Re: GNU Mailman settings for this list

[Dmitry Alexandrov]

Ian Kelling <iank@fsf.org> wrote:
> Dmitry Alexandrov <321942@gmail.com> writes:
>> Well.  At least, I hope his list would not be as broken technically as this 
>> is used to be: before the last downtime it chucked out HTML parts, so 
>> signatures became invalid.  When the issue was brought up half a year ago, 
>> Ian Kelling <sysadmin@gnu.org> said he was about to look into it when doing 
>> a upgrade [1].  And indeed, something changed: now it does not cut parts 
>> off, but performs a lossy conversion to plain text.
>>
>> So a message composed with a typical out of a box MUA and passed through 
>> this list now have *two* autogenerated parts: one by sender’s MUA and 
>> another by gnu.org’s Mailman, which confuses subscribers [2].  Signatures 
>> are still broken, of course.
>>
>> (That’s besides everything else: mangling ‘from’ field, etc.)
>>
>
> Should Mailman convert text/html parts to plain text? Currently this is set 
> to "yes".

When plain text alternative is already present?  Of course, not.

> There's good and bad things about this setting.

There is no good things about _current_ settings: who needs _two_ autogenerated 
plain text parts?  Goodness of the former settings, when HTML parts was cut 
off, is also doubtful.

> One bad thing is that gpg signatures on html email will be rendered invalid.

Another bad thing that many MUAs have a bad habit of autohardwrapping plain 
text, while being incapable to do that properly (well, generally speaking it’s 
a task unsolvable without AI).  I am tired of sorting out the quoting mess that 
they produce.

> For this list, I think its best to keep that setting on, because html email 
> is a risk of security, software freedom and privacy unless you take very tech 
> savvy measures against it

This is exaggeration.  There is no more security risks than of viewing a page 
on the Web.  As for privacy, there is nothing ‘very tech savvy’ in disabling 
external images; not to say, that many MUAs do that by default nowadays, while 
many email providers, on the contrary, still reveal sender IP (both local and 
public, if differ) in every letter sent.

> and this is not a list we should expect that or expose people to that.

Neither are able to protect them: if someone would like to send a malicious 
message to a list subscriber, you could do noting to prevent him.

> Lots of people reading this list like me, have their email client set to 
> convert any html email to plain text.

And lots of people, like me, prefer to see what was actually sent by an author, 
not a result of lossy conversion.

> Mangling the from field happens when someone sends from a strict DMARC domain 
> (a newish email security standard that is not widespread), because mailman 
> modifies all messages to add the subject prefix and footer

Yes, I am aware of that.  That why I was glad, when you said that they would go 
away after upgrade.  And disappointed, when they did not.

> and by that standard, it has to change the From line. Plain text conversion 
> is also a message modification that requires the change. Subject prefixes and 
> footers provide valuable information, especially to users who are not 
> familiar with email lists, eg: someone signs up for this list, new messages 
> appear in their inbox, but they can't tell its from the list

Of course, he can: they normally have a libreplanet-discuss@libreplanet.org in 
either ‘to’ or ‘cc’.

> or how to filter them or how to turn it off.

Then he would do what he usually does when meet a technical difficulty: either 
google or ask.

While providing him with tag in a subject and instructions in footer is nothing 
else but teaching him a wrong practice, most prominent downsides of which 
you’ve just outlined.  In the best case, he will have to learn the proper way 
nevertheless when encounters a list that does not do it, in the worst — will 
demand from that other list to support the bad practice too.

> For users who are familiar with mailing lists, or are sending patches, they 
> should generally be turned off, and we are turning them off for a lot of 
> lists, but for this list, its more important to have settings that are most 
> helpful to new users.

I believe, users new to mailing lists should be introduced to a pristine 
system, not a system full of quirks.

If we want to be helpful to new subscribers, why do not explain how to 
unsubscribe from a list or filter it in a welcoming message?  Mailman on 
gnu.org does send a pretty useless welcoming message to any new user anyway, 
does not it?

> I'm not sure, but the footer might also invalidate mime gpg signatures.

No, it should not.  Are my signatures invalid?

It does invalidate DKIM signatures, if a body is signed too, though.  And yes, 
this practice exists and there are all chances that it will become more 
widespread in the future.

By the way, IIRC, there was complaints, that messages of this list tend to be 
classified by major email providers as spam more often than those of other 
lists @gnu.org.  Despite that DKIM per se is not intended as antispam measure, 
the massive flow of mail with DKIM signatures invalidated due to subject 
tagging, HTML excising and adding footer might be the reason nevertheless.  Who 
knows what proprietary spam classifier might found shady?

> If that is the case, it means to send gpg signed mail to this list, you need 
> to send inline, not mime. And it will always need to be plain text.

(sarcasm-mode +1)
Which would undoubtedly make this list much more user-friendly!  That was the 
goal, is not it?
(sarcasm-mode -1)

In short, I propose to refrain from _any_ mangling of messages.

signature.asc
Description: PGP signature