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

["Mark E. Mallett" <mem at mv.mv.com>]

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 
> advertising"
> and got a glimpse of the situation from their points of view.  If you had a 
> list
> 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 
> whole
> mailing list, easing your conflicts with the recipient postmasters who 
> currently
> have to deal with multiple open connections from you.  The bulk of the
> transferred
> 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
> per-reipienct
> 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 
> for
> valid recipients is a non-issue.  The DOS potential is no greater than 
> current
> practice,

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

mm

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg