Mailman-Developers April 2006

mailman-developers@python.org

18 participants
21 discussions

by James Ralston

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

14 years, 10 months

GNU FSF Assignment

by Fil

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

14 years, 10 months

New Mailman logging

by Mark Sapiro

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

14 years, 10 months

Sender field

by Neal Groothuis

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()

14 years, 10 months

Re: [Mailman-Developers] Problems with Vietnamese translation

by Mark Sapiro

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

14 years, 10 months

Log messages run together

by Mark Sapiro

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

14 years, 10 months

Problem with new bin/Makefile and Cygwin

by Mark Sapiro

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

14 years, 10 months

Re: [Mailman-Developers] [Mailman-Users] Sender field

by Bob Puff＠NLE

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.

14 years, 10 months

New Mailman wiki, Subversion (and other stuff)

by Barry Warsaw

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

14 years, 10 months

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7858] trunk/mailman

by Tokio Kikuchi

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/

14 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers April 2006