gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Describing archives (new feature at the mirror)


From: Julian T J Midgley
Subject: Re: [Gnu-arch-users] Re: Describing archives (new feature at the mirror)
Date: Sat, 3 Apr 2004 13:05:37 +0100 (BST)

On Sat, 3 Apr 2004, Andrew Suffield wrote:
>
> You are assuming that the transformation an MLM performs on the mail
> is completely without value, and you would never care which version
> you receive. The problem with that idea should be obvious.

I appreciate your desire for perfection in your solutions.  Experience
suggests, however, that in the face of an absence of standards, a little
pragmatism goes a long way.

If one is interested in the additional data added to a message by the MLM,
then one can retrieve it from any other mail sent to the mailing list (or
from the duplicate itself, which is typically stored for a period).  In
practice, this information is useful only rarely.

If it were the habit of MLMs to send, piece by piece in the headers,
recipes for the finest miso soups, the solutions to entertaining
mathematical problems, or hot stock tips, then I might be more concerned
that I received their transformed copy.  In practice, however, they do
not, restricting their activities instead to regurgitating URLS and
instructions for unsubscription, locating archives and suchlike, together
with some gratuitous signature bloat, and so I genuinely care not whether
I see the MLM version or that of the author.

> > So keep a cache of message-ids you've already seen, and throw
> > any duplicates (arranging for your filters to drop the first copy of each
> > mail into your inbox or mailing list boxes as you prefer).
>
> And now anybody who can predict msgids, which frankly is not all that
> hard (they are not designed to be secure) can selectively filter your
> mail by forwarding you spam with suitable forged msgids.

Again, whilst this is in theory true, any such attack is trivially
detectable (without loss of data, since duplicates are not immediately
discarded), and much harder to pull off in practice than you suggest.
So, encore une fois, the solution (of filtering duplicates) turns out,
although not to be perfect, to be considerably more practical than the
alternatives, and certainly sufficiently effective to deny your original
assertion that "the only sane place that it can be fixed is at the sender
end".

All the best,

Julian


-- 
Julian T. J. Midgley                       http://www.xenoclast.org/
Cambridge, England.
PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1  A7D5 3027 2F2E BCC7 863F







reply via email to

[Prev in Thread] Current Thread [Next in Thread]