AOL rejecting email from Horde

[faris]

A strange problem has cropped up today.

AOL seems to have started rejecting email sent from 127.0.0.1 (localhost). This seems very reasonable in a way.

Unfortunately it seems that webmail in Plesk 7.5.3 on RH9 send email from localhost -- I've sent some test messages and checked the headers.

Does anybody know of any way of changing this so it is sent from the actual public IP of the server?

Or could it be a PHP issue somehow? I've never seen this happen before so I suppose it could be. I'm currently using Scott's php 4.1.0.

Faris.

 

[jamesyeeoc]

Here are the Received headers from a test email I sent from Horde (on a test server) to my Yahoo (I don't have an AOL account to test with). Follow them from the bottom up:

Received: from xx.yy.zz.66 (EHLO mail.mytestdomain.com) (xx.yy.zz.66) by mta147.mail.mud.yahoo.com
with SMTP; Fri, 25 Nov 2005 18:22:17 -0800

Received: (qmail 5416 invoked by uid 2520); 25 Nov 2005 18:19:03 -0800

Received: from 127.0.0.1 by www.mytestdomain.com (envelope-from <[email protected]>, uid 2020)
with qmail-scanner-1.25st (clamdscan: 0.87.1/1195. f-prot: 4.5.4/3.16.6.
spamassassin: 3.0.3. perlscan: 1.25st. Clear:RC:1(127.0.0.1):.
Processed in 1.517614 secs); 26 Nov 2005 02:19:03 -0000

Received: from localhost (127.0.0.1) by localhost with SMTP; 25 Nov 2005 18:19:01 -0800

Received: from www.mytestdomain.com (www.mytestdomain.com [xx.yy.zz.68]) by webmail.mytestdomain.com
(Horde MIME library) with HTTP; Fri, 25 Nov 2005 18:19:01 -0800

I do not believe there will be any way to totally get rid of the headers showing 127.0.0.1, those are the ones where Horde is passing it around internally in the server. But as you can see, by the time it goes 'out' to the destination, it is going out from the server's main IP, and that is reflected in Yahoo's header.

If AOL is scanning ALL the headers and rejecting if it finds any trace of 127.0.0.1, then that is a bad thing.

 

[akaplan]

AOL recenlty starting requring a .PTR record for all IP's that connect to its mail servers.

You can easily check WHICH ip AOL "sees" as the sending ip address, in webmail send email to " [email protected]"

You will get a response with the sending IP address.

 

[phoenixisp]

Also, I know from first hand experience, AOL also requires that a .txt (SPF) DNS entry be made.

http://postmaster.aol.com/spf/details.html

 

[faris]

Thanks for some extremely useful info - I'm very greatful!

Using webmail to send to that email address resulted in:

*************
Your connecting IP is: [my main server's public IP]

Please visit our web page at: http://postmaster.aol.com for more information about AOL Email Policies and methods to fix delivery issues.

Postmaster Group
America Online, Inc.
1-888-212-5537
*************

So it may not be the localhost address that is the problem after all and I may be mis-interpreting what has happened.

This is the error generated when sending either by webmail or, as I have just discovered, by using formmail (but that might be a one off error ....)

*********

Error 421 DYN:T1

421 DYN:T1
http://postmaster.info.aol.com/errors/421dynt1.html
EXPLANATION:

The IP address you are sending from has been blocked due to AOL Member complaints and/or high volumes of e-mail.

SOLUTION:

Complaints:
When an AOL member clicks "this is spam" for a piece of email sent from one of your IPs, this is considered a "complaint". If you are having difficulty with the number of complaints you are receiving, a feedback loop would benefit you. Once you have requested a feedback loop you will be notified when a member clicks "this is spam". See feedback loop for additional information.

Mail Volumes:
America Online has made provisions for those who need to send large amounts of e-mail to our members. The bulk sender list allows for the possibility of large amounts of e-mail sent to AOL. Apply for the bulk sender list online.

**********

Now we do not send a large volume of email to aol. Of course we do have users who forward email to their own AOL accounts (no more than 5 users!), and as a result a lot of spam gets forwarded, but only to the users own AOL accounts. And since AOL rejects email from made up email addresses, not much will get through, surely?

This is why I thought it must be the localhost address that was triggering it, given that a lot of spam will be generated by bots and viruses and whatever, many of which will probably be sending as localhost.

But I'm starting think maybe I'm completely wrong.

With regards to SPF records ... this is going to be difficult, as you can't add spf records to localcost (can you?).

It is all very confusing.

Faris.

 

[phoenixisp]

I spent about 2 hours on the phone with the "Postmaster" from AOL and here are the things that they say will solve the problem - in the order they addressed them:
1) Reverse DNS
2) Port- they don't like email on 25, they prefer 587
3) Reported as spammer?

