On 2006-04-27 at 22:46-05 Brad Knowles <brad(a)stop.mail-abuse.org> wrote:
> At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:
>
> > Again from RFC 2822 3.6.2, the Sender: header should contain the
> > address of the agent responsible for transmitting the message,
> > meaning that a person who sends mail to the address in that header
> > should expect to reach said agent, not suggest to Mailman that a
> > message bounced.
>
> Right. Mailman is the agent responsible for transmitting the
> message, and this needs to be reflected.
This is not correct. Quoting RFC2822 section 3.6.2:
3.6.2. Originator fields
The originator fields indicate the mailbox(es) of the source of
the message. The "From:" field specifies the author(s) of the
message, that is, the mailbox(es) of the person(s) or system(s)
responsible for the writing of the message. The "Sender:" field
specifies the mailbox of the agent responsible for the actual
transmission of the message. For example, if a secretary were to
send a message for another person, the mailbox of the secretary
would appear in the "Sender:" field and the mailbox of the actual
author would appear in the "From:" field.
The Sender header should be employed by the orignator of the message,
and only the originator. Mailman is not the originator of a message
sent to a list; it is merely a relay agent.
I will grant that the phrasing of the RFC is suboptimal here--it uses
"transmission" when a better word choice would have been "submission".
But the immediately proceeding example (of a secretary sending mail on
behalf of another person) clarifies the intent beyond any claim of
ambiguity.
> [Outlook's behavior] is an MUA problem. See FAQ 2.3.
No, it's not. As much as it pains me to say it, Outlook's behavior
matches perfectly the intent of the RFC. It is Mailman's behavior of
rewriting the Sender header that is the problem.
> However, we want to make sure to capture any potential messages that
> may be routed to the "Sender:" field and have them automatically
> processed through the part of the system that is designed to do that
> sort of thing.
Mailman's "processing" behavior is to treat a reply to the Sender as a
bounce. This is incorrect behavior, because many mail clients will
include address of the Sender header in a "reply-to-all" function,
causing Mailman to treat the reply as a bounce.
So, in summary, the disadvantages of Mailman's behavior of rewriting
the Sender header is that doing so is not in the intended spirit of
RFC2822, causes subscription grief, and breaks Outlook. The advantage
is that it helps Mailman detect bounces from a slim minority of
brain-dead MTAs that send bounces to the Sender header.
> The problem is that you said you wanted to implement an option to
> allow people to turn it off, not to rip this feature completely out
> of the system.
I would argue that the best course of action is to excise Sender
header rewriting entirely and provide no option to turn it on.
(Mailman has way too many options already.)
If, however, an option is created to control the behavior, it should
definitely default to OFF (no Sender header rewriting), not on.
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
Hello,
can someone point me to the procedure/documents needed to assign copyright
to Barry^H^H^H^H^H the FSF ? I can't find them on Google or on the GNU
project pages (??).
-- Fil
I think I've finally gotten a grasp of the new Mailman logging scheme
and I think there's something missing.
I see how the basic logging to files works and how the propagate flag
to loginit.initialize() controls propagation to the root 'mailman'
logger which logs to the sys.stderr stream.
What I think is missing is something analogous to the old
Mailman.Logging.Utils.LogStdErr() to cause writes to sys.stderr to be
logged instead of or in addition to being sent to the stderr stream.
The end result of this is that a few messages from bin/mailmanctl and
one message from bin/qrunner will only go to the stderr stream and
will not be logged. I don't see this as serious as I think all these
messages can only occur in response to fatal conditions in direct
response to a mailmanctl command.
However, there are also sys.stderr writes in the various scripts
invoked by the mail wrapper. These used to be logged as well as
written to the stderr stream (where they presumably end up in a DSN).
The error conditions that cause these messages occur because of bad
alaises or routers in the MTA (things that invoke the wrapper without
a list name) or aliases left after a list is removed. These should
probably still be logged.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
To reopen an old discussion:
I would like to request that a feature be added in the next version of
Mailman to allow a list administrator to disable rewriting of the
"Sender:" header, or (better) for this behavior to be eliminated from
Mailman altogether.
Rationale:
- Outlook treats the Sender field as a person sending on behalf of
another. This seems to me to be a reasonable interpretation of the
Sender field, per RFC 2822 3.6.2. When a "bounces" address is included
in the sender field, Outlook displays something along the lines of "From
listname-bounces+jim=reader.domain.com(a)mailman.server.com On behalf of
fred(a)poster.domain.com". (See Mailman FAQ entry 2.3). This is undesirable.
- Thunderbird also displays the sender field, which presents similar
confusion.
- Useful information (the original content of the Sender: header) is
lost by doing this.
- Bounces go to the envelope sender or Return-Path: header, not the
Sender: header, so this is not necessary for proper bounce handling.
- Again from RFC 2822 3.6.2, the Sender: header should contain the
address of the agent responsible for transmitting the message, meaning
that a person who sends mail to the address in that header should expect
to reach said agent, not suggest to Mailman that a message bounced.
- Information regarding interacting with the list is provided by the
List-* headers; including it in the Sender: field is unnecessary.
Removing this (IMO) unwanted functionality is trivial:
diff -ru mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py
mailman-2.1.5/Mailman
/Handlers/SMTPDirect.py
--- mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py 2004-01-22
17:02:07.0000
00000 -0600
+++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py 2006-04-26
13:48:45.0000
00000 -0500
@@ -348,9 +348,9 @@
# the Sender header at all. Brad Knowles points out that MTAs tend to
# wipe existing Return-Path headers, and old MTAs may still honor
# Errors-To while new ones will at worst ignore the header.
- del msg['sender']
+ # del msg['sender']
del msg['errors-to']
- msg['Sender'] = envsender
+ # msg['Sender'] = envsender
msg['Errors-To'] = envsender
# Get the plain, flattened text of the message, sans unixfrom
msgtext = msg.as_string()
Clytie Siddall wrote:
>
>Weird. I used the latest .pot for Mailman, so the headers _should_ be
>correct. I can't see how msgmerge can have changed that: it only
>matches translations to original text. If the templates need to be
>there in the installed system, I'll have to fix this. <sigh> But I'd
>still like to know how it happened. :(
I don't know. The mailman.pot does have the spaces between '#:' and the
path. msgmerge on my Cygwin test installation actually will put the
space in between '#:' and the path even if it isn't there in the
original mailman.po file, but if there are different msmerges out
there that exhibit different behavior, perhaps bin/po2templ.py needs
to be updated to account for differing formats.
In my case, I think the problem could be addressed by reordering
messages/Makefile.in to run msgmerge on the mailman.po before
po2templ.py and installing the templates, but if there are different
msgmerge behaviors, that wouldn't work for everyone. We'd need to
update po2templ.py.
It shouldn't be difficult to work up a patch to po2templ.py (using re)
that would make it more robust in this area. I'm willing to do that,
but I may not have time to get to it for a few days.
>Your next mail:
>
>> There is no entry for Vietnamese in the add_languages() statements in
>> Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT
>> entries in Defaults.py.in in the trunk.
>
>Who should add such entries? Should I? If so, please tell me what I
>should do.
The comments in Defaults.py.in say in part
# Vgg: Language descriptions and charsets dictionary, any new supported
# language must have a corresponding entry here.
I think this means it's up to the translator to put it there, but I'm
not really familiar with Mailman i18n procedures.
If you look at Defaults.py.in in the trunk and in the Release_2_1-maint
branch (they're different in this respect) at the very end of the
file, it should be obvious what to do.
>Is this analagous with adding a language code to the ALL_LINGUAS line
>in configure.in or configure.ac ?
No, not really.
configure.in contains commands to build ALL_LINGUAS by listing the
messages directory and selecting all subdirectory names of form '..'
and '.._..'.
The entries in Defaults.py are the same language codes, but they
contain the 'name' of the language (e.g., _(Vietnamese)), and the name
of the character set for the language.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
As of revision 7877 to Mailman/loginit.py, log file messages lack a
terminating newline. Adding one to FMT as in
FMT = '%(asctime)s (%(process)d) %(message)s\n'
fixes the problem.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
The recent 'mmshell' change to bin/Makefile.in causes a problem in
Cygwin (I really have to make a 'real' test platform one of these
days, but that's another story).
The change adds
for f in $(LN_SCRIPTS); \
do \
rm -f $(DESTDIR)/$(SCRIPTSDIR)/$$f; \
(cd $(DESTDIR)/$(SCRIPTSDIR); $(LN_S) mmshell $$f); \
done
This should really be
for f in $(LN_SCRIPTS); \
do \
rm -f $(DESTDIR)$(SCRIPTSDIR)/$$f; \
(cd $(DESTDIR)$(SCRIPTSDIR); $(LN_S) mmshell $$f); \
done
DESTDIR is normally null and SCRIPTSDIR is $(prefix)/bin. With the
extra slash, this creates a path that on Cygwin winds up looking in my
case like '//cygdrive/f/test-mailman/bin'. Normally, the doubled slash
wouldn't matter, but /cygdrive/f is not a real directory, it is a
magic construct that refers to the root of the F: drive, and
//cygdrive/f doesn't work.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Not quite. http://new.openspf.org/FAQ/Envelope_from_scope
Neal Groothuis wrote:
> Bob Puff@NLE wrote:
>
>> Don't forget to consider things like SPF, which I think uses the
>> sender field. Whatever is used for SPF _must_ be the domain of the
>> mailman box, or you're gonna run into a pack of trouble.
>
>
> SPF is based on the client name presented in the HELO command in an SMTP
> transaction and the return path, as given in the MAIL command. The
> Sender: field is not used.
For a while now, I've been trying to implement several project
management improvements for Mailman, so that future development can be
opened up to more people. As Tokio's and Mark's work has shown, there
are very talented programmers out there that can contribute great stuff
to Mailman if given a chance. Folks like Brad, JC, and Terri have also
contributed greatly in ways other than with code, and I'd like to make
it easier for others like them to help out.
With 2.1 in maintenance mode, planning for 2.2 gearing up, and my desire
to once again jump start 3.0 work, we need all the help we can get.
While I'm still working on some things, there have been some good
developments that I wanted to let you know about. First, Atlassian has
offered free licenses and hosting for their excellent products Jira
(issue tracker) and Confluence (wiki). I've used both for several years
now and I think they are top-notch applications; Jira is definitely one
of the best issue trackers I've used.
The wiki is now live, although not a lot of content has been moved
there. Please see <http://wiki.list.org>. You can browse the wiki
anonymously, but you must sign up to make any additions or changes. I
would eventually like to move things like the Mailman FAQ, list of
Mailman users, online documentation (where it doesn't overlap with the
latex docs), and all community contributed content from the main web
site to the wiki. If you've been looking for a way to contribute to
Mailman that doesn't involve coding, here's your chance!
While Jira is live, there's nothing yet there. I've done only the
minimal configuration for the issue tracker, but have not yet even set
up any projects. Still, you can go to <http://bugs.list.org> to sign up
or get a feel for the basics. Right now, I'm working on a conversion
script that will take the SourceForge tracker data and massage it into a
form that Jira can import. My plan is to move all issue tracking to
Jira from SF's trackers.
One option to getting there faster is to just start Jira from scratch --
i.e. not import the SF issues. We could say that all 2.2 and 3.0 bugs
and patches must go to Jira, but that 2.1 bugs would stay on SF. Then,
when 2.1 is retired, we'd retire the SF tracker (that may not be for a
long time though, given how pervasive 2.1 is). I'm interested in
getting opinions about whether we should migrate all issues to Jira now,
split the issues as described above, or take some other approach.
Now that Mailman 2.1.8 is out, I've gone ahead and converted the SF CVS
repository to Subversion. You can checkout the entire tree via
<https://svn.sourceforge.net/svnroot/mailman> but understand that that
will checkout /everything/ (trunk, tags, branches, etc). If you just
want Mailman 2.1, you can check out
<https://svn.sourceforge.net/svnroot/mailman/branches/Release_2_1-maint>, or if you just want the trunk (2.2) you can check out <https://svn.sourceforge.net/svnroot/mailman/trunk>. You should no longer be able to check anything into the CVS repository. Not everyone who had write permission to CVS has been given Subversion write access. If you still need write access to Subversion and don't have it, please let me know.
Now that the conversion is complete, I plan on doing some repo house
cleaning, such as moving the website stuff out of the main directory.
After that, we can decide to leave the Subversion repository on
SourceForge, or move it to Atlassian's hosting. The latter gives us the
ability to control write permissions per directory and a hook to Fisheye
for repo browsing through the web. Even if we want to move, we don't
need to do that right away, as an svn dump/restore should do the trick.
Now that these changes have been made, I think it's time to start
planning for Mailman 2.2. To that end, I would like most development
artifacts to be recorded in the wiki, although discussion should still
happen on mailman-developers (there's a 'Development' space and a link
for 2.2 under that). I also plan on getting our data imported into
Rosetta so we can coordinate i18n there; it's mostly my fault I've
dropped the ball on this one.
Longer term, as we begin to restart Mailman 3 development, all those
decisions will go in the wiki too. I have some other thoughts about
Mailman 3 that I'd like to get feedback on, but as this message is
getting fairly long anyway, I'll defer that for the time being.
So in summary, please check out the wiki. Let me know what you think
about importing the SF issues into Jira. And check out the Subversion
repository.
-Barry
Hi Barry,
I had some hours playing with the new svn trunk. (I was a little bit
busy because our academic year begins April.)
bwarsaw(a)users.sourceforge.net wrote:
> Revision: 7858
> Author: bwarsaw
> Date: 2006-04-16 21:08:17 -0700 (Sun, 16 Apr 2006)
> ViewCVS: http://svn.sourceforge.net/mailman/?rev=7858&view=rev
>
> Log Message:
> -----------
> - Convert all logging to Python's standard logging module. Get rid of all
> traces of our crufty old Syslog. Most of this work was purely mechanical,
> except for:
I get this for a fresh install of svn trunk. You may have old install
remained, if you haven't experienced this.
% bin/mailmanctl start
Traceback (most recent call last):
File "bin/mailmanctl", line 112, in ?
from Mailman.Logging.Syslog import syslog
ImportError: No module named Logging.Syslog
Also, if you send SIGHUP to reopen the logs, only the last reopen
messages is recorded because each runners try to reopen the log file.
We may have to restart qrunners if mailmanctl receive SIGHUP and it has
started new log files. We may also utilize the backupCount feature for
log rotation (intruducing LOG_BACKUP_COUNT in Defaults.py).
>
> 1) Initializing the loggers. For this, there's a new module
> Mailman/loginit.py (yes all modules from now on will use PEP 8
> names). We can't call this 'logging.py' because that will
> interfere with importing the stdlib module of the same name (can
> you say Python 2.5 and absolute imports?).
>
> If you want to write log messages both to the log file and to
> stderr, pass True to loginit.initialize(). This will turn on
> propagation of log messages to the parent 'mailman' logger, which
> is set up to print to stderr. This is how bin/qrunner works when
> not running as a subprocess of mailmanctl.
>
> 2) The driver script. I had to untwist the StampedLogger stuff and
> implement differently printing exceptions and such to log/error
> because standard logging objects don't have a write() method. So
> we write to a cStringIO and then pass that to the logger.
>
> 3) SMTPDirect.py because of the configurability of the log messages.
> This required changing SafeDict into a dict subclass (which is
> better than using UserDicts anyway -- yay Python 2.3!). It's
> probably still possible to flummox things up if you change the
> name of the loggers in the SMTP_LOG_* variables in mm_cfg.py.
> However, the worst you can do is cause output to go to stderr and
> not go to a log file.
>
> Note too that all entry points into the Mailman system must call
> Mailman.loginit.initialize() or the log output will go to stderr
> (which may occasionally be what you want). Currently all CGIs and
> qrunners should be working properly.
>
> I wish I could have tested all code paths that touch the logger, but
> that's infeasible. I have tested this, but it's possible that there
> were some mistakes in the translation.
>
> - Mailman.Bouncers.BounceAPI.Stop is a singleton, but not a class
> instance any more.
>
> - True/False code cleanup, PEP 8 import restructuring, whitespace
> normalization, and copyright year updates, as appropriate.
>
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/