ietf-smtp
[Top] [All Lists]

Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.

2005-05-09 12:56:16
On Mon, 09 May 2005 11:11:35 PDT, SM said:

Greylisting is a short term fix.  The better question is what to do on a 
4.7.1 extended code.  MX hosts may have different filtering 
policies.  Should the SMTP client use the same MX host on a 4.7.1 to avoid 
getting around filtering policies and to play nice with greylisting?

If a site sets up multiple MX's with different policies, they're painting the
target on their own foreheads. Sticking to "the same MX host" to play nice
won't work - if you're already talking to a secondary MX, there's 2
possibilities:

1) They are in the same administrative domain and implement the same policy.
It doesn't matter if you try another MX next time, as results are consistent.

2) The backup MX doesn't implement the same policy.  In this case, you *should*
implement a flip-flop to another MX, as that increases the chances you'll hit
a machine implementing the desired policy from zero to something non-zero.

In either case, flipping to a different MX results in at least as good results.

It however *is* true that if the *primary* gives you a 4.7.X, it's probably a
good idea to not retry on a secondary, on the assumption that the secondary 
never
has more clue about the security stance of the primary than the primary itself
does.  If the *primary* is saying "temp security fail", then any attempt by a
secondary to give a more definitive permanent answer (in *either* the 2.x.y or
5.x.y series) is spurious at best.

Attachment: pgpy32PiNsJzu.pgp
Description: PGP signature