Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit
![](https://secure.gravatar.com/avatar/db32238d5eebf878622c8bd2770a7d0e.jpg?s=120&d=mm&r=g)
On Sat, 29 Nov 2003 07:12:45 +0000 Richard Barrett <r.barrett@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.
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.
-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
![](https://secure.gravatar.com/avatar/632bc87a86b0db6153c56defac0ba682.jpg?s=120&d=mm&r=g)
On 29 Nov 2003, at 13:32, J C Lawrence wrote:
On Sat, 29 Nov 2003 07:12:45 +0000 Richard Barrett <r.barrett@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@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
participants (2)
-
J C Lawrence
-
Richard Barrett