[Mailman-Users] email headers, follow-up

Ed Lazor osmosis at atfantasy.com
Fri Feb 9 22:21:17 CET 2001


Since my post the other day, I've been getting a lot of personal email 
asking how to remove the extra headers in the most recent version of 
Mailman.  I've responded individually to help as much as possible, but 
maybe it's time I posted something to the mailman users list.

In addition, some of the responses I received make me think I should 
clarify a few things.

A bunch of developers, including those publishing Mailman, are trying to 
improve email on the Internet by adding features.  Additional headers are 
part of these new features and you begin to see them after upgrading to the 
most recent version of Mailman.

For everyone to benefit from these new features, they must first become a 
standard.  A proposal for this standard has been presented and, according 
to Roger B.A. Klorese, it's called RFC822.  This proposal must be accepted 
and implemented by a large portion of people across the Internet to become 
a standard.

The authors of Mailman have shown their support by adding these features to 
Mailman.  I think this is wonderful and I support this.  At the same time, 
please don't make me turn around and force this upon others.  Let everyone 
make their own choice.  You can do this by having support for these new 
features in Mailman and making their use optional.

In this way, you show support for the proposed standard.  You give people 
the chance to upgrade their email clients at their leisure.  You also avoid 
situations where end-users are called overly sensitive simply because they 
don't want to see the new headers.

Forcing change meets resistance.  Offering new optional features opens the 
eyes of curiosity and wonder.

I'm sure everyone here appreciates the idea of the Open Source.  One of the 
fundamental concepts of Open Source is empowering people with tools they 
can use in any way they choose.

I was lucky, because I was able to go in and modify one of the source files 
and remove the extra headers (I hope I did it right, because it was the 
first time I've even seen Python).  I'm trying to help people by presenting 
those changes here.  The  attitudes displayed by some on this list make me 
feel as if I'm going around someone by doing this.

Please understand that I do support the standard.  I also support the Open 
Source idea of presenting people with options so they can do what they 
want.  If the developers of Mailman could make these changes optional and 
part of the standard distribution, it would be absolutely wonderful!

-Ed


$base/Mailman/Handlers/CookHeaders.py

# Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
"""Cook a message's Subject header.
"""
import string
import re
import urlparse
from Mailman import mm_cfg

def process(mlist, msg, msgdata):
# Mark the message as dirty so that its text will be forced to disk next
# time it's queued.
msgdata['_dirty'] = 1
# Set the "X-Ack: no" header if noack flag is set.
if msgdata.get('noack'):
msg['X-Ack'] = 'no'
# Because we're going to modify various important headers in the email
# message, we want to save some of the information in the msgdata
# dictionary for later. Specifically, the sender header will get waxed,
# but we need it for the Acknowledge module later.
msgdata['original_sender'] = msg.GetSender()
subject = msg.getheader('subject')
adminaddr = mlist.GetAdminEmail()
fasttrack = msgdata.get('fasttrack')
if not msgdata.get('isdigest') and not fasttrack:
# Add the subject prefix unless the message is a digest or is being
# fast tracked (e.g. internally crafted, delivered to a single user
# such as the list admin). We assume all digests have an appropriate
# subject header added by the ToDigest module.
prefix = mlist.subject_prefix
# we purposefully leave no space b/w prefix and subject!
if not subject:
msg['Subject'] = prefix + '(no subject)'
elif prefix and not re.search(re.escape(prefix), subject, re.I):
msg['Subject'] = prefix + subject
#
# get rid of duplicate headers
del msg['sender']
del msg['errors-to']
msg['Sender'] = msgdata.get('errorsto', adminaddr)
msg['Errors-To'] = msgdata.get('errorsto', adminaddr)
#
# Mark message so we know we've been here
# msg.headers.append('X-BeenThere: %s\n' % mlist.GetListEmail())
#
# Add Precedence: and other useful headers. None of these are standard
# and finding information on some of them are fairly difficult. Some are
# just common practice, and we'll add more here as they become necessary.
# A good place to look is
#
# http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html
#
# None of these headers are added if they already exist
# if not msg.get('x-mailman-version'):
# msg['X-Mailman-Version'] = mm_cfg.VERSION
# Semi-controversial: some don't want this included at all, others
# want the value to be `list'.
if not msg.get('precedence'):
msg['Precedence'] = 'bulk'
#
# Reply-To: munging. Do not do this if the message is "fast tracked",
# meaning it is internally crafted and delivered to a specific user.
# Yuck, I hate this feature but enough people want it that we should
# support it as an option.
if not fasttrack:
xreplyto = None
# Set Reply-To: header to point back to this list
if mlist.reply_goes_to_list == 1:
xreplyto = msg.get('reply-to')
msg['Reply-To'] = mlist.GetListEmail()
# Set Reply-To: an explicit address
elif mlist.reply_goes_to_list == 2:
xreplyto = msg.get('reply-to')
msg['Reply-To'] = mlist.reply_to_address
# Give the recipient some ability to un-munge things.
if xreplyto:
msg['X-Reply-To'] = xreplyto
#
# Add list-specific headers as defined in RFC 2369, but only if the
# message is being crafted for a specific list (e.g. not for the password
# reminders).
if msgdata.get('_nolist'):
return
#
# Pre-calculate
listid = '<%s.%s>' % (mlist._internal_name, mlist.host_name)
if mlist.description:
listid = mlist.description + ' ' + listid
requestaddr = mlist.GetRequestEmail()
subfieldfmt = '<%s>, <mailto:%s?subject=%ssubscribe>'
listinfo = mlist.GetScriptURL('listinfo', absolute=1)
#
# TBD: List-Id is not in the RFC, but it was in an earlier draft so we
# leave it in for historical reasons.
headers = {}
#
# First we delete any pre-existing headers because the RFC permist only
# one copy of each, and we want to be sure it's ours.
for h, v in headers.items():
del msg[h]
# Wrap these lines if they are too long. 78 character width probably
# shouldn't be hardcoded. The adding of 2 is for the colon-space
# separator.
if len(h) + 2 + len(v) > 78:
v = string.join(string.split(v, ', '), ',\n\t')
msg[h] = v
#
# Always delete List-Archive header, but only add it back if the list is
# actually archiving
del msg['List-Archive']
# if mlist.archive:
# value = '<%s>' % urlparse.urljoin(mlist.web_page_url,
# mlist.GetBaseArchiveURL())
# msg['List-Archive'] = value





More information about the Mailman-Users mailing list