ietf-smtp
[Top] [All Lists]

Re: Restrictive ~ priority

2007-05-03 13:53:01
On 2007-05-03 16:05:31 -0400, Hector Santos wrote:
Frank Ellermann wrote:
You especially don't want an "accept everything" policy on the
lowest-priority MX because spammers do expect and exploit that.

(Hmm, is that another recommendation that should go into the RFC if
it isn't already there? "If there are multiple MX for a domain, they
SHOULD implement the same policy for accepting or rejecting mail. In
particular, a lower priority MX should not accept mail that a higher
priority MX rejects")

Yes, but I'd say "for MXs with a different priority the MX with the
numerically higher priority SHOULD be at least as restrictive with
respect to accepting mails for the domain in question as the MX with
the numerically lower priority." 


Here is a MX version of "GreyListing," that was getting some interesting 
positive results from some of our sysops who tried it:

    http://www.joreybump.com/code/howto/nolisting.html

I was aware of that, but I realize that the sentence I suggested covers
that case poorly. The lowest priority MX in this scheme doesn't usually
even listen on port 25, and if it does, it answers every request with a
temporary error. So it never really accepts or rejects mail.

What I wanted to prevent is the case where a conforming client that
tries the MXs in the correct order cannot deliver a mail because it gets
a 5xx error, but a non-conforming client which tries the MXs in some
other order can deliver the mail. If that is wide-spread it encourages
writing non-conforming clients, both for spam and legitimate purposes.

        hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Sam in "Freefall"

Attachment: signature.asc
Description: Digital signature