[Mailman-Developers] bugtraq submission warning: email address harvesting exploit

[Richard Barrett]

On 29 Nov 2003, at 13:32, J C Lawrence wrote:

> On Sat, 29 Nov 2003 07:12:45 +0000
> Richard Barrett <r.barrett at openinfo.co.uk> wrote:
>> On 29 Nov 2003, at 00:48, J C Lawrence wrote:
>
>>>> [ 850805 ] Aggressive anti email address harvesting measure
>
>>> This patch appears to fail to distinguish between email addresses and
>>> Message IDs.
>>>
>
>> And ...
>
>> In the interest of simplicity it doesn't attempt to. But how important
>> a matter is that?
>
> For me, and (possibly) for Mailman v3, critical.  I use Message IDs as 
> a
> primary key for my list archives, indexing and several other bits.
> Changing them, at any point, breaks that.
>

I confess I was not gazing that far into the future and, not being a 
Mailman developer, have no influence or knowledge of the architecture 
of Mailman v3. However, offering an immediate fix for an arguably valid 
criticism of the current stable release that would not have a major 
destabilizing effect on that stable release seems worthwhile to me.

One of the reasons why the offered patch is so limited in its impact on 
the Mailman source is that it does the job at a single choke point (in 
private.py), is entirely quiescent if you do not turn it on in 
mm_cfg.py, returns to do nothing if you turn it back off again and 
leaves no trace in the data on the server whether it was ever turned on 
or not or how many times. This means that an alternative solution in a 
later Mailman release can happily omit this solution and still finds 
itself updating standard Mailman archives as if the brief period of 
currency for the solution had never been.

It seems from what you say that your archiving and indexing solution is 
not standard Mailman internal pipermail archiving so the poor fit of 
the solution offered with your system is unsurprising.

>> This is a rendering filter which leaves the underlying archived
>> material intact in the archive and handles both the archive's html
>> pages and the downloadable text version of the period archives. It has
>> no impact on any processing undertaken at the server end on the
>> archive material, which might depend on the Message IDs, thread
>> identification by the archiver for instance.
>
> For me Message IDs are both a systems-level and user-level concern.  
> Raw
> Message IDs as well as URLs containing message IDs are quoted by users
> as ways to reference specific messages in the archives, additionally
> Message IDs are also quoted in URLs which appear in every message, 
> which
> point to that message in the archives, etc.
>
>> My mail reader will still identify threads in filtered, downloaded
>> text archives when treated as an .mbox, although I grant that the
>> chances of Message ID collisions must be increased by the filtering.
>
> I and several others use an NNTP-based backing store (which of course
> uses Message ID as a primary key as per NNTP specs) for my archives and
> then render directly out of that (see prior traffic on this list wrt
> MeoWWW etc).  The access key for retrieving a message is its Message 
> ID.
> Touch the Message ID and the whole system breaks.
>

Bear in mind that the patch only affects the data delivered in response 
to HTTP requests. The actual archive data on the server remains 
unchanged and the patch has no effect on data moving in either 
direction through a regular NNTP-Mailman gateways. If you have your own 
adaptations to Mailman, of which I know nothing, it is no surprise if 
the proffered solution is not suitable.

As the patch is only intended as a simple, fast solution for standard 
pipermail archives (or my integration of the MHonArc archiver with 
pipermail) which deliver material from the archives via Mailman's 
private.py script, I guess the solution is not for you.

Your input was informative and useful and I'll ponder on it.

In the meantime, the best of luck in finding an alternative solution 
that fits your needs.

> -- 
> J C Lawrence
> ---------(*)                Satan, oscillate my metallic sonatas.
> claw at kanga.nu               He lived as a devil, eh?
> http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
>