[debian-ctte-request@lists.debian.org: Re: debian-ctte mailing list and spam]
BAH!!!
----- Forwarded message from debian-ctte-request@lists.debian.org -----
Envelope-to: ssta@clothcat.org
Delivery-date: Mon, 21 Jun 2004 23:40:06 +0200
To: ssta@clothcat.org
Subject: Re: debian-ctte mailing list and spam
From: debian-ctte-request@lists.debian.org
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at linuxops.net
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on shanta.linuxops.net
X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME
autolearn=no version=2.63
X-Spam-Level:
You are not subscribed to this list, so your submission was rejected.
Please subscribe to the list first and then repost your message.
A copy of your submission is included below.
---------------------------------------------------------------------------
[I can't see an Mail-Followup-To or Reply-To in the headers, so preserving the
full CC list. Apologies if some people get this twice]
Quoting Ian Jackson <ian@davenant.greenend.org.uk>:
> I was thinking of something like this:
>
> Post arrives, and there are a number of reasons it might be
> accepted:
> - Poster (`From:') on subscription list (per list[1])
> - Message body is PGP signed[2]; key is in one of several PGP
> keyrings[3] (same keyring for all lists)
> - Poster's return-path + calling IP address[4] is in whitelist
> (same whitelist for all lists)
>
> If none of these apply, the post is bounced to the return-path with an
> explanation in the bounce text. The bounce contains a challenge, a
> response to which (by email, I suppose) adds return-path + calling IP
> address to the whitelist and causes the message to be delivered to the
> list.
>
> What do people think ?
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.
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.
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?
>
> [1] Although for now this is just for debian-ctte, if it works well
> then other lists might want to use it too. So we have to think now
> about which properties are per-list and which ones global.
>
> [2] A PGP signed message is one which consists _entirely_ of:
> - An old-style PGP clearsig message optionally followed by a
> `-- ' delimited signature (of specified maximum length and
> width).
> - A new-style PGP-mime message (Content-Type multipart/signed)
> The signature has to be reasonably recent, not too far in the future,
> and of course has to be from a key in the keyring.
>
> [3] Several keyrings:
> - Standard Debian maintainer keyring
> - Auxiliary keyring, updates auth'd by maintainer keyring
> - Manual override file (we don't expect to use this)
> When I say `keyring A updates auth'd by B' I mean that you send a
> message signed by a key in B with instructions to add or remove
> certain keys from A. The scheme I describe above would allow Debian
> maintainers to add separate lower-security email-signing keys
> belonging to them or to any interested party. Note that those
> lower-security keys don't get to add further keys.
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.
Perhaps implement the checking feature, but turn it off for now?
> [4] The calling IP address would computed as follows: scan the
> Received lines starting at the top of the message. Find the first one
> which _doesn't_ say `Received: from <something>.debian.org ...'. The
> IP address in that Received line is the one in question.
>
> This check is necessary because we expect the whitelist to quickly
> contain many Debian developers, and of course spammers will forge mail
> with those addresses in the From:.
How will that deal with people (I believe there are some) who use debian
machines to read/send project related email?
> Regarding performance: am I to take it that running a Perl script on
> each message is too slow ? That would be a convenient way to
> implement it, but Perl's startup costs are substantial, particularly
> when lots of modules are being used.
>
I don't know what the performance requirements are exactly, but I suspect that
a
client/server mechanism (a la spamc/spamd) would offer better performance than
a
perl script starting for each mail.
Cheers,
--
Stephen Stafford | Development and support consultant
<stephen@clothcat.demon.co.uk> | http://www.clothcat.org
<ssta@clothcat.org> | Never put off until tomorrow what you can
<bagpuss@debian.org> | con someone into doing for you today
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
----- End forwarded message -----
Reply to: