[Greylist-users] Up and running on the real sever - and I

[James J Dempsey]

William Blunn <bill--greylist at tao-group.com> wrote:

> The RFCs are useful as a starting point, and for quoting at people *under
> certain circumstances* ...  but slavishly following them is not always
> the best path.

I know what you are trying to say, but I think it is a dangerous slippery
slope.  The RFCs are the law that explains the protocol between two remote
hosts.  If hosts start doing whatever they want, then we are never going to
get mail delivered.

Certainly in a case where there is a problem between two hosts, the one that
didn't comply with the RFC is at fault.  Period.

As an example of why we have RFCs: I've always hated the blatant misspelling
of the SMTP HELO command.  I'm going to change my mail transport to use HELLO
instead.  Clearly this is an improvement. 

It is similar to the many highways we have here in Massachusetts with 55mph
speed limits.  90% of the people disregard the law -- the average speed on
Rt 128 is probably 70-75 mph when there isn't rush hour traffic.  Teach your
learning-to-drive children that it is OK to drive over the speed limit and
you are teaching them that it is OK to interpret for yourself which laws to
follow and which to break.  This is a big mistake.

To get back to the original question of what the RFC says about retry
strategies, Section 4.5.4.1 of RFC 2821 says:

    ...mail that cannot be transmitted immediately MUST be queued and periodically
    retried by the sender.
    ...
    The sender MUST delay retrying a particular destination after one attempt
    has failed.  In general, the retry interval SHOULD be at least 30 minutes;
    however, more sophisticated and variable strategies will be beneficial when
    the SMTP client can determine the reason for non-delivery.
    ...
    Retries continue until the message is transmitted or the sender gives up;
    the give-up time generally needs to be at least 4-5 days.  The parameters to
    the retry algorithm MUST be configurable.
    ...
    The SMTP client can shorten the queuing delay in cooperation with the SMTP
    server.  For example, if mail is received from a particular address, it is
    likely that mail queued for that host can now be sent.  Application of this
    principle may, in many cases, eliminate the requirement for an explicit
    "send queues now" function such as ETRN [9].


So the bottom line is that the only thing it says is that you MUST do is
retry periodically, and that the parameters must be configurable.  It
suggests that you should retry only after 30 minutes and that you should
keep trying for 4-5 days.

Hope this helps,

                       --Jim Dempsey--
                         jjd at jjd.com
                       http://jjd.com/

P.S. I can't drive 55.