Mailman 3 March 2002 - Mailman-Developers

Mailman can't handle MIME: Content-transfer-encoding: quoted-printable?
by James Madill 14 Mar '02

14 Mar '02

Users of one of my mailing lists got a nasty surprise when a posted message was repeatedly sent to them. I traced the problem down to an instance of the standard End-Of-Message marker (a lone period on a line) in the middle of the posted message. The posted message contained extended ASCII characters encoded using the MIME Content-transfer-encoding: quoted-printable format. There was what appeared to be soft returns at column 72. This message happened to have a paragraph that ended on column 73, so the "soft return" resulted in the period alone on the next line. Sendmail accepted the encoded document for Mailman, but on sending out, Mailman encountered what it thought was an EOM marker and stopped the processing of the message at that point. Unfortunately, there was still plenty of message left to send, so it was not removed from the queue, and Mailman kept on sending the first portion. The smtp daemon is sendmail 8.12.1. Mailman is version 2.0.8 with DELIVERY_MODULE = 'SMTPDirect' in Defaults.py. Am I missing some Mailman switch to tell it to recognize messages with the Content-transfer-encoding: quoted-printable tag? -- James o o o o o o o . . . _______________________ _______=======_T___ o _____ |James Madill | |Duke Univ Med Ctr| >.][__n_n_| D[ ====|____ |james.madill(a)duke.edu| | (919) 286-6384 | (________|__|_[____/____]_|_____________________|_|_________________| _/oo O-O-O ` oo oo 'o^o^o o^o^o` 'o^o o^o` -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- <http://www.duke.edu/~madil001/>

4 3

Is there a stupid Python trick to save me?
by Dan Mick 14 Mar '02

14 Mar '02

I had an interesting thing happen today; a list started to get two footers added to it. Odd. Then I remembered why: I'd defined a pipeline for this list that had an extra module in it (my "BounceImplicit" module that just rejects Bccs; the custom list pipeline contained the old default + Bounce Implicit). But now, Decorate shouldn't be in the pipeline, since it's called by SMTPDirect directly with the latest changes to SMTPDirect. So my pipeline calls it once explicitly and once implicitly. Oops. It occurred to me that if there were some way to have a 'lazy evaluate' in a Python variable, I could maybe work around that, by saying "list.pipeline = mm_cfg.GLOBAL_PIPELINE + 'BounceImplicit' (or something like that) That way, if GLOBAL_PIPELINE changes, I still get the right effect. But I don't know how I might mechanize something like that without hacking the code. Am I smoking something, or is there some stupid Python trick that would allow "dynamic list composition from a value"? (Alternatively, would it be worth having something that allows "add to the pipeline at a defined location" declarations, so that people can add custom modules but still track changes to the source? I realize that as an alpha tester I'm in a bit of a unique situation, but..)

4 4

Re: [Mailman-Developers] Re: [BUG] Users are created as moderated in CVS mailman
by Dan Mick 13 Mar '02

13 Mar '02

> This is okay, but I would still much much prefer it if > DEFAULT_DEFAULT_MEMBER_MODERATION were just set to 0, Barry. Me too. I don't understand changing the default to "a certainly- surprising behavior", even if that behavior is really really attractive to some admins for some lists.

2 1

Re: [Mailman-Developers] Missing footers with latest CVS
by Dan Mick 13 Mar '02

13 Mar '02

> >>>>> "Dan" == Dan Mick <dmick(a)utopia.West.Sun.COM> writes: > > Dan> Installed latest CVS yesterday, and notice now that some > Dan> posters are not getting footers added to their messages. I > Dan> suspect the footer-add-based- on-language code is at fault, > Dan> but I haven't had time to isolate a pattern yet. Anyway, > Dan> consider this Distant Early Warning that that code isn't > Dan> working for some otherwise-untroubled list members. > > Maybe it's working as intended? ;) well, then, how it's intended has a bug. :) > Are they posting messages with a charset that is not the same as the > mailing list's charset? The default charset is us-ascii; I will > hazard a guess that they are posting messages flagged as UTF-8 or > ISO-8859-1 but that are really us-ascii. Well, so, one of them has no charset expressed at all that I can see. > We can add a work around for this, but it will be hard. Not really, if appropriate workaround is "ignore the incoming charset and add this footer unconditionally please".

7 19

Re: [Mailman-Developers] Please Allow Me To Introduce Myself...
by James J. Besemer 13 Mar '02

13 Mar '02

mac(a)wooz.org wrote: > Cool! Since I'm strapped for time right now, I'm just going to > comment briefly. Thanks for the various pointers. Dunno how long before I'll be productive (read Dangerous ;o). > You'd think! I've had a couple of patches contributed that filter out > HTML, but I've not been able to whip them into shape for inclusion. > I've basically given up hope for MM2.1, but will look at it again for > the next release. The problem is that the naive approach isn't > difficult, but for it to be robust is much more difficult. When you find more time I'd appreciate some more background on this. Wanting to filter out HTML (nb. from AOL accounts) is the #1 gripe from my users. The Python library has an HTML parser that I've used before and it works pretty well. I used it to translate HTML to HTML, inserting data in various named fields. But removal of the HTML is the default action of the code. Of course you don't really want simply to remove it. E.g., you'd want to include HREF's somehow, substitute the description for images, etc. In thinking about this since my first post, it occurrs to me that one difficulty would be having two versions of one incoming post being parceled out to a single list. Now, I presume, you have a single file in the queue. I've been wrong before but this doesn't seem like brain surgery. > such extra information ought to be kept in an > external database like LDAP or some such. Then those databases ought > to be easily integrated into Mailman's rosters. That makes perfect sense. Thanks again for the other pointers. [Now back to the paying customers.... ;o| Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com

10 23

[BUG] Users are created as moderated in CVS mailman
by Ben Gertzfield 12 Mar '02

12 Mar '02

I'm not at all sure why this is, but on a completely fresh install of CVS mailman, even though DEFAULT_NEW_MEMBER_OPTIONS = 256, all my new list members are created with the 'moderated' flag on. The only custom options I have in Mailman/mm_cfg.py are: DEFAULT_SERVER_LANGUAGE = 'ja' DEFAULT_URL_PATTERN = 'http://%s/cgi-mailman/' [ben@nausicaa:/usr/local/mailman]% sudo python -i bin/withlist test-us-ascii Loading list test-us-ascii (unlocked) >>> m.members {'che(a)debian.org': 0, 'ben(a)gmo.jp': 0} >>> m.new_member_options 256 >>> m.user_options {'che(a)debian.org': 392, 'ben(a)gmo.jp': 392} # Bitfield for user options. See DEFAULT_LIST_OPTIONS above to set defaults # for all new lists. Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() DontReceiveOwnPosts = 2 # Non-digesters only AcknowledgePosts = 4 DisableMime = 8 # Digesters only ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 392 is 256 + 128 + 8. How is this getting set? Ben -- Brought to you by the letters P and A and the number 19. "A squib is a firecracker." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/

5 21

Re: [Mailman-Developers] Missing footers with latest CVS
by Dan Mick 12 Mar '02

12 Mar '02

> > Index: Decorate.py > > =================================================================== > > RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/Decorate.py,v > > retrieving revision 2.13 > > diff -u -r2.13 Decorate.py > > --- Decorate.py 12 Mar 2002 00:49:40 -0000 2.13 > > +++ Decorate.py 12 Mar 2002 20:29:12 -0000 > > @@ -72,6 +72,7 @@ > > # BAW: If the charsets don't match, should we add the header and footer by > > # MIME multipart chroming the message? > > if not msg.is_multipart() and msgtype == 'text/plain' and \ > > + not msg.get('content-transfer-encoding').lower() == 'base64' and \ > > (lcset == 'us-ascii' or mcset == lcset): > > payload = header + msg.get_payload() + footer > > msg.set_payload(payload) > > That (lcset == 'us-ascii') alternative assumes that the body > charset is always ASCII-friendly. Close, but not exactly true. The assertion was made that *all* charsets we support have us-ascii as a strict and complete subset. Are you claiming that's not true, or claiming that the assertion isn't sufficient to allow that alternative?

1 0

check_perms
by Ron Jarrell 12 Mar '02

12 Mar '02

Having just had the opportunity to run check_perms again (because one of my newly created lists failed to inhereit the right group. When the one before and after it did. I love computers sometimes), I noticed one picky little detail. If you run it without the -f, and it finds errors, it tells you to run it -f to fix them. That's fine. If you *do* run it -f, and it finds, and fixes, errors, it *still* tells you to rerun it -f to fix the errors... It probably shouldn't confuse people that way...

2 1

more snapshot woes...
by Ron Jarrell 12 Mar '02

12 Mar '02

I love playing catchup after a long hiatus :-)... Seems like somethings out of sync here... While doing the make install, update appears to blow chunks, because of PortableUnixMailbox.. Compiling /home/mailman/Mailman/aliases.py ... Compiling /home/mailman/Mailman/htmlformat.py ... Compiling /home/mailman/Mailman/i18n.py ... Listing /home/mailman/Mailman/pythonlib ... Compiling /home/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Archiver import Archiver File "/home/mailman/Mailman/Archiver/__init__.py", line 17, in ? from Archiver import * File "/home/mailman/Mailman/Archiver/Archiver.py", line 32, in ? from Mailman import Mailbox File "/home/mailman/Mailman/Mailbox.py", line 40, in ? class Mailbox(mailbox.PortableUnixMailbox): AttributeError: PortableUnixMailbox *** Error code 1 make: Fatal error: Command failed for target `update' 55.0u 111.0s 3:17 84% 0+0k 0+0io 0pf+0w

5 13

Released: New option for mailman-cvs: reply-to munging per user
by Marc MERLIN 12 Mar '02

12 Mar '02

On Mon, Mar 11, 2002 at 01:18:54AM -0800, Marc MERLIN wrote: > Per Barry's recommendation, I wrote this by adding a flag for each user and > duping each list message (munged and non munged version) and sending the > right version to each user. Just in case someone wonders why we went this way versus having a list of munged users like you have a list of digest users, is that it would require to change a lot more code to accomodate a third class of users. > Since this adds some processing, I added an optimization to bypass this code > if no one on the list requests munging. This was the missing piece in my patch yesterday, and implementing it right, and in an efficient way was tricky, but I'm pretty sure I nailed it now, and did it in a way that minimizes scans of the list membership. I think I've tested all the possible cases for this patch, and they worked correctly. I've also been encouraged by the positive feedback from the few people who responded on mailman-users on whether this patch would be useful to them too. If you get the chance, please install this on your mailman-cvs machine (my patch applies cleanly as of right now, can't make promises about tomorrow :D), and let me know if you find something I overlooked. Barry, if you have the time, let me know if you have questions about this or if you spot things that you'd have implemented differently. Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

1 1