Re: slow email validation problems

--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.
     john