>Unfortunately, if the MTA does it, the recipient has no control over
>it.
This is so dependent on the distributers setup, that it would make sense
for the recipient to take care of it on their end. It isn't reasonable
to make senders conform to your standards. You should be able to use
procmail to achieve anything you could do with multiple copies.
>I don't see what single-RCPT delivery has to do with list duplicate
>elimination. Each list delivery is a separate set of MAIL/RCPT.../DATA
>transactions, regardless of the MTA. If "user@host" is on "list1" and
>"list2", and a message is sent to both lists, he'll get copies with
>"list1-owner" and "list2-owner" in the return path. Only Majordomo
>could conceivably see that "user@host" is on both lists (and only if
>the addresses are identical) and contruct a temporary list with only
>the unique addresses. But then how would it handle bounces? If
>"user@host" bounced, would list1-owner or list2-owner be notified? Or
>would you set something up to notify both? Sounds complicated.
Just to clarify, Majordomo already is able to figure this out. I have
lists not going through resend, therefore delivering only one message to
each user. When sending to multiple lists at a time, it correctly bounces
to the appropriate list owners. I have not checked why this is the case,
but it does work!
>OK, then, what if I have a procmail recipe that looks at the envelope
>return path to properly file list mail? Then the addresses *are*
>duplicates after expansion, but I *still* want both copies because the
>headers are different.
This can easily be changed to use the to line to file the message,
avoiding this problem.
Jonathan
Follow-Ups:
References:
|
|
