In principle, I agree with Patrick. Mailman is not the right place for DNSBL support or Spamassassin support. This is not just because it's already done in the MTA and/or HTTPd, but also because the MTA and HTTPd are better places in any case because they can reject without receiving the whole content (which can be very large, especially in case of a DoS attack).

Nevertheless, this is a frequently requested feature because many Mailman list owners and even site admins lack shell access and access to MTA and HTTPd configurations. I don't much like it (I'd rather tell the list admins to get a better host), but OTOH many can't or won't, so we may as well give them what they ask for.

There's another problem with these two projects as GSoC projects, though, and that's that they're too "small". As the OP noted, SpamAssassin has already been done for Mailman, and there are packages on PyPI for DNSBL support. Integrating into Mailman is only gong to be a few lines for each, and even if you propose several, the code quite repetitive (mostly marshalling for the Handler API, and the code to allow the list owner to enable/disable through the admin site). GSoC envisions a more extended project that involves some design and several different skills.

The confirmation for phone numbers is more interesting, and could be extended to various kinds of confidential information, as well as detection of confidential posts from footer legalese (which was recently discussed on the -users list).

Regards, Steve

Patrick Ben Koetter writes:

Hi Aanand,

• Aanand Shekhar Roy 2013001@iiitdmj.ac.in:)

...

Hi all, I am currently finding good plugin ideas that might make there way into mailman 3 system.I had discussed the same with @terri on irc.Some ideas i have already found good are:

1. DNS BlockList

where would you put DNSBL support?

On SMTP level? I'd let the MTA take care of it. On HTTP level? I'd let the HTTP take care of it.

Sorry, if I sound harsh. I don't mean it. I just can't imagine where DNSBL would make sense without reinventing something that has been done yet.

...

2. Confirmation from user before posting phone nos in emails
3. SpamAsassin as it is

I'd leave that to an MTA too, unless there's a non-SMTP way how mail enters mailman.

p@rick

-- [*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

---

Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/stephen%40xemacs....

Security Policy: http://wiki.list.org/x/QIA9

Ian Eiloart writes:

I don’t think Exim can. Once it has the sender and recipient addresses, it can either reject the email or ask to receive the whole of the message: headers and body.

Indeed. I didn't mean that you can always reject/discard without receiving the message, but sometimes you can. Furthermore, in the case of normal deliveries, the MTA is almost always much quicker about clearing its queue than Mailman can be.

It’s nice to be able to push spam checking further down the line, because it’s possible that different lists might want different configurations. For example, a health professionals’ list might want to be more liberal about references to body parts, and a finance professionals’ list might want to be more liberal about references to unexpected inheritance!

SpamAssassin can handle that fine -- all needed information will be available. Note that if you handle such an exception at the MTA, you have *one* exception to add, whereas if you handle it at the mailing list, you have to add the rule to all mailing lists except the unexceptional one.

Aanand Shekhar Roy writes:

outdated so I had to ask you all whether the following ideas have been implemented yet or not?

Neither has been implemented in Mailman, but you might want to do a web search for them, especially the downloadable archives -- HyperKitty may have already done it.

1.Provide downloadable tar.gz's of the html archives.

There's no such thing as "the" archives in Mailman. The site admin may not even have direct access to them (if they use mail-archive.com or Gmane), and even if the archive is local, there are various archivers (the old Pipermail in Mailman 2 -- which hasn't yet been ported to Mailman 3, MHonArc, and now HyperKitty).

I'm not sure how much value this has, however, both because we already provide downloadable mbox archives, and on the other hand connectivity is rapidly improving everywhere -- the HTML version is easily and quickly available over the web.

2.Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.

This is a good idea, and straightforward to implement, I think.