Mail Server best practices - was: Pandora's Box of new TLDs
Frank Bulk - iNAME
frnkblk at iname.com
Sat Jun 28 18:21:38 UTC 2008
From: Phil Regnauld [mailto:regnauld at catpipe.net]
Sent: Saturday, June 28, 2008 1:02 PM
To: michael.dillon at bt.com
Cc: nanog at nanog.org
Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs
michael.dillon at bt.com (michael.dillon) writes:
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
don't have other options other than just using some horrible webmail
service, because their operator/ISP is clueless. I do make a
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.
More information about the NANOG