[Top] [All Lists]

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

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.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>