[Mailman-Developers] Feature request: Reply-To Munging etc.

[Sven Anderson]

Stephen J. Turnbull, 06.03.2007 08:25:
> Sven Anderson writes:
> 
>  > 1) Receiver clean-up (if Reply-To munging is NOT used)
>  > So what about an option to clean-up the receivers list in Mailman,
>  > that is Mailman removes all To/CC addresses which are members of
>  > the list?
> 
> IIRC, if the user sets their subscription to "no-dupes", that user's
> address will be removed from the addressee list, as well as from the
> list of addresses that Mailman actually distributes to the post to.

I just checked this to be sure, but only the latter is true. The user's
address stays in the To/Cc header.

And anyway, that's not what I want. I want an option so that the addressee
list is cleaned up, no matter if the users wants duplicates or not. That's
because addressee accumulation is the most heard argument against
reply-to-all usage, which again is needed to live without Reply-To
munging. I claim, that such an option would be very useful not just for me
but for many Mailman administrators, especially for those who don't want
to munge the Reply-To header.

>  > 2) Add non-member-senders to Reply-To (if Reply-To munging IS used)
>  > One of the annoying things using Reply-To munging in open lists is,
>  > that you cannot easily include external authors in replies, whether
>  > you are using reply-to or reply-to-all in your MUA. It would be
>  > nice, if the sender could be added to the Reply-To addresses in the
>  > case, that the sender is not a member of the list, so that replies
>  > automatically go to the list AND the author.
> 
> This is simply not enough.  You need to add all the non-list
> addressees, too.  That is equivalent to (1).

No, that is not true, as the "reply-to-all" function includes all the
addressees already, but the From address is _never_ included, if the
Reply-To is set, neither with simple reply nor with reply-to-all. I'm just
addressing this problem with my proposal, that - if Reply-To is set - the
>From address is not included in _any_ case with a standard conform MUA.

Anyway, I refined my ideas in the meantime, and I will try to write them
down in a further email tonight.


Cheers,

Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4840 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20070306/f0f51d4d/attachment.bin