Re: Mail Data termination
2011-08-18 15:42:09
To add the problems a client using a CS logic can cause, it won't work
very well against the growing # of Greylist Ready SMTP receivers.
If an initial transaction is rejected is due to greylist, sitting
there idle waiting for another same destination message to come in to
start a new transaction with the receiver isn't going to change the
initial SENDER rejection status.
Allowing for this, opens the door for GreyList Security Loopholes we
have documented proof (and discussed here) to occur.
The solution was to remember the transaction status so that bad guys
don't use 2nd transaction to get around the initial greylist rejection.
Hector Santos wrote:
Murray S. Kucherawy wrote:
One of the more ubiquitous MTAs out there has a feature called
"connection caching" where it will keep some fixed number of outbound
SMTP connections around, cycled using an LRU method, in case a new
message arrives that is routed to a recent destination to avoid the
cost
of making a new connection and doing the initial SMTP negotiation.
I believe Postfix and Exchange can do this.
And I was referring to Sendmail.
The more SMTP clients there are that do this, the more likely it is
that a server demanding QUIT before scheduling a delivery attempt will
lose
mail.
Fortunately, that is *never* the case hence there is no problem until
you try to correct a problem. It helps with robustness by reducing
problematic transactions, especially the exploited ones.
But you did highlight something I need to look at, not because of 5321
required QUIT which by the way is only going to be addressed with YASO
(Yet Another Server Option), but rather analyze what the major
dangerous presumptions and selfish engineering considerations a client
operating under a Connection Sharing (CS) mode imposes on receivers. It
might explains some situations seen.
First, a server may have Receiver Loading Limits and a client with a
tenacity to take up more CPU time than it needs can get it flagged. To
use CS for the purpose to reduce its redundancy without considering the
load it places on receivers is a very selfish engineering consideration.
Chewing up a channel unnecessarily for 5 minutes disallowing other
clients connection access increases system available and scalability
problems.
Second, it uses a dangerous presumption that a server is FIXED on using
5 minutes for idle times. 5 minutes is a SHOULD, not a MUST and for a
client to DEPEND on a SERVER using 5 minutes is short-sighted engineering.
This should be done using an SMTP extension where a server can expose
server timeouts perhaps and willingness to allow a client to sit idle
redundantly and repeatedly.
Whats surreal about this, is the constant conflict of people ramming
specs in people's spec yet have this strange tolerance for allowing and
accommodating failure. Very odd. That doesn't work very well, IMEO,
and if you wish to call that a "singular interpretation" thats fine by me.
As this particular case shown, the ignorance of the failure would of
delivered bad messages and also delivered duplicated bad messages.
--
Sincerely
Hector Santos
http://www.santronics.com
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Mail Data termination, (continued)
- Re: Mail Data termination, Hector Santos
- Re: Mail Data termination, Hector Santos
- Connection Caching and Little's Law, Hector Santos
- Re: Mail Data termination,
Hector Santos <=
- Re: Mail Data termination, Sabahattin Gucukoglu
- RE: Mail Data termination, ned+ietf-smtp
- Re: Mail Data termination, Hector Santos
- Re: Mail Data termination, Randall Gellens
- Re: Mail Data termination, Hector Santos
- Re: Mail Data termination, John C Klensin
- RE: Mail Data termination, Murray S. Kucherawy
- Re: Mail Data termination, Hector Santos
- Re: Mail Data termination, SM
Re: Mail Data termination, Hector Santos
|
|
|