Re: debian-ctte mailing list and spam
Wichert Akkerman writes ("Re: debian-ctte mailing list and spam"):
> It runs from procmail, so basically:
> * receive the post on stdin
> * return accept/bounce flag via returncode
Blars Blarson writes ("Re: debian-ctte mailing list and spam"):
> * the system being used is heavily overloaded, so few resources are
> available for doing the processing.
I was thinking of something like this:
Post arrives, and there are a number of reasons it might be
- Poster (`From:') on subscription list (per list)
- Message body is PGP signed; key is in one of several PGP
keyrings (same keyring for all lists)
- Poster's return-path + calling IP address 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
What do people think ?
 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.
 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
- 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.
 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.
 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:.
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.