Bug#500965: lists.debian.org: Should remove DKIM and DomainKey headers

2008-10-03 Thread Thomas Viehmann
severity important
thanks

Hi Russel,

thanks for alerting us of this problem.

Russell Coker wrote:
[ signatures in DKIM-Signature and DomainKey-Signature broken by
  appending a footer]

For lists where the footer only contains unsubscription information, an
alternative to removing the headers could be appending the footer only
on non-signed mail.
Of course, even more preferable would be if people designing standards
would not expect users to change the ways they sign messages (l=) based
on whether it's going to be sent to a list or not as the only way to
accommodate common existing practices.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#500965: lists.debian.org: Should remove DKIM and DomainKey headers

2008-10-03 Thread Russell Coker
On Friday 03 October 2008 19:02, Thomas Viehmann [EMAIL PROTECTED] wrote:
 Of course, even more preferable would be if people designing standards
 would not expect users to change the ways they sign messages (l=) based
 on whether it's going to be sent to a list or not as the only way to
 accommodate common existing practices.

I challenge you to design a way of signing messages that doesn't have this 
issue.

I can't think of a better way of doing this, and I am really interested to 
hear any proposals of better ways of doing it.  Last time I checked DKIM 
wasn't finalised so you can suggest changes to it...



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#500965: lists.debian.org: Should remove DKIM and DomainKey headers

2008-10-03 Thread Thomas Viehmann
Hi Russell,

Russell Coker wrote:
 On Friday 03 October 2008 19:02, Thomas Viehmann [EMAIL PROTECTED] wrote:
 Of course, even more preferable would be if people designing standards
 would not expect users to change the ways they sign messages (l=) based
 on whether it's going to be sent to a list or not as the only way to
 accommodate common existing practices.
 
 I challenge you to design a way of signing messages that doesn't have this 
 issue.

 I can't think of a better way of doing this, and I am really interested to 
 hear any proposals of better ways of doing it.  Last time I checked DKIM 
 wasn't finalised so you can suggest changes to it...
I thought it was an RFC by now. The obvious way would be signing the
footer part that we added (by, say, having a start and lenght field and
allowing multiple signatures), having well-signed mean signature
headers covering everything.
People wishing to implement some policy could impose restrictions of
content covered by auxiliary signatures. Naturally, another sane
policy would be requiring timely delivery of messages relative to the
oldest signature.

But this is offtopic here, maybe it'd be worth wile to take it up to the
dkim-people, but until they decidedly need input and are prepared to fix
this, I'm not too sure it's good use of my time nor whether my ideas on
the subject have significant drawbacks.[1]

Yes, it's not ideal that we're appending stuff, but we still get mail
from people not being able to figure out how to unsubscribe at a rate of
about 1/per day.

Kind regards

T.

1. I once had a conversation with an IMAP expert participating in the
   standards process and was surprised how they did not have globally
   unique identifiers. There are some things to be considered, but the
   security concerns he cited seemed to be easy enough to eliminate.
-- 
Thomas Viehmann, http://thomas.viehmann.net/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#500965: lists.debian.org: Should remove DKIM and DomainKey headers

2008-10-03 Thread Stephen Gran
This one time, at band camp, Russell Coker said:
 On Friday 03 October 2008 19:02, Thomas Viehmann [EMAIL PROTECTED] wrote:
  Of course, even more preferable would be if people designing standards
  would not expect users to change the ways they sign messages (l=) based
  on whether it's going to be sent to a list or not as the only way to
  accommodate common existing practices.
 
 I challenge you to design a way of signing messages that doesn't have this 
 issue.

PGP and GPG seem to do it right.  Given that they've existed for ages,
do it correctly, and actually have some measure of believability, I'm
not sure why another standard was needed for signing things, much less
why we should all change all our existing practices to accomodate a
poorly thought scheme.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Bug#500965: lists.debian.org: Should remove DKIM and DomainKey headers

2008-10-02 Thread Russell Coker
Package: lists.debian.org
Severity: normal

Gmail sends out all mail signed with DKIM and DomainKeys, the DKIM
signatures do not include a length field so any change to the message
length (such as appending a list footer) will break the signature.

To deal with this problem the default configuration of the Mailman
package in Lenny will strip all DKIM and DomainKeys headers
(DKIM-Signature and DomainKey-Signature are the names of the headers in
question).

I think that the ideal functionality of a list server in this regard
would be to leave DKIM headers with a length field IFF the list in
question is not configured to prepend the list name to the subject line.
If the DKIM header has no length field or the subject line is to be
modified then it needs to be stripped.  But the functionality of Mailman
in Lenny is adequate.

The current situation is that anyone who configures their mail server to
reject messages that fail the DKIM checks will reject every message sent
to a Debian mailing list from Gmail (which is a moderate amount of
mail).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]