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

Re: debian-ctte mailing list and spam



Stephen Stafford writes ("Re: debian-ctte mailing list and spam"):
> This looks like a fairly good plan, however it will mean that
> virtually all the spam (which the point is to try to minimise) gets
> bounced back to the (probably) forged return-path, thereby sending
> spam to some poor unfortunate.  A fair proportion of the stuff my
> filters removes is of this type.

Indeed.  (There are people working in the IETF on cryptographically
authenticated return paths which if they can get a good spec can solve
this problem.)

> I don't know how technically viable it is, but I'd far prefer to see
> this system reject the mail at the SMTP level at which point these
> bounces aren't generated.

I think that that's technically quite difficult.  It would mean close
wiring the spamchecker into the existing SMTP setup.  People are
working on schemes like that, and I should be careful not to rule out
such a structure in the future, but I don't think it's practical at
the moment.

> If that *isn't* possible (as I suspect it might not be) then would you please
> consider adding some header (X-Debian-Bounce) or something that can easily be
> filtered for?

Good point.

> Is there any reason not to just accept *any* gpg/pgp signed mail?
> At the moment I've never seen a spammer signing mail, so *any* mail
> received that is signed is likely to be ham.  If it turned out they
> were going to start doing so, then fine, add the functionality (and
> leave room for it in the design now), but I see no reason to incur
> the overhead of checking signatures against a keyring if it buys us
> nothing immediately.

Spammers have been known to add things that look like PGP signatures
but aren't, so you have to actually verify the signature.  To verify
the signature you need the public key.  You don't want to look to the
public key up on a possibly-fallible general-purpose keyserver.  So,
you have to keep your own keyring anyway.

> Perhaps implement the checking feature, but turn it off for now?
>  
> > [4] The calling IP address would computed [...]
> 
> How will that deal with people (I believe there are some) who use debian
> machines to read/send project related email?

The algorithm I described has a special case, where all the Received
headers say `from *.debian.org'.  We could either always accept those
mails or simply treat that case as distinct a `null' calling IP
address value.

Ian.



Reply to: