[Top] [All Lists]

Re: [Asrg] pre-rfc thought balloon: ESMTP DATAFIRST

2006-06-05 18:17:51
On Mon, Jun 05, 2006 at 06:20:20PM -0500, David Nicol wrote:

I had lunch last week with some guys who send "responsible e-mail 
and got a glimpse of the situation from their points of view.  If you had a 
of, say, every potential coca-cola drinker at AOL, switching to a DATAFIRST
sequence would allow you to put the ad in first and then chase it with the 
mailing list, easing your conflicts with the recipient postmasters who 
have to deal with multiple open connections from you.  The bulk of the
data is the vast list of recipients, perhaps millions.  Currently as
we all know a
bulk sender must work within recipient limits, and per-recipient policies 
do not
work at all with multiple recipients.  LTMP's approach works but it is
still half-way
for a large list, as the list has to be cached on both sides while the
policy is checked.  With a short message and a long list and
per-recipient policy,
DATAFIRST is the correct order.

I dunno.  I somehow doubt that receivers will want to keep a delivery
transaction open while accepting and processing a large enough recipient
list that would make caching that list a problem for either side.
The statement that "I have so many recipients to give you all at once
that it's a burden to me to keep track of them" does not strike me
as a friendly one from the point of view of the receiver.

[And do senders really want to send so much non-personalized bulk in
this day and age?]

The LMTP-style solution adds value without taking any away, whereas a
mere rearrangement of commands does take functionality away.  Among the
things lost are:

 - a point at which you can revoke/abort the session, despite any
   previously accepted RCPT-TOs (there are various policy reasons for
   which this is common behaviour).  You could of course add a new
   RCPT-TO response that means the same thing, or an "all done" command
   phase, but this would again mean caching the list on both sides;

 - being able to reject the DATA because you've decided against it
   based on the recipient list; you mention later that there's no
   benefit in this, but I have a hard time agreeing with that.

The concern about needing to receive the data provisionally while waiting 
valid recipients is a non-issue.  The DOS potential is no greater than 

The percentage of transactions turned away pre-DATA purely because of
bad RCPT-TO (or a decision made during RCPT-TO processing) is large.
This rearrangement of commands could conveivably turn that to zero; even
if not widely adopted, it could be easily used for mischievious purposes.

and the SIZE extension would take care of announcing that you
will only take so much DATA before closing.  DATAFIRST should have its
own size restriction that is separate from the SIZE size restriction, that's
a good point.

This merely parameterizes the problem, whereas LMTP-style deals with it


Asrg mailing list

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