Bug 63842

Summary:	Subject line mangling is turned on by default.
Product:	[Retired] Red Hat Linux	Reporter:	David Woodhouse <dwmw2>
Component:	mailman	Assignee:	John Dennis <jdennis>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-03-13 23:05:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Woodhouse 2002-04-19 11:45:47 UTC

The default for new lists is to turn on the misguided addition of [LISTNAME] to
the subject of every mail sent out, ostensibly for the purpose of allowing
people to filter list mails.

Filtering on anything but the SMTP reverse-path is unreliable and will give
false positives. Adding crap to the _Subject_ line simply serves to hide the
real information that the original sender put there. This option should be off
by default.

The behaviour of reply_goes_to_list option is far saner - it is turned off by
default and the help text explains why it's a stupid idea to turn it on. The
subject_prefix option should be handled similarly - not only should it be empty
by default for new lists, but the help text should explain why it is
undesirable. Something along the lines of...

"This text will be prepended to subject lines of messages posted to the list. By
adding noise to the subject lines, the real information therein is made more
difficult to read, and therefore it is <I>strongly</I> recommended that this is
left blank for most mailing lists. <P>
Some people have been known to use the addition of the list name to the subject
line as a way of filtering list mails. This practice is unreliable, and far
better filtering can be achieved by checking the SMTP reverse-path (usually the
Return-Path or Sender headers in the delivered mail)."

Comment 1 John Dennis 2003-03-13 23:05:27 UTC

Defaults are in the realm of religion, some people like the default the way it
is.  My general inclination as a package maintainer is not to change the
upstream sources unless there is a compelling reason and the upstream sources
have this on by default. Given that it is trival to change the default in
mm_cfg.py to your own individual preference its hard for me to see the choice of
a default as a bug. As it turns out I'm in your camp, I happen not to care for
this default either, its just that this isn't a bug IMHO.

BTW, mailman now adds List-Id to the headers which is an excellent way for users
to filter.

Comment 2 David Woodhouse 2003-03-14 13:39:20 UTC

I'll accept the argument that we shouldn't change the default, albeit grumpily
-- leaving it on by default means that admins who _don't_ think about it will
leave it on, rather than only those who are dim enough to actually think it's a
good idea.

But I certainly wouldn't advocate filtering on List-ID. That has false positives
when a mail _originally_ sent via a list is received via other means -- either
by _another_ list which doesn't add its own List-ID or more likely if an
important mail is bounced _directly_ to a recipient known not to be paying much
attention to the list at the moment.

If I know you're on vacation and you're going to read the list with the 'd' key
on your return, and I see a mail on the list and hit 'b' in pine to bounce it to
you so it ends up in your inbox and you actually _see_ it...

Does it end up in your inbox and actually get read, or does it hit a false
positive because you're filtering on List-ID: and still end up in the list
folder with the original?

The only reliable filtering method that I've found is the SMTP reverse-path,
usually in a 'Return-Path:' header of the delivered mail.