Comments in-line. -----Original Message----- From: Phil Regnauld [mailto:regnauld@catpipe.net] Sent: Saturday, June 28, 2008 1:02 PM To: michael.dillon@bt.com Cc: nanog@nanog.org Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs michael.dillon@bt.com (michael.dillon) writes:
http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf
Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. FB> You do have an option -- ask the sender to clean up their act. Then the operator/ISP will happily receive the sender's e-mail. When one of our business customers complains to us (ISP) that they can't send e-mail to an external third-party and I find out it's due to poor configuration on their part (almost 100% of the time -- the sole exception that I can recall is a business customer's IP address being blocked by a GoDaddy RBL even though another properly SWIPed customer was sending the spam. Apparently GoDaddy's minimum block size is /24 and they can't bother to look up the ranges), I don't complain about the external third-party, I educate our business customer on best practices.
On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry.
Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). FB> The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure? Of course, the inverse it not true. <snip>