Re: [debian-ctte-request@lists.debian.org: Re: debian-ctte mailing list and spam]

[Chris Cheney]

On Mon, Jun 21, 2004 at 11:43:34PM +0100, Stephen Stafford wrote:
> 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?

I have seen spam that looks like it is signed, but mutt doesn't show it
as such. I think perhaps they tried to sign it but failed to do so
properly. ;)

Chris


signature.asc
Description: Digital signature

[debian-ctte-request@lists.debian.org: Re: debian-ctte mailing list and spam]

[Stephen Stafford]

BAH!!!

- Forwarded message from [EMAIL PROTECTED] -

Envelope-to: [EMAIL PROTECTED]
Delivery-date: Mon, 21 Jun 2004 23:40:06 +0200
To: [EMAIL PROTECTED]
Subject: Re: debian-ctte mailing list and spam
From: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>:

> 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 .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.

Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64 port]

[Raul Miller]

On Mon, Jun 21, 2004 at 03:17:45PM -0500, Manoj Srivastava wrote:
> On Fri, 18 Jun 2004 01:07:54 +0100, Ian Jackson
> <[EMAIL PROTECTED]> said:  
> 
> >  * In our opinion the porting team are the right people to be
> >deciding on the architecture name, in general.
> 
> >  * In our opinion there is no significant technical reason to
> >interfere with the porting team's decision; on the contrary, we
> >largely agree with the porting team's choice of `amd64'.
> 
> >  * In our opinion architecture names with underscores in should not
> >be used because of the existing use of underscore as a separator
> >in package filenames, etc.; accordingly we advise that these
> >should be avoided.
> 
> >  * Since names with hyphens in are currently only used when
> >separating variant kernel-processor combinations, we advise that
> >this practice should be continued.
> 
> >  * Therefore, insofar as we are granted any authority by the
> >constitution, we uphold the porting team's choice of `amd64'.
> 
> >  * We request that dpkg should be changed to use `amd64'.  Should
> >the dpkg maintainers decline, we will seek clarification of the
> >Constitution and consider using our powers in 6.1(1), 6.1(2) or
> >6.1(4) to overrule the dpkg maintainers.
> 
>   I support this statement.

As do I.  [I had intended to say this earlier, but looking over the
archives, I don't see that I'e done so.]

Thanks,

-- 
Raul

Re: md5sum

[Scott James Remnant]

On Mon, 2004-06-21 at 14:26 -0500, Adam Heath wrote:

> Please don't do anything to resolve this bug, until I have had time to write a
> proper reply.
> 
What is the "proper reply" you are writing?

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part

Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64 port]

[Manoj Srivastava]

On Fri, 18 Jun 2004 01:07:54 +0100, Ian Jackson
<[EMAIL PROTECTED]> said:  

>  * In our opinion the porting team are the right people to be
>deciding on the architecture name, in general.

>  * In our opinion there is no significant technical reason to
>interfere with the porting team's decision; on the contrary, we
>largely agree with the porting team's choice of `amd64'.

>  * In our opinion architecture names with underscores in should not
>be used because of the existing use of underscore as a separator
>in package filenames, etc.; accordingly we advise that these
>should be avoided.

>  * Since names with hyphens in are currently only used when
>separating variant kernel-processor combinations, we advise that
>this practice should be continued.

>  * Therefore, insofar as we are granted any authority by the
>constitution, we uphold the porting team's choice of `amd64'.

>  * We request that dpkg should be changed to use `amd64'.  Should
>the dpkg maintainers decline, we will seek clarification of the
>Constitution and consider using our powers in 6.1(1), 6.1(2) or
>6.1(4) to overrule the dpkg maintainers.

I support this statement.

manoj
-- 
QOTD: "I'd never marry a woman who didn't like pizza... I might play
golf with her, but I wouldn't marry her!"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#254598: Name of the Debian x86-64/AMD64 port

[Manoj Srivastava]

On Thu, 17 Jun 2004 16:36:05 -0400, Raul Miller <[EMAIL PROTECTED]> said: 

> Does anyone have any reasonable objection to Stephen Frost's
> statement that the porting team should get to choose the name of the
> port?

Sounds fair to me.

manoj
-- 
I don't know if it's what you want, but it's what you get.  :-) Larry
Wall in <[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: debian-ctte mailing list and spam

[Wichert Akkerman]

Previously Ian Jackson wrote:
> 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)

That looks like a good list.

> 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.

Do you want to store the original message on the server? That might grow
to become a large database. It could be pruned daily of course.

> [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)

Perhaps we should support s/mime as well?

> [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)

Debian maintainer keyring is not a file but tries to grab keys from
LDAP.

> 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.

Compared to spamassassin it should be quite low-weight, and we can
always throw more hardware at the problem (Debian has plenty of offers).

Perhaps it can be done as a daemon to which you submit a message with a
little bit of context (name of the list should be enough). That way
you only need to work a little tool to submit the post which prevents
the startup costs.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.