ietf-smtp
[Top] [All Lists]

Re: Mail Data termination

2011-08-22 08:03:24



--On Monday, August 22, 2011 09:42 +0100 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

...
 
This is _not_ a standards problem, at least IMO.

Well, I have issues with the timeout suggestions in 5321,
which I do think need more discussion. I appreciate that the
'SHOULD' means you are allowed to ignore that suggestion if
there are 'valid reasons' to do so, but it is not clear at all
what implications may be.

Certainly 5321 and both of its predecessors were written for
times in which SMTP clients and servers could be assumed to be
cooperative in getting messages through, in which message
delivery (and NDN delivery) were everyone's primary objectives,
and where network behavior was the main enemy, not attackers of
a variety of types.  Certainly they were not written for
situations in which the attackers included client or servers
designed to get best performance (however measured or evaluated)
for their environments by making performance for everyone else
worse.

When I resist changing the 5321 limits, I do so both because I
am generally concerned about the procedural implications of
protocol changes at this state but also because there are still
environments around the world with lower-performance clients
and/or servers,  lower bandwidth than the big server farms, or
even intermittent connections.  Servers with intermittent or
flaky connections make strategies like "once you determine that
you can open a connection and get a message through to a host,
gather up everything you can find and send it as part of the
same connection and, especially if the connection took several
tries to establish, maybe keep it open for short while to see if
anything else can be pushed through it" really sensible.  Our
colleagues in the DTN business would probably suggest that
"around the world" should be expanded to "around the solar
system" (at least) and point out that the same sorts of
strategies are even more important for them.
 
To be honest, I'd never thought any major sender would use
connection caching when sending mail as it is (to my
viewpoint) a very antisocial thing to do.

See above.  At least some of the thinking that produced that
behavior comes from environments in which the profile, capacity,
and connections of a server made getting a connection really
hard (no matter how many cycles the connection setup and
teardown did or did not take).   In that environment, the
strategy is not only not antisocial, it is hugely beneficial,
not just to the sender but to the receiver and the
users/mailboxes it supports.

Maybe, in a perfect world, a client system would try to figure
out and remember the difference between a server like that and a
high-performance server that was well and continuously
connected.  Like caching MX targets, one should do that only
with great care and sophistication, lest one cause far more
serious problems in an environment that can change between queue
runs.  Maybe it isn't worth the trouble -- as with other things,
I (and many others) can tell you how to make these statistical
projections from history work, but I can't advise on whether
they are sensible or worth the tradeoffs without knowing a huge
amount about a particular situation and code base.

So, until this
discussion, it had never entered my mind that we needed to do
anything about it. We do have to fight against 'DoS' attacks,
which might, in fact, turn out to be 'legitimate' connection
caching, but because we've been treating it as attacks, we've
been handling it differently than if it was a legitimate, but
unwanted, behaviour.

Maybe an info or BCP document would be useful

My sense is that there have been some very careful discussions
and analyses in this thread (along with the inevitable small
amount of complete noise).  Probably a good foundation for such
a document could be to simply draw that material together,
eliminate the noise, and organize it coherently.  Because of
differences among environments I think it would actually be most
useful as a discussion of the issues and analysis of what might
make sense than as any sort of normative specification, buy
YMMD.  If someone has both the time and interest, I'd strongly
encourage it.  I'd guess that the usual suspects for producing
such documents are too busy (I know I am), but that should imply
"someone else needs to pick up the pen if it is to be done" and
not "it isn't worthwhile".

    john

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