Mailman 3 January 2002 - Mailman-Developers

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 09 Jan '02

09 Jan '02

> DM> No, I'm not trying any marriage, nor any realtime lookups, > DM> just using its prewired heuristics (from a .forward file, as I > DM> don't own my mailserver). It's a "look at the message and try > DM> to intuit if it's spam" solution, so it doesn't use any > DM> whitelisting really (well, there's dynamic whitelisting, in > DM> that some of its heuristics are "have I ever noted non-spam > DM> from this address before?") > > DM> I love it so far; it's instantly cut my spam to almost nil > DM> (from ~30-40 a day) with very few errors. > > I lost track, SpamAssassin or TDMA? SA > I read about SA briefly and it > looks like you could run it in a client/server arrangement. Yeah; it runs as a relatively-big Perl wad normally, but for efficiency you can start it as a daemon and then run a small C client that behaves the same way, so that the startup costs are one-time instead of per-mail. > If the > on-the-wire protocol were simple enough, you could probably write a > pure-Python client and then integrate that into Mailman's handler > pipeline. If it's too complex, you might be able to wrap SA's C API > in a Python extension module. Yeah, either should be simple enough to code in Python (it's an HTML-like protocol). I actually hadn't thought about trying to provide spam filtering for lists; I'm just thrilled with what it's doing for my personal email.

2 1

Re: [Mailman-Developers] documentation for config.pck elements?
by Dan Mick 09 Jan '02

09 Jan '02

> DM> It might be that inverting the problem might be the right > DM> answer: Mailman 2.1 goes through an API for all "member"-type > DM> queries, and so perhaps storing the member info external to > DM> config.db via a new "member-adaptor" interface, so that TMDA > DM> could also access it through a stable interface, would be the > DM> right Mailman/TMDA integration answer? See MemberAdaptor.py > DM> and OldStyleMemberships.py. > > That's definitely on the plate for post-MM2.1. Separating out the > storage and representation issues and providing an abstract interface > to the data model affords all kinds of benefits. Actually, I was semi-proposing that MemberAdaptor was mature enough to be drop-in-replaced by something that TMDA supplies, but I can't quite tell if you're disagreeing or not. > DM> Interesting, though; just trying out SpamAssassin > > Neat! Are you integrating it with Mailman? I'd love to hear about > your results (you may have already posted about it, I'm trying to > catch up on the list). It looks like a neat thing to try to marry to > Mailman. So is TDMA. Thanks for posting that link Jason. No, I'm not trying any marriage, nor any realtime lookups, just using its prewired heuristics (from a .forward file, as I don't own my mailserver). It's a "look at the message and try to intuit if it's spam" solution, so it doesn't use any whitelisting really (well, there's dynamic whitelisting, in that some of its heuristics are "have I ever noted non-spam from this address before?") I love it so far; it's instantly cut my spam to almost nil (from ~30-40 a day) with very few errors.

2 1

bad!
by Fil 09 Jan '02

09 Jan '02

Here's what one of our lists' moderators receive, once in a while, since we updated Mailman to the current CVS. So there's "bad marshal data", but in which file? What to do? (I guess it's people trying to unsubscribe.) > MailCommandHandler.ParseMailCommand() > > Traceback (most recent call last): > File "/home/mailman/Mailman/MailCommandHandler.py", line 261, in ParseMailC > self.__dispatch[cmd](args, line, msg) > File "/home/mailman/Mailman/MailCommandHandler.py", line 601, in ProcessUns > self.ConfirmUnsubscription(cpaddr) > File "/home/mailman/Mailman/MailList.py", line 1011, in ConfirmUnsubscripti > cookie = Pending.new(Pending.UNSUBSCRIPTION, addr) > File "/home/mailman/Mailman/Pending.py", line 62, in new > db = _load() > File "/home/mailman/Mailman/Pending.py", line 115, in _load > return marshal.load(fp) > ValueError: bad marshal data -- Fil

2 2

documentation for config.pck elements?
by Jason R. Mastaler 09 Jan '02

09 Jan '02

