[Top] [All Lists]

Re: slow email validation problems

2005-09-15 05:12:51

--On Wednesday, September 14, 2005 9:22 PM -0400 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Wed, 14 Sep 2005 21:20:41 +0200, Bogdan Tomchuk said:

I still have a lot of trouble to get why lot of peoples on
this list try, in some  way, to move there decision
responsibility on remote system.

RFC2821 says:

6.1 Reliable Delivery and Replies by Email

   When the receiver-SMTP accepts a piece of mail (by sending
a "250 OK"    message in response to DATA), it is accepting
responsibility for    delivering or relaying the message.  It
must take this responsibility    seriously.  It MUST NOT lose
the message for frivolous reasons, such    as because the host
later crashes or because of a predictable    resource shortage.

OK?  Re-read that until you understand - sending a '250 OK' is
to be taken *seriously*, to the point where losing a message
because the system crashes is considered a "frivolous" excuse.

As a result, it's in my interest to do *anything* I can to
avoid sending that '250 OK' unless I'm very confident that I
can deal with it - after all, I know that while I'm busy being
indecisive, it's safely queued on the sending system that
issued a '250 OK' before trying to forward it to me. ;)

While I certainly agree with this, I would say "anything that does not risk a self-inflicted denial of service attack by holding too many connections open for so long". I know I don't need to tell you this, but, for several others who have gotten enthused about this "keepalive" idea, please reread Harald's comment from the 13th, quoted below, and remember that we specified extensions such as PIPELINING so as to squeeze as much time, and as many turnarounds, out of SMTP sending as possible.

Harald wrote...

hmm.... "scaling is the ultimate problem", says Mike O'Dell.

If you take 30 seconds to accept a message, and have the
default Postfix process limit of 100, you can accept up to 300
messages a minute - or an average of 5 per second.

If you do this, and others follow your example, you're
imposing a limit on the SENDING MTA of 5 messages per second
(if it's Postfix). If you have large resources on the sending
side, you can open up connections until you run out of process
descriptors, port numbers of something else - but it's a heavy
demand on a busy mail system to increase the average
transaction time from sub-seconds to more than 30 seconds.

Also please remember that we've got a lot of "long delay" situations on the Internet and will likely have more in the future. They include locations that have connectively only a few times a day (or, in a few cases, per week), locations that require multiple satellite hops, and, e.g., Mars and the Moon. We also have some fairly slow links around: a good deal of email still is transported over dialup links at 2400 baud (and at qualities that often does not exceed 28.8 kbps). Since it probably unwise for a relay to open a connection to the next-hop site before it has the entire message in hand, sending a moderately large message over several such links can also be a slow process. In either case, if one is going to keep all connections associated with a particular message open until the final destination MTA can either make delivery or determine that delivery is impossible, think minutes or hours (at least), not seconds.