On 2011-10-28 14:17:56 -0700, Steve Atkins wrote:
https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/
| 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
message.
hp
[1] http://projects.puremagic.com/greylisting/whitepaper.html
--
_ | Peter J. Holzer | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR | "Netz der kleinen Geister".
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Oliver Cromm in desd
signature.asc
Description: Digital signature