[Mailman-Users] Avoiding mangling in Mailman 3?

[Stephen J. Turnbull]

Allan Hansen writes:

 > 1. Replace the From: address with a no-reply address on the list
 >    server. Don’t add the sender’s address in quotes.

I believe this requires a change in the Mailman code.

I guess you want the author's display name, if available, there?  What
if there is no display name, or it doesn't identify the author?  I
guess the best play would be the mailbox of the author.

How about "mailbox AT domain.com"?  I guess some nontechnical users
might just copy that to an address field with less than amusing
results, but it might be useful in manual lookups in address books,
since most clients do not display Reply-To.

 > 2. Keep the ‘Reply-To:’ address as the sender’s address (that’s
 >    what I have it set to now - I don’t want people to reply to the
 >    lists).

I believe this doesn't need a change to Mailman.

 > 3. Put HTML mailto: links for ‘Reply to Sender’ and Reply to List’
 >    at the bottom of the message.

A mailto link for the list is configurable.  However, the link for
author would require changes to Mailman code I'm pretty sure.  Also,
as explained below, it's probably very unreliable and unattractive to
try to use links to simulate a mail client's reply function.

First of all, users expect a reply function to copy the text of the
original.  mailto URLs don't provide a facility for that.  We would
have to add code to copy the text to the URL.  I'm not sure how
typical clients would react to that, and if the original is plain
text, the message's whole text would be visibly duplicated in the
footer of the message distributed to subscribers, which would likely
be displayed as is by most clients.  This would be pretty distressing
to most subscribers, I think.  Also, I expect most clients use the DOM
they have constructed to display the original mail to populate replies
they construct themselves, but Mailman can't know about that.  Users
may not be pleased with replies constructed from a mailto URL; in
particular, it would not be displayed or transmitted as copied, but
rather as original text.

Second, users expect replies to preserve threading.  This would mean
adding References or at least In-Reply-To header fields to the mailto
URLs.  This would be straightforward to implement, but would result in
large, unreadable plaintext footers, if some users are sending
plaintext mail.  (Though it wouldn't be as bad as if you tried to
include the original text in the reply's composition window, I imagine
you'd get complaints.)  Again, I'm not sure how typical clients would
deal with it, whether they would follow the RFCs or screw up.

Third, if you mean "links as HTML" rather than "insert URLs
somehow", this is rather problematic.  HTML mail is a minefield.
There are standards, but in practice they're all violated by one
client or another.  Manipulating HTML before forwarding to the
subscribers is very likely to have bad side effects for some mail
composed by some clients.

You're also not guaranteed that all the subscribers even use HTML
mail, in which case even if added as HTML, in those messages you'd
have all the ugliness described above.

Steve