At 2:33 PM -0400 2005-04-30, Tobias Eigen wrote:
The described patch to Mailman is very interesting, though, and I'm glad it's been done. I haven't tried the patch, but from what I'm hearing the issue of it appearing to endorse one or other archives can be dealt with by making the feature customizable - i.e. have a control line where mailman admins can configure whatever external archiver they want, with completely configurable fields: the name/description of the archiver and the email address to automatically add. The mail-archive and gmane options would be included as examples but commented out.
This assumes that the patch could be modified so as to be generally applicable across all external archiving systems, and the comments from Lars at Gmane have already indicated that's not possible.
This is a nice idea, but I don't think it's going to be that easy. Sure, you might be able to generalize the patch to a certain degree, but there would be many hurdles. Recall the post from Jeff Marshall at 30 Apr 2005 10:37:15 -0700 where he mentioned that RFC 2369 only allows for one List-Archive: URL.
Without opening a can of worms, hopefully, let me close with one last thought. I realize this has probably been discussed ad nauseum in other places, but there's a bit of a flaw in all this. Email addresses can be faked, and so an archiver based on email is going to be fraught with problems - or at least a whole lot of spam on the archives once the spammers figure out how it works.
Anything based on e-mail is going to be vulnerable. Whether this is a mailing list, a mailing list archiving system, or anything else.
On our own system, we use Mailman's own archiver subsystem for gatewaying messages to our Fud Forum (http://www.fudforum.org). Another way I've tried successfully is through the use of an email address made up of random characters that gets delivered to Fud. That works fine, and since the list is on Kabissa (managed by me) and the Fud is on Kabissa, the likelihood of spammers getting in by spoofing addresses is pretty low.
External mailing list archiving systems would be likely to be reasonably secure. No one else would have any reason to know what address of theirs was subscribed to the mailing list, and it would be difficult to brute-force that. Moreover, it would be easy for them to implement a greylist-style mechanism where incoming posts from the mailing list are required to be sent by one or more given IP addresses, thus securing them from most sorts of inbound spoofs to the archive, even if the subscribed address could be discovered.
If you're concerned about addresses being lifted from the archive, that's also reasonably easy to secure -- mail-archive.com has one example, but there are plenty of others.
Of course, spammers could always subscribe to the list and then post their spam, and viruses would be able to look in the outbox of a user's MUA and then send new messages with virus content attached to those same recipients, and either of these types of posts would be likely to get through to the recipients of the list.
One way to mitigate this problem is to require approval before a subscriber is allowed to finish the process to subscribe. Another is to make users moderated by default, so that their postings require approval before they get through to the list.
Of course, there are always the mechanisms that Mailman provides for doing content stripping of MIME bodypart types, and I believe that these sorts of things should be done by default.
I think we've already got some pretty good tools in this area.
If you wanted to go further, you could require that all subscribers post via cryptographically signed messages, but then that would be vulnerable to the virus problem where the malware takes over the user's MUA and sends out messages in their name.
I guess you could always run a completely closed system, whereby people could access a webmail-type system on your servers, or use a forum-based solution on the same machines, but I think that defeats much of the purpose of a mailing list management system, which is to take content as it comes in and to distribute that out to the various recipients so that they can read that at their leisure on their own systems.
There might be other anti-spam security mechanisms which you could employ, and I'd welcome hearing about them.
Then there are all the system-level anti-spam mechanisms, such as greylisting, rules-based message scoring systems like SpamAssassin, fingerprint-based content reporting/detection systems such as DCC/Razor/Pyzor, and others. Of course, all of these sorts of things would be outside of the mailing list management system, and not a part of Mailman.
-- Brad Knowles, <[EMAIL PROTECTED]>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See <http://www.sage.org/> for more info. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