While on the phone with them, and 'passing' all 3 of their requirements, I was still blocked. Even though they claimed I wasn't on their block list. But as soon as I added the SPF record for the server's default domain, everything went through just fine.

If you need more info on SPFs, go to this site, they'll even help you configure your statement. Then when you add the record to your domain's DNS, make sure to enter it as a TXT record.

http://www.openspf.org/

 

[ShadowMan@]

That AOL error has nothing to do with localhost or 127.0.0.1 being in the headers as you first indicated in the original post. Simply put, your domain name or IP address has been blocked due to some AOL users flagging emails from your server as being SPAM.

AOL has a procedure to follow, but there is no guarantee that they will unblock you. One of their ways would be at:

http://postmaster.info.aol.com/fbl/ (this is the 'feedback loop' they mention)

If you are sending solicited bulk emails, then you would do the following procedure:

http://postmaster.aol.com/whitelist/

We still have a few old Plesk servers which do not have SPF records and those domains have not had problems sending to AOL (even as of today), and some of them do not have their own PTR records. So I'm not sure why some Plesk admins have problems with AOL and others don't....

 

[TDuncklee]

For years I’ve depended on qmhandle. I’ve upgraded to freeBSD 4.11 and Plesk 7.5 and now can’t get qmhandle to run. ./qmHandle –a returns:
Qmail isn't running, can't send messages!

I have this in the config:
my ($pidcmd) = 'pidof qmail-send';

# pidof qmail-send returns the correct pid so I know it works. I even put a print statement in qmhandle to show me that it is getting the pid.

I also had to comment out use warnings; but #!/usr/bin/perl –w is supposed to do the same thing.

Anyone have a solution?

 

[faris]

Well, the thing is I know every single customer on our servers personally. No really! And they don't send bulk email. They hardly send any email. In fact I don't allow the majority to send via our servers - they use their ISPs.

Anyway, I've instigated the feedback loop, and added spf records to everything that I can.

But I suspect there's more too it somehow.

TDuncklee -- I know it isn't the ideal answer, but have you tried 4PSA's Qmail Manager? OK, it costs money, but not that much, and is quite useful.

Faris.

 

[TDuncklee]

Well I figured out how to get qmhandle to run. Apparently the new pidof (installed via the FreeBSED ports system) puts a space at the end of the pid it returns. Around line 465 this fails:

if ($qmpid =~ /^\d+$/) { return $qmpid; }

Since I don’t know perl I just added a chop to remove the trailing space so it ends up looking like this:

# Retrieve pid of qmail-send
sub qmailPid {
my $qmpid = `$pidcmd`;
chomp ($qmpid);
chop ($qmpid);
if ($qmpid =~ /^\d+$/) { return $qmpid; }
return 0;
}

Only other change is to change very first line to:
#!/usr/bin/perl -w
And comment out:
#use warnings;

 

[ShadowMan@]

Originally posted by faris
Well, the thing is I know every single customer on our servers personally. No really! And they don't send bulk email. They hardly send any email. In fact I don't allow the majority to send via our servers - they use their ISPs

Don't forget the following situations:

1. The IP address was owned by a different server which got blacklisted.

2. Email address spoofing (false From) used by Spammers, so spam mails may not have even touched your server, nor originated from an actual user on your system.

3. An email(s) sent by one of the minority which can send out via your server, may have been mistakenly reported as spam by the AOL user (I have seen this happen, though rarely).

I recently had one IP test positive as blacklisted (have owned the IP for years and never was blacklisted anywhere before), the only thing we could attribute it to was some users of one domain (I too know all of that company's employees personally, for years) were emailing joke/**** emails back and forth over and over and many of them ended up being flagged by spam by some ISPs, then got reported to ordb.org (not sure how). Had to go through the procedure with AOL and ordb.org but is fine now. And none of the other 63 IPs in that particular block have ever had any problems either.

 

[faris]

I think you were right all along.

With the AOL feedback loop in place, I was sent one of the spam messages which I was able to trace to a pathetically written form to email cgi script on one of the hosting accounts. He's going to get a telling off.

The nasty spammers have been using the server to send zillions of messages to AOL users. Thankfully only AOL users, but still.....

Faris.