[Top] [All Lists]

Re: 5xx errors in general and MXs

2004-04-23 05:41:07


- 5xx in response to RCPT is a permanent failure.  The client SHOULD NOT
  try to deliver that message to that recipient via other MXes. 

- If a server wants to say "try another MX" in response to RCPT then it
  SHOULD respond with 4xx.  There's no guarantee that the client will 
  use a different MX on the next try, but a robust client will do so.

- Mail domains that implement rejection policies based on IP address or
  other criteria SHOULD implement them consistently across all incoming
  message paths.  (note that this doesn't necessarily mean that all 
  MXes should implement the same policy at the SMTP level; it means that
  a message that is rejected for policy reasons will be rejected at 
  some point in the signal path no matter which MX the client chooses)

- Servers SHOULD NOT trust third party blacklists when deciding whether 
  to reject messages.  They are notoriously unreliable.


On another list we have a - meanwhile rather emotional - discussion
about aggressive delivery attempts.

The origin of the discussion and the aggressive delivery attempts are
- large sites rejecting (valid, i.e. non spam) emails from certain IP
  addresses based on policy decision, while they accept the same email
  from other IP addresses without any problems (DUL lists like AOL
  uses them for 5xx greetings or uses them to answer
  RCPT TO with "550 5.0.0 Access denied")
- some unclear wordings in RFC 2821 (and historic 974) about what a
  delivery is and what a "successful" delivery is.
  In particular does a "5xx" code as an answer to a RCPT TO qualify
  for a "successful delivery" in terms of a "successful connection"
  or is a "successful delivery" to be interpreted in terms of a
  "successful transmission" (RFC974 makes some differences but is
  unclear about details, just as RFC 2821 is).

This discussion led to a view topics, namely
- how authoritative are answers from any MX server for a domain or
  is the authority of the answer limited to that particular mailserver
- is a 5xx code from one of the MXs of a domain to be treated as a
  global permanent failure or is it valid (and backed by wording in
  e.g. RFC974
     "Implementors are encouraged to write mailers so that they
      try the MXs in order until one of the MXs accepts the message,
      or all the MXs have been tried."
  if I get e.g. a "550 go away" as an answer to a RCPT TO command to simply
  disconnect and try the next MX and if I am through with all of them
  to inject the message at a smarthost (e.g. my ISPs mailserver).
- how to interpret the 5xx code that e.g. AOL uses for a greeting if they
  reject connections for policy reasons.

The originator of the aggressive delivery strategy argued
- if you don't want me to use any other of your MX hosts in case of
  a 5xx code then don't list them.
- if you don't want me to annul the policies set for a specific MX
  then take care that all of your MXs enforce the same policy
- there is no clear way for a receiving MTA to tell the sending MTA about
  its policies like "we don't accept email from your IP but probably
  will if you use your ISPs mailserver".

Would it be desirable to have specific message codes signalling policies to
sending MTAs?

Comments and clarifications highly welcome,


SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Regime Change 2004 - better late than never. 

<Prev in Thread] Current Thread [Next in Thread>