On 6/5/06, Mark E. Mallett <mem(_at_)mv(_dot_)mv(_dot_)com> wrote:
I think that is indeed the goal (not bypassing policy restrictions, but
enforcing them individually, without having to 4xx all but one
recipient). My reaction was also that the LMTP approach is better: be
able to adjust or confirm, after DATA, any successful RCPT-TO that
happened before DATA. I'm sure this has been suggested before, but
dunno why it hasn't gotten any start.
mm
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.
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, 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.
--
David L Nicol
"fans of liza minelli should always be
disconnected immediately" -- Matthew Henry
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg