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

On 2006-06-06 00:21:16 -0000, John Levine wrote:

The idea if implemented would ease content-based filtering at the
server as messages to multiple recipients would no longer require
separate complete transactions for each recipient when sending to
servers that implement complex per-recipient acceptance policies.


I wouldn't bother, for several reasons:

One is that you're optimizing a rare case and pessimizing an unusual
case.  I get a lot of mail that I reject at RCPT TO, little mail to
multiple recipients, and no mail at all to multiple recipients who
need to do different things with it based on the content.  If one
thinks it's spam and the other doesn't, that invariably means one of
them has a misadjusted spam filter.


I agree that the case is rare, but nevertheless I think it is an
important case (I have implemented a plugin for qpsmtpd to allow
per-recipient content-filters - an ugly hack, but it seems to work).

There are cases where it isn't a misadjusted spam-filter (a mail
crossposted to a closed and an open mailing-list comes to mind), and
even where it is, one user's misadjusted spam filter shouldn't prevent a
different user from getting legitimate mail.

The next is that for reasons unrelated to bandwidth, there are good
reasons to send list mail one copy at a time.


I agree with that, but messages with lots of recipients are often not
sent through mailing-list software. People create "lists" in their
personal address books and simply send a mail to umpteen recipients.

The last is that despite the persistent folklore, the amount of
bandwidth that mail uses is trivial compared to web and P2P, and it is
a foolish economy to try and reduce it even more.


Last time I looked at our site the smtp traffic was comparable to http
and quite ahead of the p2p protocols I know. I was quite surprised. I'll
have to measure that again soon.

But I agree that bandwidth isn't much of a problem. The problem is that
messages with dozens or hundreds recipients are transferred in a single
transaction and that the SMTP protocol currently doesn't offer any any
method to return per-recipient results after receiving the content.
Current solutions (like my cf_wrapper mentioned above) rely on temporary
failures, which may cause long delays if there are many recipients. 

So I think that some extension should be implemented. Like some others I
would prefer something based on the LMTP model, though. (But maybe
that's just because I already know LMTP)

        hp

-- 
   _  | Peter J. Holzer    | Ich sehe nun ein, dass Computer wenig
|_|_) | Sysadmin WSR       | geeignet sind, um sich was zu merken.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Holger Lembke in dan-am

pgpgYBgiEW4Id.pgp
Description: PGP signature

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg