The problem with SPEWS has been around since the second half of 2003 - at least. SPEWS was very poorly run - they had a policy of blocking a service provider's entire address space if that provider failed to resolve a problem involving a single IP on SPEWS' terms. They did this to both The Planet and Hurricane Electric, caker took it up with them, nothing ever got resolved. Bottom line - if your correspondents have an ISP who uses SPEWS then they need a new ISP.

_________________
/ Peter

OK, more information. dig returns a valid reverse dns, so that looks to be working. No blocking taking place, so that is cool.

<p>I did find something in the mail log for every single user@aol.com message:

Mar 23 15:15:38 localhost postfix/smtp[5071]: 0CF3417575: to=<user@aol.com>, relay=mailin-04.mx.aol.com[64.12.137.184], delay=6, status=bounced (host mailin-04.mx.aol.com[64.12.137.184] said: 550 REQUESTED ACTION NOT TAKEN: DNS FAILURE)

Any ideas? It looks like it is saying that it couldn't resolve the name, but my IP address does resolve back to mydomain.com. Could it be that mail is being sent by Postfix from mail.mydomain.com? (it appears like this in the log)

I have another entry that might indicate this...

Mar 21 18:39:09 localhost postfix/smtp[950]: E78591758D: to=<user@cox.net>, relay=mx.east.cox.net[68.1.17.3], delay=9, status=bounced (host mx.east.cox.net[68.1.17.3] said: 553 mail.mydomain.com does not exist)

I am not sure where postfix got the mail.mydomain.com from... any suggestions? Does this look like it could be the problem? I am using zoneedit to do dns routing for my domain. Do I need to add a mail.mydomain.com CNAME entry to handle and resolve this?

Thanks again everyone, you have been extrememly helpful.

mydomain.com is one of the examples in the default postfix files.

Take a look through main.conf, you will probably find it in there, update it to the correct domain.

Adam

It is he correct domain... I was using mydomain.com in place of my real domain, as I didn't want to spam my domain here looking for attention.

<p>Anyone else know why mail. is getting appended to my outgoing mail?

Check the output of:

postconf | grep '^myhostname\|^smtp_helo_name'

Parameter myhostname defaults to the value obtained from the gethostname() function (the value in /etc/hostname dot concatenated with the value in /etc/dnsdomainname, on most systems).

Parameter smtp_helo_name defaults to the same as myhostname.

Whatever names you have for these two parameters need to be resolvable in the DNS.

_________________
/ Peter

It was an improperly configured dns. I added mail.mydomain.com as a CNAME and it cleared the problem right up (mail.mydomain.com was being rejected when the receiving server could not resolve it...)

Thanks everyone!

Don't use CNAMES for mail servers. Use A records.

The RFC's say use A records and if you don't some mailers
will not exchange mail with you.

Yep, a good rule of thumb is that anything that goes in the "header" portion of your zone (that is, MX, NS, etc) should never point to a CNAME. Only A records. It's amazing how much wierdness and breakage it can cause in seemingly unrelated areas.

_________________
----
Ed/Bones.

Or, you can use A records for everything, like me.

Never heard a good argument as to why not.

_________________
Jay Faulkner
http://oldos.org

Ok, I can't resist.

Suppose you have a web server that serves a large number of websites on the same IP. They are different sites for different people. You need to change the IP of your server for whatever reason.

If you use A records only you have to make a lot of dns changes to fix this.

Anyone can write a one liner to change a hundred instances of <OLD IP> to <NEW IP>,
increment the serial, HUP named, and your done.

If you have a hundred DNS zone files you can write a little loop to do the same thing to each file.

But, what if you don't control all the zonefiles. What if you need to email or phone a hundred different people to get the changes made to their zonefiles. In that case using CNAMES would save you quite a lot of time.