I've had a request from a list member who would like us
to add a subject prefix to all the lists on our server
(mail.gnome.org), as his mail client can't do any kind
of automatic filtering. We are obviously reluctant to
change the status quo, as many people (e.g. PDA/mobile
users) would then respond asking us to remove them.
Instead, I decided to file this feature request to make
it (per-subscription) configurable. It would have one
of three possible values; use the default list setting,
override on or override off. This would allow users to
please themselves, and in some cases overcome problems
caused by limitations in their mailclient.
Logged In: YES
user_id=67709
This should be submitted as Feature Request.
BTW, many mailing list users are happy with subject
prefixes. Why not GNOME users? ;-)
Logged In: YES
user_id=20872
Some lists use prefixes, some don't. Some users that
subscribe to many lists want consistency, but we don't want
to have to determine and enforce a site-wide policy and deal
with all the ensuing arguments. This feature shifts the
decision from the list/site managers to the individuals
users. Basic headache prevention.
The main argument for prefixes seems to be 'I can quickly
identify what the mail is about in my inbox', where users
haven't got or don't use their client's header filtering
features.
The main argument against prefixes seems to be 'I just get a
screenful of list prefixes when I try to view my list
folders', where users are trying to use mail clients in a
low screen resolution (e.g. old VGA screen, palm/PDA device,
mobile phone, small desktop window whatever).
Sorry for misfiling it. Haven't used SF for a while -
forgot that feature requests and bugs aren't mixed like in
bugzilla.
Logged In: YES
user_id=29401
Originator: NO
Nothing seems to have happened with this in the last 3 years. I just saw this conflict come up again on the Subversion mailing list, and it seems to come up regularly on any list that has the prefixes disabled (my personal preference).
Before I start looking at the code, are there any design constraints that argue against implementing this, or implementing it in a particular way?
Logged In: YES
user_id=29401
Originator: NO
It looks like the default subject prefix mangling happens in the main pipeline after the message is accepted, in CookHeaders. Per-user processing (like VERP) appears to be done in the queue runners. I guess OutputRunner would need to be the one to do this, and would need to break up the recipient list into groups based on what per-recipient munging needs to be done.
Logged In: YES
user_id=1123998
Originator: NO
This discussion should continue on Mailman-Developers@python.org <http://mail.python.org/mailman/listinfo/mailman-developers>.
Please keep in mind that this is unlikely to be accepted for the 2.1 maintenance branch, primararily because of the changes to user options and the corresponding i18n implications.