North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Mail Server best practices - was: Pandora's Box of new TLDs

  • From: Frank Bulk - iNAME
  • Date: Sat Jun 28 14:21:56 2008

Comments in-line.

-----Original Message-----
From: Phil Regnauld [mailto:[email protected]] 
Sent: Saturday, June 28, 2008 1:02 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs

[email protected] (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>