[Greylist-users] RE: Broken MTA? - Exchange 2003 SMTP (Matt Prigge)

[Bob de Wildt]

Matt,

We have experimented with the codes and we took the following RFC's to
hand:
- RFC 821 (aug 1982)
- RFC 1891 (jan 1996)
- RFC 1893 (jan 1996)
- RFC 3463 (jan 2003).

According to all of them the 451 status code leaves room for any MTA to
break the connection and return the message immediatly.

Instead of using 451 as a status code, try 421 as status code.
This referres to a connection error and a tranmission shutdown at the
sender side.

421 status does not state any permanent errors. Which means the sender
MTA has to retry to deliver the message.

Further we looked at the revised RFC 1893
Where you will find that status code:

4.X.X   Persistent Transient Failure

          A persistent transient failure is one in which the message as
          sent is valid, but some temporary event prevents the
successful
          sending of the message.  Sending in the future may be
successful.

X.3.2   System not accepting network messages

          The host on which the mailbox is resident is not accepting
          messages.  Examples of such conditions include an immanent
          shutdown, excessive load, or system maintenance.  This is
          useful for both permanent and persistent transient errors.

This does never indicate that resending the message will result in a
bounce, since it does not state any permanent error.

So we have chosen as an error reply for:
"421" , "4.3.2 "
Which many MTA's seem to understand. Even MTA's that would not resend on
"451" , "4.7.1" seem to accept this code as a sign they need to retry to
deliver the message.

It also function perfectly with Exchange 2003. Though we still have some
issues with Novell Groupware, but hey, nobody is perfect :)


Most of the errors you have experimented with end with the line:
<< This is useful only as a permanent error. >>
Which is exactly what Exchange 2000 and 2003 interpert.

Try feeding exchange the 421 code and see wether it starts resending.
After that experiment with the second status code.

Also have a close look at RFC 3463 (januari 2003) which is a revised
version of RFC 1893.


Kind regards and good luck, 

Bob de Wildt