Re: forgeries increasing

[Bob Proulx]

Jim Meyering wrote:
> In case this ever becomes a big enough problem:

Stay tuned.  I think spammers are ramping up their attacks.  We could
easily find things under heavy assault very quickly.  I think so far
it has only been the spam machinery developers who have been poking at
the system to develop their code.  Once developed they will then sell
these to other spammers as a new avenue so far unexploited.  At that
time is when I think the spam will start in earnest.

>     maintain a profile for each subscriber, and when s/he posts
>     with a significantly different header "signature" (i.e., derived
>     from some amalgam of fields like Message-Id, Received: etc.), then
>     require a delay or manual approval.

Yes.  Instead of whitelisting the address use the combination of
address plus the IP list that it took to enter the mailing list
together as a whitelist.  Adding the mail relay IP address would be
much harder to forge.  Adding more information such as mail user agent
and other opportunistically available information from the header
would increase the accuracy.

> Obviously, there's the small matter of coding, not to mention
> coming up with a good heuristic for determining what "significantly
> different" should mean.

Most significantly is that we would need two major changes to the
existing system.

1. *ALL* mail would need to be moderated.  Currently subscriber email
   is passed through.  In order to control the forgery problem even
   subscriber email would need to be moderated.

2. Mail would need to be approved automatically through Mailman
   _somehow_.  Currently listhelper only discards spam.  Currently
   listhelper does not approve messages.  This would need to be
   improved.

I have had very bad experiences using Mailman's email interface to
approve messages.  Previously when testing this functionality I
discovered that Mailman would often discard a message that was
intended to be approved.  It appeared that the algorithm was that if
the password verified then it approved it but if the included password
failed to verify then it discarded the message!  Ouch.

In any case, these two problems will need to be solved before
something like this can be turned-on.

> And of course, you can skip the check if a message is signed,
> or if headers themselves can be authenticated.

It would make sense to have types of authentication.  One type should
be signed messages.  If the message is signed and the signature
verifies then send the message through regardless of how it was
originated.  Would need to remove parts of the message outside of the
signed part to avoid parasite content being added around a signed
message.

Bob