Mailman 3 July 1999 - Mailman-Developers

Re: [Mailman-Developers] patch candidate for MailList.Save()
by Harald Meland 20 Jul '99

20 Jul '99

[Barry A. Warsaw] > The idea is that the marshal is first written to a temp file called > config.db.tmp.<mypid>. If this succeeds completely, then > > 1) config.db.last is unlinked > 2) a hard link config.db.last -> config.db is created > 3) a hard link config.db -> config.db.tmp.<mypid> is created > 4) config.db.tmp.<mypid> is unlinked > > Comments? You missed 2.5) config.db is removed which constitutes a race condition -- I think the below patch fixes that (but as you say, this really is crucial code to get right, so I'm posting it here for others to comment before committing): Index: MailList.py =================================================================== RCS file: /export/public/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.130 diff -u -r1.130 MailList.py --- MailList.py 1999/07/18 17:26:55 1.130 +++ MailList.py 1999/07/19 15:09:08 @@ -759,6 +759,8 @@ fname = os.path.join(self._full_path, 'config.db') fname_tmp = fname + '.tmp.' + `os.getpid()` fname_last = fname + ".last" + # Make config.db unreadable by `other', as it contains all the + # list members' passwords (in clear text). omask = os.umask(007) try: try: @@ -771,10 +773,14 @@ 'Failed config.db file write, retaining old state' '\n %s' % `status.args`) Utils.reraise() - # now move config.db -> config.db.last - # then move config.db.tmp.xxx -> config.db - aside_new(fname, fname_last) - aside_new(fname_tmp, fname) + # Now do config.db.tmp.xxx -> config.db -> config.db.last + # rotation -- safely. + if os.path.exists(fname_last): + os.unlink(fname_last) + os.link(fname, fname_last) + os.rename(fname_tmp, fname) +## aside_new(fname, fname_last) +## aside_new(fname_tmp, fname) finally: os.umask(omask) self.CheckHTMLArchiveDir() After this change, the function aside_new() in MailList.py can be removed (or moved to Utils.py), as it isn't being used anywhere else. -- Harald

2 1

mailman & unsubs
by David Ascher 18 Jul '99

18 Jul '99

I subscribe to lots of mailman lists. Sometimes, mailman disables my email address. I have no doubt that it's for a good reason. However, that reason is for a certain group of users fairly temporary (down server). As it stands, I periodically find out that I've been disabled on fairly quiet lists that I don't expect to read every day. It'd be nice if mailman could 'ping' the email address periodically (once a week?) to find out if the problem is resolved. Something progressively more expensive like if ping_ok and SMTP_VRFY_ok and first_email_goes_in_queue_goes_through: undisable_email() would do the job in 96% of the cases w/ low overhead, I suspect. --david

3 2

FW: Returned mail: unknown mailer error 1
by Jeff Hahn 16 Jul '99

16 Jul '99

A mail message with the following To: line generated this error... "To: :" (The following message has been "somewhat" sanitized) -Jeff -----Original Message----- From: Mail Delivery Subsystem [mailto:Postmaster@rikers.streek.com] Sent: Wednesday, July 07, 1999 7:21 AM To: xxx-request(a)xxx.com Subject: Returned mail: unknown mailer error 1 The original message was received at Wed, 7 Jul 1999 07:20:17 -0500 from maillist(a)xxx.xxx.com [xxx.xx.xx.xx] ----- The following addresses had permanent fatal errors ----- "|/home/mailman/MM/mail/wrapper post xxx" (expanded from: <xxx(a)xxx.xxx.com>) ----- Transcript of session follows ----- Traceback (innermost last): File "/home/mailman/MM/scripts/post", line 73, in ? mlist.Post(msg, approved=fromusenet) File "/home/mailman/MM/Mailman/MailList.py", line 1243, in Post if (self.require_explicit_destination and File "/home/mailman/MM/Mailman/MailList.py", line 1081, in HasExplicitDest for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'): File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 320, in getaddrlist return a.getaddrlist() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 496, in getaddrlist ad = self.getaddress() File "/home/mailman/MM/Mailman/pythonlib/rfc822.py", line 533, in getaddress if self.field[self.pos] == ';': IndexError: string index out of range 554 "|/home/mailman/MM/mail/wrapper post xxx"... unknown mailer error 1

2 1

spam control
by Jonathan Clark 15 Jul '99

15 Jul '99

Hi guys, I just tried out mailman for the first time and I like it a lot. I noticed there is some attempt to stop spam crawlers. However, some of the email addresses displayed (like the list owner) are shown in the clear. Here is a little trick I use to allow mailto: to work correctly and at the same time stop spam crawlers from gathering email addresses. Email: <script language="JavaScript"></script> jc at jonathanclark.com <script language="JavaScript"></script> When this is displayed on a browser that has java script turned off, it will only display: "Email: jc at jonathanclark.com" When the end user has javascript on (as most people do), they will see the same thing, but when they click on it they will get the correct mailto: command to launch their mail program. Since crawlers don't execute javascript, they can't collect the name. Generally I don't worry about non java script but I recently turned it off because of those annoying (open-another-window-on-close) tricks people do. I think it would be great if mailman used (or had the option) to use this technique for all email addresses it displayed. Jonathan P.S. I'm not on the list, so cc: me any discussion on this. Thanks!

1 0

Cookies and MSIE 4.x
by Evaldas Auryla 15 Jul '99

15 Jul '99

Hello! It seems like MS Internet Explorer 4.x (except 4.7x for NT) is not following RFC 2109 and storing cookies sent by Mailman _without_ dbl.quotes "". Mailman fails verifying these cookies, because Cookie.py module thinks the incoming cookie does not contain any special chars (not true) as it is _not_ enclosed with dbl.quotes so decoding goes wrong. The consequence is that for the administration of the Mailman over the web you have to re-enter password to authenticate on every page. Annoying. I made a little patch to SecurityManager.py to get around this problem, experienced in Mailman 1.0rc2 and 1.0rc3, (for the Mailman in fact it's a feature, not a bug :-)) and submitted it to the JitterBug database http://www.python.org/mailman-bugs/ . Does anybody had something similar ? Regards -- Evaldas

1 0

Further on jitterbug open/75 - timezone handling in archiver
by Nigel Metheringham 13 Jul '99

13 Jul '99

[Note: there is no way for me as a bug reporter to make a follow up note into the bug report - ie I have fixed/worked round this for myself but am having to put it to the list since I can't add a comment to the bug report...] The problem was that I was seeing a wierd time skew on my archives dating back to the point where DST kicked in (suspicious eh). Basically I had 2 archives for each week - one with the correct date on - ie Monday 12 July and the other with just one or two messages with a duff date on - specifically in this example it would be Monday 13 July The code in HyperArch.py has:- def dateToVolName(self,date): datetuple=time.gmtime(date) It appears the later call to strftime is applying its own localtime rules. This may be a libc oddity - I am not good enough on POSIX to know that. If you change the gmtime call to a localtime then it all works correctly. For the record this is on a Red Hat 6.0 system - so Python 1.5.1, glibc 2.1. This fix will have side effects that your archive roll over changes with the server localtime rather than GMT - I don't know if this is a problem for people. Nigel. -- [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Documentation for config.db file?
by Dan Delaney 12 Jul '99

12 Jul '99

Is there any documentation for the format of the config.db file? Here's my situation. I've written a large database system for the membership information of an organization. Each member of the organization can login to the website with a password and edit his or her own member information (address, bio, password, etc). When a member makes a change to his email address, or when I add a new member, the program automatically makes a change to the majordomo list file, which is simply a text file with the email addresses in it. Well, now that I've switched the list to Mailman, I can no longer do this because I don't know how Mailman stores the subscriber info. I can easily modify a db file with PHP, I just need to know how the info in laid out in the file. Thanks. --Dan ________________________________________________________________________ Dionysos(a)Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html

2 1

Fix for bug "incoming/64"--the prefix replication problem
by Dan Delaney 12 Jul '99

12 Jul '99

Hi all. I just transferred all of my majordomo lists over to Mailman and I must say, it is quite nice. There are a few things I'd like to see in the future, but they would just be icing on the cake. There is only one actual problem I've had. When someone replies to a message and his program prepends "Re: " to the subject, Mailman then adds a NEW list prefix to the subject line every time, even if there is already one somewhere in the subject line, so we end up with something like this: Subject: [MyList] Re: [MyList] Re: [MyList] A few observations After a while, the subject lines accumulate quite a few of those prefixes, which I think is a BIG problem. I was looking at the code in the MailList.py program, and it looks like the code only checks to see if the prefix is already present AT THE BEGINNING of the line before it adds the prefix, thus ignoring the fact that it might be there after a "Re: " or "Fwd: ". Here are the relevant lines from MailList.py: -------------------------------------------------------------------- 1267: # Prepend the subject_prefix to the subject line. 1268: subj = msg.getheader('subject') 1269: prefix = self.subject_prefix 1270: if not subj: 1271: msg.SetHeader('Subject', '%s(no subject)' % prefix) *1272: elif prefix and not re.match(re.escape(self.subject_prefix), *1273: subj, re.I): 1274: msg.SetHeader('Subject', '%s%s' % (prefix, subj)) -------------------------------------------------------------------- The simplest solution to this problem is to replace the "re.match" in line 1272 with "re.search". The difference between the two is that re.match only matches the pattern if it occurs at the BEGINNING of the line, whereas re.search will match the pattern anywhere in the line. I've already tried this in my installation and it works quite well. In this case, after someone sends a message with a subject something like this... Subject: [MyList] Hello there ...all of the following replies, no matter how many there are, will never add another [MyList] prefix because it is already present SOMEWHERE in the subject. Thus all subsequent replies will have the following as their subject: Subject: Re: [MyList] Hello there Now that would be sufficient to at least fix the problem of "subject prefix replication". However, I still am not satisfied with the result because now the prefix is not the FIRST thing in the subject. Being a graphic designer, I am particularly sensitive to the visual aspect of all of this, and to me it would be much more aesthetically pleasing to have the list name tags all lined up in my inbox list of messages, rather than some of them offset four places from the left edge. One way to get around this would be to use an "re.sub" method to actually strip out all occurances of the list tag in the subject line before adding another one to the beginning. That would be great except for one thing: that would lead to the build up of "Re: "s! After a while you would end up with: Subject: [MyList] Re: Re: RE: Re: Hello there So, what you have to do is remove all of the extra "Re: "s as well. Which brings me to another problem: "RE: and FWD: replication", which is a big problem with email in general (especially with all this damn chain-letter spam!). And since the email programs aren't doing their job by cleaning up that crapola, why not have the mailing list manager do it? I wrote a mailing list archive program a while back which does this and it really helps with "threading" the messages based on the subject lines. (In fact, I store the subject without ANY 'Re:'s or 'Fwd:'s so that the subjects will be exactly the same, and I save the fact that it is a reply in a separate field. You can check out the archive if you like at www.LouisvilleTimes.org/harmonet/). Anyway, this would make the following subject line... Subject: Re: [MyList] Re: Fwd: [MyList] Re: Hello there (fwd) ...end up looking like this: Subject: [MyList] Re: Hello there The result is that your list messages always have readable, comprehendable subjects that don't take 5 minutes to decode, AND your list archives are much more functional and easier to browse because messages which REALLY have the same subject won't be bogged down with 'Re:'s and 'Fwd:'s. This is the basic procedure: 1. First, with a regex substitution, strip the subject line of all occurances of the list's subject prefix. 2. Then, using a case-insensitive regex, check to see if the subject BEGINS with "fw: " or "fwd: ", or if it ends with a "(fwd)". If so, set a second prefix variable (prefix2) to "Fwd: " to be added after the first prefix (the one from the list). 3. Next, check to see if the subject line begins with an "re: ". If it does, this takes precedence over the "Fwd: ", so just go ahead and set prefix2 to "Re: " even if it already contains "Fwd: " 4. Next, with a case-insensitive regex substitution, remove ALL instances of "re: ", "fw: ", "fwd: ", and "(fwd)" from the subject. 5. Finally, add both the list prefix and the new prefix2 to the beginning of the subject. So, here's a replacement for the segment of code that I quoted earlier from the MailList.py program which accomplishes this task quite well (I'm using it in my Mailman installation right now): -------------------------------------------------------------------- # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix # If there's no subject, give it one if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: # Delete all occurances of the prefix from the subject if prefix: subj = re.sub(re.escape(self.subject_prefix), '', subj) # Check to see if the message is a reply or forward prefix2 = '' if re.search('^fwd*: |\(fwd\)', subj, re.I): prefix2 = 'Fwd: ' if re.match('re: ', subj, re.I): prefix2 = 'Re: ' # Clean up all that 're:' and 'fwd: ' garbage subj = re.sub('[rR][eE]: | *\(*[fF][wW][dD]*\)*:* *', '', subj) # Set the new subject line in place msg.SetHeader('Subject', '%s%s%s' % (prefix, prefix2, subj)) -------------------------------------------------------------------- Give it a try for a while on your own mailing lists. I think you'll like the results. Cheers. -- Dan ________________________________________________________________________ Dionysos(a)Dionysia.org Daniel G. Delaney www.Dionysia.org/~dionysos/ PGP Public Key: /~dionysos/pgp.html

2 1

Feature Request
by Phillip Porch 12 Jul '99

12 Jul '99

My partner has been administering several lists here under listproc 8.2 and we have been considering moving to mailman as our list server. His main complaint is that he has been using the subscriber file to store extra information about subscribers under listproc but can't under mailman. How difficult would it be to add a freeform text field associated with an email name that would only be accessible to the list owner or site manager? -- Phillip P. Porch <root(a)sco.theporch.com> NIC:PP1573 finger for http://www.theporch.com UTM - 16 514548E 3994397N PGP key

2 1

rc3 check_perms : adm.pw ??
by Ricardo Kustner 11 Jul '99

11 Jul '99

Hi, first of all thanks for adding a permission check script to the new mailman release! :) anyway, after upgrading to rc3, i immediately tried out the permission script just to see if it works... at the end it gives me an error cause it's looking for a ~mailman/data/adm.pw file... but that one doesn't exist anywhere in my mailman tree?? Traceback (innermost last): File "./check_perms", line 164, in ? checkadminpw() File "./check_perms", line 128, in checkadminpw mode = statmode(adminpw) File "./check_perms", line 39, in statmode return os.stat(path)[ST_MODE] OSError: [Errno 2] No such file or directory: '/usr/local/mailman/data/adm.pw' Ricardo. --

1 0