[Top] [All Lists]

Re: draft-atkins-smtp-traffic-control

2011-10-29 07:54:03
On 2011-10-28 14:17:56 -0700, Steve Atkins wrote:

|  If a client sees this additional response in any SMTP response from a
|  server then it SHOULD gracefully close the SMTP connection by sending
|  a QUIT command as soon as possible.  It SHOULD NOT make any new
|  connection to the same server for the duration of the delay.  If
|  possible it SHOULD gracefully close any other connections to the same
|  server.  If the implementation of the client makes it difficult to
|  implement some of these behaviours, it can still usefully implement
|  the other requirements.

I think this interacts badly with two use cases I have in mind:

1) Greylisting (yes, I know you don't care much about that, but it's
   what triggered this discussion and people will want to use it for that):

   Assume a site which uses greylisting as originally described by Evan
   Harris: Greylisting on the tupel (sender, rcpt, ip), initial delay of
   a previously unknown triplet: 1 Hour lifetime of triplets that have
   not yet allowed a mail to pass: 4 hours.

   Now you want to send emails to 5 users at this site which you have
   not emailed before.

   Your MTA will open a connection to the MX of the site and get 
   a "450 wait:3600" response to "RCPT TO:<user1(_at_)example(_dot_)com>".
   It will close the connection, put the message back into
   the queue and not contact the MX again for an hour.

   An hour later it will try to deliver the next message. Not it will
   get a "450 wait:3600" response for user2. 

   Repeat for users 3, 4, and 5.

   When it finally gets back to user1, 5 hours have passed. Not only is
   this an unacceptably long delay, by now the triplet for this user has
   expired (after 4 hours), so it will get a "450 wait:3600" response
   again, and the pattern repeats. The mails will never be delivered.

2) Too many connections:

    Assume that you have your MTA configured to attempt at most 10
    concurrent connections to an MX, and that you want to send lots of
    mails to an MX which accepts only 5 concurrent connections from a
    single IP address. 

    So your MTA opens the first 5 connections and starts sending
    messages. When it opens the 6th connection it gets a 
    "4xx wait:" reply with a small delay (maybe 0, maybe a few seconds).
    This will cause it to abort the already established connections
    (hopefully after finishing the current transaction) and then start
    new connections after the specified delay (which may be
    immediately). This seems wasteful to me.

I think it would be better if the delay applied only to the entity which
triggered it:

If a 4xx wait: reply is received at connection startup (either in the
greeting or as a reply to EHLO), then try to reconnect to that host
after the specified time.

If a 4xx wait: was received as a reply to a MAIL FROM or DATA command,
try to resend this message after the specified time.

If a 4xx wait: was received as a reply to a RCPT TO command, try to
resend this message to this specific recipient after the specified time.

A somewhat simpler strategy could be to always apply the delay to the



   _  | Peter J. Holzer    | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR       | "Netz der kleinen Geister".
| |   | hjp(_at_)hjp(_dot_)at         | 
__/   | |  -- Oliver Cromm in desd

Attachment: signature.asc
Description: Digital signature