Are the contents of a Mailman configuration "database" (config.db/config.pck) documented anywhere? In particular, the various keys. Keys such as "members", "digest_members", and "owner" are obvious, but others aren't so. I can probably figure them out with some digging, but I'd like to have some sort of reference to point TMDA users to. TMDA has recently been trained to grok MM config databases (see http://mla.libertine.org/tmda-workers/200201/msg00050.html). Thanks. -- (TMDA (http://tmda.sourceforge.net/)) (user-level UCE intrusion prevention)

1 0

RELEASE Mailman 2.1 alpha 4
by barry＠zope.com 08 Jan '02

08 Jan '02

Hi all, Just wanted to let you know that I've released Mailman 2.1 alpha 4. Below is the big list of changes with this release. This will be the last alpha release for 2.1, but this still leaves open the possibility of a few new features in MM2.1. I've got everything in that I intend to get in. If you've got a pet new feature -- and have code that implements it -- please do remind me about it now and I'll work on getting in what I can for the first beta. Apologies for falling so far behind in the mailing list traffic. This is admittedly a bit of a rushed release. I really wanted to get this out before the end of the year (in my timezone at least ;). Depending on my other real-job commitments, I'll be spending all my spare time getting bugs fixed and moving toward the 2.1 final release. I'm shooting for release by the Python conference in February, but I don't know if I'll make it. Cheers, and happy new year to you all. I-swear-the-X-Oblique-Strategy-was-chosen-random-ly y'rs, -Barry -------------------- snip snip -------------------- 2.1 alpha 4 (31-Dec-2001) - The administrative requests database page (admindb) has been redesigned for better usability when there are lots of held postings. Changes include: o A summary page which groups held messages by sender email address. On this page you can dispose of all the sender's messages in one action. You can also view the details of all the sender's messages, or the details of a single message. You can also add the sender to one of the list's sender filters. o A details page where you can view all messages, just those for a particular sender, or just a single held message. This details page is laid out the same as the old admindb page. o The instructions have been shorted on the summary and details page, with links to more detailed explanations. - Bounce processing o Mailman now keeps track of the reason a member's delivery has been disabled: explicitly by the administrator, explicitly by the user, by the system due to excessive bounces, or for (legacy) unknown reasons. o A new bounce processing algorithm has been implemented (we might actually understand this one ;). When an address starts bouncing, the member gets a "bounce score". Hard (fatal) bounces score 1.0, while soft (transient) bounces score 0.5. List administrators can specify a bounce threshold above which a member gets disabled. They can also specify a time interval after which, if no bounces are received from the member, the member's bounce score is considered stale and is thrown away. o A new cron script, cron/disabled, periodically sends notifications to members who are bounce disabled. After a certain number of warnings the member is deleted from the list. List administrators can control both the number of notifications and the amount of time between notifications. Notifications include a confirmation cookie that the member can use to re-enable their subscription, via email or web. o New configuration variables to support the bounce processing are DEFAULT_BOUNCE_SCORE_THRESHOLD, DEFAULT_BOUNCE_INFO_STALE_AFTER, DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS, DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS_INTERVAL. - Privacy and security o Sender filters can now be regular expressions. If a line starts with ^ it is taken as a (raw string) regular expression, otherwise it is a literal email address. o Fixes in 2.0.8 ported forward: prevent cross-site scripting exploits. - Mail delivery o Aliases have all been changed so that there's more consistency between the alias a message gets delivered to, and the script & queue runner that handles the message. I've also renamed the mail wrapper script to `mailman' from `wrapper' to avoid collisions with other MLM's. You /will/ need to regenerate your alias files with bin/genaliases, and you may need to update your smrsh (Sendmail) configs.a Bounces always go to listname-bounces now, since administration has been separated from bounce processing. listname-admin is obsolete. o VERP support! This greatly improves the accuracy of bounce detection. Configuration variables which control this feature include VERP_DELIVERY_INTERVAL, VERP_PERSONALIZED_DELIVERIES, VERP_PASSWORD_REMINDERS, VERP_REGEXP, and VERP_FORMAT. The latter two must be tuned to your MTA. o A new alias mailman-loop(a)dom.ain is added which directs all output to the file $prefix/data/owner-bounces.mbox. This is used when sending messages to the site list owners, as the final fallback for bouncing messages. o New configuration variable POSTFIX_STYLE_VIRTUAL_DOMAINS which should be set if you are using the Postfix MTA and want Mailman to play nice with Postfix-style virtual domains. - Miscellaneous o Better interoperability with Python 2.2. o MailList objects now record the date (in seconds since epoch) that they were created. This is in a hidden attribute `created_at'. o bin/qrunner grows a -s/--subproc switch which is usually used only when it's started from mailmanctl. o bin/newlist grows a -l/--language option so that the list's preferred language can be set from the command line. o cron changes: admin reminders go out at 8am local time instead of 10pm local time. - Pipermail archiver o MIME attachments are scrubbed out into separate files which can be viewed by following a link in the original article. Article contains an indication of the size of the attachment, its type, and other useful information. o New script bin/cleanarch which can be used to `clean' an .mbox archive file by fixing unescaped embedded Unix From_ lines. o New configuration variable ARCHIVE_SCRUBBER in Defaults.py.in which names the module that Pipermail should use to scrub articles of MIME attachments. o New configuration variable ARCHIVE_HTML_SANITIZER which describes how the scrubber should handle text/html attachments. o PUBLIC_ARCHIVE_URL has change its semantics. It is now an absolute url, with the hostname and listname parts interpolated into it on a per-list basis. o Pipermail should now provide the proper character set in the Content-Type: header for archived articles. - Internationalization o Czech translations by Dan Ohnesorg. o The Hungarian charset has be fixed to be iso-8859-2. o The member options login page now has a language selection widget. - Building, configuration o email-0.96 package is required (see the misc directory). o New recipes for integrating Mailman and Sendmail, contributed by David Champion.

5 6

Changing Digest numbers
by Bob Puff/NLE 08 Jan '02

08 Jan '02

Hey gang, In 2.0.x, how do you bump the volume number, and reset the digest number back to 1? Bob

4 4

Re: [Mailman-Developers] Changing Digest numbers
by Dan Mick 08 Jan '02

08 Jan '02

> >>>>> "BP" == Bob Puff <bob(a)nleaudio.com> writes: > > BP> In 2.0.x, how do you bump the volume number, and reset the > BP> digest number back to 1? > > cron/bumpdigests Aha, a non-.py file! Looking at the source proved harder than I thought...

2 1

Re: [Mailman-Developers] Changing Digest numbers
by Dan Mick 08 Jan '02

08 Jan '02

> > There's an admin page entry for it; you need to even crack the > > source. Bottom of admin/<listname>/digest, if it's the same place > > as in 2.1 (and it looks like it is; I'm just not running 2.0.x so > > I can't verify easily). > > Not in 2.0.x there's not. At least that I can see. That's a 2.1.x thing. You're right; I was looking at the 2.1 sources (didn't think I had them on this machine). Looks to me then like there's no way other than bin/withlist. Variables are 'volume' and 'next_digest_number'. I base the "there's no way" on the fact that I can't find an assignment to 'volume' anywhere (besides its original init to 1).

1 0

Re: [Mailman-Developers] Changing Digest numbers
by Dan Mick 08 Jan '02

08 Jan '02

There's an admin page entry for it; you need to even crack the source. Bottom of admin/<listname>/digest, if it's the same place as in 2.1 (and it looks like it is; I'm just not running 2.0.x so I can't verify easily). > Did I miss a support contract that I was supposed to sign > before joining this list? I don't know. > Did you look at the source? > > > DId I miss a message, or was there no reply? How do you change the digest > numbers? > > > > Bob > > > > > > Bob Puff/NLE wrote: > > > > > > Hey gang, > > > > > > In 2.0.x, how do you bump the volume number, and reset the digest number > back to 1?

2 1

Re: [Mailman-Developers] Changing Digest numbers
by Dan Mick 08 Jan '02

08 Jan '02

> There's an admin page entry for it; you need to even crack the ^ didn't > source. Bottom of admin/<listname>/digest, if it's the same place

1 0