Bug 63842 - Subject line mangling is turned on by default.
Subject line mangling is turned on by default.
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: mailman (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-19 07:45 EDT by David Woodhouse
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-03-13 18:05:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2002-04-19 07:45:47 EDT
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 18:05:27 EST
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 08:39:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.