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.
The next is that for reasons unrelated to bandwidth, there are good
reasons to send list mail one copy at a time. On the lists I run,
plain old text lists like this one, each copy of each message is sent
out with a unique bounce address that makes list management vastly
easier by encoding the list, the message number, and the recipient.
I'm also thinking of embedding per-user unsubscribe links, since it's
quite common for people to get stuck when they subscribe at address A,
don't keep the welcome message that tells how to unsub, then try to
unsub from new address B.
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. The experiments
I've seen say that for normal MTAs on normal network links, individual
deliveries get list mail done in less elapsed time due to the
increased parallelism. (In the past 30 years, the bandwidth of
networks has vastly increased, but the end to end time hasn't changed
much, what with that pesky speed of light.)
So there are certainly problems to be fixed in e-mail, but this isn't
one of them.
R's,
John
PS: If you really want to do this bad idea, leave the MAIL FROM at the
beginning, and have the extension return a list of codes at the end of
data, one per rcpt address. Then at least you're no worse off than
you are now.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg