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.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-am
Attachment:
pgpQRSSw2f1m5.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg