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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg