From: Jim P. <ji...@ya...> - 2006-05-06 06:45:47
|
So..... where is DK and mailinglists at these days? I desire to use DK on a Mailman mailinglist server... but it seems thats not possible. Should DK and Mailman be able to work without becoming domainkeys=bad? -Jim P. (newbie to dk, please be kind) |
From: SM <sm...@re...> - 2006-05-06 16:08:48
|
Hi Jim, At 23:45 05-05-2006, Jim Popovitch wrote: >So..... where is DK and mailinglists at these days? I desire to use >DK on a Mailman mailinglist server... but it seems thats not >possible. Should DK and Mailman be able to work without becoming >domainkeys=bad? The problem with mailing lists is that they modify the subject line and/or the message body without resigning the message. This mailing list, for example, adds a footer which is why DK verification of the signature of this email fails. If you are running the mail server which hosts Mailman, you can have DK-milter sign outgoing mail. Regards, -sm |
From: Jim P. <ji...@ya...> - 2006-05-06 17:52:15
|
SM wrote: > If you are running the mail server which hosts Mailman, you can have > DK-milter sign outgoing mail. I have done this and when email is sent directly from the server (shell prompt) then DK passes. If list traffic send via a test list on the same server (where dk...@te... and sa...@se... are listed as subscribers), both of those systems report that DK fails. -Jim P. |
From: SM <sm...@re...> - 2006-05-08 04:52:03
|
Hi Jim, I'm posting this as a follow-up to the problem that was resolved off-list. At 10:52 06-05-2006, Jim Popovitch wrote: >I have done this and when email is sent directly from the server >(shell prompt) then DK passes. If list traffic send via a test list >on the same server (where dk...@te... and >sa...@se... are listed as subscribers), both of those >systems report that DK fails. Thanks for helping out in test DK-milter with mailman. There seems to be a bug in dk-milter and dkim-milter when the Authentication-results: header is inserted. During canonicalization, that header is being appended after the existing Received headers of the message instead of being pre-appended when the email sent by Mailman is DK signed. DK verification fails at the subscriber's end as the DK signature is incorrect. Canonicalized form of message: Received: from mail.example.com (mail.example.com [192.0.2.1]) by mail.example.net (8.13.6/8.13.6) with ESMTP id k47IA4ON000939 for <mai...@ex...>; Sun, 7 May 2006 11:10:10 -0700 (PDT) Received: from client.example.com (client.example.com [192.0.2.2]) by mail.example.com (8.13.6/8.13.6) with ESMTP id k47I9ua6017740 for <mai...@ex...>; Sun, 7 May 2006 11:10:05 -0700 Authentication-Results: mail.example.net from=us...@ex...; domainkeys=pass (testing) Message-Id: <200...@ex...> Actual email headers: DomainKey-Signature: a=rsa-sha1; s=mail; d=example.net; c=simple; q=dns; b=L4DOned8/O7Qi0L1l37BKxHKSxib+StnxIrYLNeZrXJp15nSV305tE5C84IK4iUVN APA7dB/gXPdBymtl3IJapbsk3jWHuYnla9cS07Xdjm2GWfjLtpTwtQIUVnJaJTHFIwW ROlsxb+P8zDTWuh1eu/wqVsXSvNMV+eDA8jIi0I= Received: from mail.example.com (mail.example.com [192.0.2.1]) by mail.example.net (8.13.6/8.13.6) with ESMTP id k47IA4ON000939 for <mai...@ex...>; Sun, 7 May 2006 11:10:10 -0700 (PDT) Authentication-Results: mail.example.net from=us...@ex...; domainkeys=pass (testing) Received: from client.example.com (client.example.com [192.0.2.2]) by mail.example.com (8.13.6/8.13.6) with ESMTP id k47I9ua6017740 for <mai...@ex...>; Sun, 7 May 2006 11:10:05 -0700 Message-Id: <200...@ex...> The workaround you suggested is to configure Mailman as follows: Mailman/Handlers/CleanseDKIM.py : def process(mlist, msg, msgdata): del msg['domainkey-signature'] del msg['dkim-signature'] changed to: def process(mlist, msg, msgdata): del msg['domainkey-signature'] del msg['dkim-signature'] del msg['authentication-results'] The above was tested with dk-milter 0.3.4. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-05-08 18:11:27
|
SM wrote: > Thanks for helping out in test DK-milter with mailman. There seems to > be a bug in dk-milter and dkim-milter when the Authentication-results: > header is inserted. During canonicalization, that header is being > appended after the existing Received headers of the message instead of > being pre-appended when the email sent by Mailman is DK signed. DK > verification fails at the subscriber's end as the DK signature is > incorrect. I'm confused. What's appending signature or results headers? All three of the open source sender authentication filters we produce attempt to prepend those headers. Also, wouldn't it be sufficient simply to run dk-filter with the "-H" option? |
From: SM <sm...@re...> - 2006-05-08 18:45:25
|
Hi Murray, At 11:11 08-05-2006, Murray S. Kucherawy wrote: >I'm confused. What's appending signature or results headers? All >three of the open source sender authentication filters we produce >attempt to prepend those headers. Please refer to the example headers in my previous email. The milters are pre-appending the headers. The canonicalized headers for signing has the Authentication-Results: header (added in step 2) after the Received: headers (seen in step 5). The mail flow is as follows: 1. DK-signed mail received by MTA and verified successfully. 2. Authentication-Results header pre-appended by milter in verification mode 3. Mail passed to LDA 4. Mailman submits mail for subscribers 5. Mail goes through localhost and is signed by milter in signing mode 6. Mail received by subscriber's MTA and verification fails 7. Authentication-Results header pre-appended by milter in verification mode >Also, wouldn't it be sufficient simply to run dk-filter with the "-H" option? That would work too. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-05-08 18:52:53
|
SM wrote: > Please refer to the example headers in my previous email. The milters > are pre-appending the headers. The canonicalized headers for signing > has the Authentication-Results: header (added in step 2) after the > Received: headers (seen in step 5). Wouldn't the new signature added in step 5 correctly include the first Authentication-Results: header which was added in step 2? If order is preserved and nothing is getting modified in-place, this should still work. |
From: SM <sm...@re...> - 2006-05-08 19:03:15
|
Hi Murray, At 11:52 08-05-2006, Murray S. Kucherawy wrote: >Wouldn't the new signature added in step 5 correctly include the >first Authentication-Results: header which was added in step 2? Yes, the new signature added in step 5 includes the first Authentication-results: header which was added in step 2. >If order is preserved and nothing is getting modified in-place, this >should still work. The problem is that the order is not preserved (see previous email with sample of headers). Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-05-08 20:09:31
|
On Mon, 8 May 2006, SM wrote: >> If order is preserved and nothing is getting modified in-place, this should >> still work. > > The problem is that the order is not preserved (see previous email with > sample of headers). Were you able to determine what's doing the reordering? That would be useful data for a FAQ in the future or something. |
From: SM <sm...@re...> - 2006-05-08 20:33:27
|
Hi Murray, At 13:09 08-05-2006, Murray S. Kucherawy wrote: >Were you able to determine what's doing the reordering? That would >be useful data for a FAQ in the future or something. I went through the code over the weekend but I couldn't find where the reordering was being done. I'll see whether I can debug it and keep you posted. Regards, -sm |
From: SM <sm...@re...> - 2006-05-09 16:51:50
|
Hi Murray, At 13:09 08-05-2006, Murray S. Kucherawy wrote: >Were you able to determine what's doing the reordering? That would >be useful data for a It's because Received: headers are omitted from canonicalization in libdk/dk.c. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-05-09 18:09:42
|
SM wrote: >> Were you able to determine what's doing the reordering? That would be >> useful data for a > > It's because Received: headers are omitted from canonicalization in > libdk/dk.c. That's not true: DomainKey-Signature: a=rsa-sha1; s=medusa; d=blackops.org; c=nofws; q=dns; h=received:x-authentication-warning:date:from:to:subject: message-id:mime-version:content-type; b=O5icCTp4C4RnusRCdxhbkD4HY88yAql8LRiWvz0WpfFLhoFJT3IjSKb4HWcXa5ZAY z0nu1JJvMyZPy0Ksc97Vw== Note the "h=" value. |
From: SM <sm...@re...> - 2006-05-09 19:56:10
|
Hi Murray, At 11:09 09-05-2006, Murray S. Kucherawy wrote: >That's not true: > >DomainKey-Signature: a=rsa-sha1; s=medusa; d=blackops.org; c=nofws; q=dns; > h=received:x-authentication-warning:date:from:to:subject: > message-id:mime-version:content-type; > b=O5icCTp4C4RnusRCdxhbkD4HY88yAql8LRiWvz0WpfFLhoFJT3IjSKb4HWcXa5ZAY > z0nu1JJvMyZPy0Ksc97Vw== > >Note the "h=" value. I meant to say that the Received: headers are reordered during canonicalization. I didn't mean omitted from the signature. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2006-05-09 23:22:33
|
SM wrote: > I meant to say that the Received: headers are reordered during > canonicalization. I didn't mean omitted from the signature. Thanks for your help with tracking this down. The issue appears to be the injection of a message with duplicate but separated headers. For example, a dummy message like so: Received: data 1 Received: data 2 From: ms...@se... To: sa...@se... Subject: test test blah foo ...will sign and verify just fine. If you add "-H" (which adds the "h=" header order tag to the signature), you can even tinker with the order for the most part and it will continue to work. However, if you insert any of those headers between the two Received: headers, the signatures begin to fail. The reason for this appears to be that the header sorting and canonicalizing code anticipates your use of "-H" and thus groups like headers when canonicalizing. As such, the above instance will always work, but without "-H" this ordering will always fail: Received: data 1 From: ms...@se... Received: data 2 To: sa...@se... Subject: test test blah foo If you don't use "-H", the verifier won't know you did the grouping when signing and will replay the headers in their original order. So the sender's canonical form is what's above, but the verifier's is what's below, and you're sunk because they don't match. I'll open this as a bug and get it fixed as soon as I can. |
From: Eland S. <su...@el...> - 2006-05-06 17:59:44
|
Hi Jim, At 10:52 06-05-2006, Jim Popovitch wrote: >I have done this and when email is sent directly from the server >(shell prompt) then DK passes. If list traffic send via a test list >on the same server (where dk...@te... and >sa...@se... are listed as subscribers), both of those >systems report that DK fails. Can you subscribe my email address to that test list and generate a message? Regards, -sm |