From: Joe P. <jo...@sk...> - 2005-09-15 05:49:06
|
Hi all, I've been playing around with both dk-filter and now dkim-filter. Anyway, I think the concept is interesting, but I have a few questions: 1) Is dkim-filter replaceing dk-filter, or will they remain in parallel deveopment? 2) Is there a way to have the "Authentication-Results:" header line always insert itself in the email? When it does not appear, I am not sure it is because of a not-strict policy or because of a "pass." I would like to see exactly what the validation came up with for all emails, especially when testing. 3) I have set up a _policy._domainkey TXT record, but when I send a mail without a signature, it does not flag the fact that I have a missing signature. Since there are result codes for "No Signature" and "Missing," I assume the latter is for when the _policy says there should be one. Why would it not expect me to have one (i.e. doesn't it check my policy if it sees no sig to determine this - how else would it know one is missing)? 4) I assume one weakness in DKIM and DomainKeys is that a spammer could insert a "Sender:" line in a message with their own domain, thereby causing the receiver to either not check for a signature (if there is no _policy at the "Sender:" domain - see question #2) or find a valid signature (if the bogus "Sender" uses their own domain/keys/signature). Since most people would not notice the Sender: header line (most would look at the "From:" line), it seems this would be an issue. 5) If I send to an unaware mailing list server, my DKIM (or DomainKeys) signatures are preserved, and since the server changes the message, the keys would indicate a failure, of course (I know this is one of the classic problems, and until most or all mailing list servers deal with it, there's always the fear that false positives could be commonplace on mail lists). But since some mailing list servers (I know Mailman does this) insert a "Sender:" line in the header, and the Sender's domain would not match the "d=" part of the signature, why would the validation not realize the key is not a match (and thereby fail with a softer failure)? Or maybe it does realize this, but the result I see does not indicate this explicitly. BTW, I read the spec, and it implies that if DKIM sees that a "Sender:" line exists now in a message that did not have one when signed, it should resign the message. I did not see this behavior on my own Mailman server. What I had to do is change Handlers/Cleanse.py to delete the DomainKeys and DKIM header lines, and then the milters did resign. I submitted a patch to Mailman for this, so future versions should behave well with DKIM and DomainKeys... Anyway, sorry for the long email, but I am interested in following the progression of this idea! -Joe |
From: Jim F. <jf...@bl...> - 2005-09-15 16:21:44
|
Joe, I'll focus on your questions relating to the standard, and let others answer the questions about the implementation. On Wed, 2005-09-14 at 22:49, Joe Peterson wrote: > Hi all, > > I've been playing around with both dk-filter and now dkim-filter. > Anyway, I think the concept is interesting, but I have a few questions: [snip] > > 3) I have set up a _policy._domainkey TXT record, but when I send a mail > without a signature, it does not flag the fact that I have a missing > signature. Since there are result codes for "No Signature" and > "Missing," I assume the latter is for when the _policy says there should > be one. Why would it not expect me to have one (i.e. doesn't it check > my policy if it sees no sig to determine this - how else would it know > one is missing)? Assuming you're referring to the domain you sent your message from (skyrush.com), the policy you have in place is that some but not all mail is signed. In other words, unsigned messages are to be expected and not considered invalid. It should be checking the sender signing policy any time that it tries to verify a message that does not have a valid signature on behalf of the "From:" address. > 4) I assume one weakness in DKIM and DomainKeys is that a spammer could > insert a "Sender:" line in a message with their own domain, thereby > causing the receiver to either not check for a signature (if there is no > _policy at the "Sender:" domain - see question #2) or find a valid > signature (if the bogus "Sender" uses their own domain/keys/signature). > Since most people would not notice the Sender: header line (most would > look at the "From:" line), it seems this would be an issue. This is in the general category of attacks which include "posing as a mailing list". One way to address this problem is to use the "!" (also sometimes referred to as Exclusive) sender signing policy; this has the effect of invalidating third-party signatures such as those that might be applied by a mailing list that modifies the message or the signed headers. But this will still be useful to some domains that don't intend to permit modifications to their messages nor to send through mailing lists (at least, I *hope* my bank doesn't send my statement to a mailing list!). Another approach to this is to apply reputation (either third-party or a local whitelist) or accreditation results to third-party signature such as the Sender example you gave. Sender signatures from mailing lists the verifier knows and trusts might be accepted, but from others might be flagged for more scrutiny. The verifier might also try to find a way to make the Sender address more visible in such cases, which might be relatively easy if the verifier knows something about the MUA, such as in a webmail service. > 5) If I send to an unaware mailing list server, my DKIM (or DomainKeys) > signatures are preserved, and since the server changes the message, the > keys would indicate a failure, of course (I know this is one of the > classic problems, and until most or all mailing list servers deal with > it, there's always the fear that false positives could be commonplace on > mail lists). But since some mailing list servers (I know Mailman does > this) insert a "Sender:" line in the header, and the Sender's domain > would not match the "d=" part of the signature, why would the validation > not realize the key is not a match (and thereby fail with a softer > failure)? Or maybe it does realize this, but the result I see does not > indicate this explicitly. The fact that signatures might be invalidated by things like DKIM-unaware mailing lists is one of the reasons that invalid signatures can't be treated as "harder" failures than missing signatures. And if we treat messages with Sender: header fields as a softer failure, you can be sure that the Bad Guys are immediately going to add Sender: header fields, so let's not go there. > BTW, I read the spec, and it implies that if DKIM sees that a "Sender:" > line exists now in a message that did not have one when signed, it > should resign the message. I did not see this behavior on my own > Mailman server. What I had to do is change Handlers/Cleanse.py to > delete the DomainKeys and DKIM header lines, and then the milters did > resign. I submitted a patch to Mailman for this, so future versions > should behave well with DKIM and DomainKeys... I'd be interested in where you're reading that in the spec. There are lots of schools of thought on how mailing lists ought to do things, so the spec is relatively silent about that (for now). The only time when the addition of a Sender: header field should present a problem is if the h= of an existing signature contains Sender. This can happen even if there isn't a Sender header field, as a way of saying "this signature isn't valid if someone later adds a Sender header field". -Jim |
From: Joe P. <jo...@sk...> - 2005-09-15 17:50:12
|
Jim Fenton wrote: >>3) I have set up a _policy._domainkey TXT record, but when I send a mail >>without a signature, it does not flag the fact that I have a missing >>signature. Since there are result codes for "No Signature" and >>"Missing," I assume the latter is for when the _policy says there should >>be one. Why would it not expect me to have one (i.e. doesn't it check >>my policy if it sees no sig to determine this - how else would it know >>one is missing)? > > > Assuming you're referring to the domain you sent your message from > (skyrush.com), the policy you have in place is that some but not all > mail is signed. In other words, unsigned messages are to be expected > and not considered invalid. I agree that no action (like rejection or discarding) should be taken when o=~, but adding an Athentication-Result still seems like the right thing to do (maybe this is just implementation). And if indeed "missing" means a signature was even *maybe* expected, the filter would have to check the _policy for any incoming email without a signature to see if this is the case. It would be cool to be able to see, from the header, that the sender does sign some emails, and this email didn't have a signature. The policy would have to be checked anyway to see the strictness of the policy, right? > It should be checking the sender signing policy any time that it tries > to verify a message that does not have a valid signature on behalf of > the "From:" address. So are you saying the the filter should always query for the _policy if it sees no signature or one that applies? And if there is a "Sender:" line, it would be checking this, not "From:", right? >>4) I assume one weakness in DKIM and DomainKeys is that a spammer could >>insert a "Sender:" line in a message with their own domain, thereby >>causing the receiver to either not check for a signature (if there is no >>_policy at the "Sender:" domain - see question #2) or find a valid >>signature (if the bogus "Sender" uses their own domain/keys/signature). >> Since most people would not notice the Sender: header line (most would >>look at the "From:" line), it seems this would be an issue. > > > This is in the general category of attacks which include "posing as a > mailing list". One way to address this problem is to use the "!" (also > sometimes referred to as Exclusive) sender signing policy; this has the > effect of invalidating third-party signatures such as those that might > be applied by a mailing list that modifies the message or the signed > headers. But this will still be useful to some domains that don't > intend to permit modifications to their messages nor to send through > mailing lists (at least, I *hope* my bank doesn't send my statement to a > mailing list!). Good point - interesting! >>5) If I send to an unaware mailing list server, my DKIM (or DomainKeys) >>signatures are preserved, and since the server changes the message, the >>keys would indicate a failure, of course (I know this is one of the >>classic problems, and until most or all mailing list servers deal with >>it, there's always the fear that false positives could be commonplace on >>mail lists). But since some mailing list servers (I know Mailman does >>this) insert a "Sender:" line in the header, and the Sender's domain >>would not match the "d=" part of the signature, why would the validation >>not realize the key is not a match (and thereby fail with a softer >>failure)? Or maybe it does realize this, but the result I see does not >>indicate this explicitly. > > > The fact that signatures might be invalidated by things like > DKIM-unaware mailing lists is one of the reasons that invalid signatures > can't be treated as "harder" failures than missing signatures. And if > we treat messages with Sender: header fields as a softer failure, you > can be sure that the Bad Guys are immediately going to add Sender: > header fields, so let's not go there. I see your point. What I was thinking is that the verifier would know, due to the mismatch of the domains between the signature and the sender, that the signature doesn't apply. So it really is like a missing signature, or maybe a "stale" one. But you are right that it shouldn't treat it more leniently. Is the filter even supposed to do this check and differentiate the error of no applicable signature vs. a bad one (i.e. I know the signer deduces the sender in order to sign, but does the verifier even look for a sender, or does it see a signature and immediately try to validate the messages based on it? Since multiple signatures seem to be discussed a little in the draft, I would think the filter is supposed to do a check)? >>BTW, I read the spec, and it implies that if DKIM sees that a "Sender:" >>line exists now in a message that did not have one when signed, it >>should resign the message. I did not see this behavior on my own >>Mailman server. What I had to do is change Handlers/Cleanse.py to >>delete the DomainKeys and DKIM header lines, and then the milters did >>resign. I submitted a patch to Mailman for this, so future versions >>should behave well with DKIM and DomainKeys... > > > I'd be interested in where you're reading that in the spec. There are > lots of schools of thought on how mailing lists ought to do things, so > the spec is relatively silent about that (for now). The only time when > the addition of a Sender: header field should present a problem is if > the h= of an existing signature contains Sender. This can happen even > if there isn't a Sender header field, as a way of saying "this signature > isn't valid if someone later adds a Sender header field". I apologize - I was remember reading it in the DomainKeys spec (draft-delany-domainkeys-base-02.txt), not the DKIM one: 'A signer MUST NOT sign an email that already contains a "DomainKey-Signature:" header unless a "Sender:" header has been added that was not included in the original signature. The most obvious case where this occurs is with mailing lists.' I had read into this that re-signing implies removing the old signature(s). But it also states that 'A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.' In any case, with DKIM, I assume a mail list system should not be doing the signing ("re-signing"), but rather just preparing the email to the MTA/milter will sign it. In the Mailman case, my patch of removing the old [now invalid] signatures allows dkim-milter to re-sign, whereas leaving the signatures in causes it to not re-sign. Thanks for the response! Joe |
From: Jim F. <jf...@bl...> - 2005-09-16 05:26:21
|
On Thu, 2005-09-15 at 10:50, Joe Peterson wrote: > Jim Fenton wrote: > >>3) I have set up a _policy._domainkey TXT record, but when I send a mail > >>without a signature, it does not flag the fact that I have a missing > >>signature. Since there are result codes for "No Signature" and > >>"Missing," I assume the latter is for when the _policy says there should > >>be one. Why would it not expect me to have one (i.e. doesn't it check > >>my policy if it sees no sig to determine this - how else would it know > >>one is missing)? > > > > > > Assuming you're referring to the domain you sent your message from > > (skyrush.com), the policy you have in place is that some but not all > > mail is signed. In other words, unsigned messages are to be expected > > and not considered invalid. > > I agree that no action (like rejection or discarding) should be taken > when o=~, but adding an Athentication-Result still seems like the right > thing to do (maybe this is just implementation). And if indeed > "missing" means a signature was even *maybe* expected, the filter would > have to check the _policy for any incoming email without a signature to > see if this is the case. It would be cool to be able to see, from the > header, that the sender does sign some emails, and this email didn't > have a signature. The policy would have to be checked anyway to see the > strictness of the policy, right? Well, I think this IS an implementation thing, but anyway: the policy you have ("~", which means "I sometimes sign messages") is currently the default. The fact that you sign some emails shouldn't make unsigned messages seem less legitimate; that would discourage incremental deployment by domains. So since it's the default, I guess it's a toss up whether it should add Authentication-Results reporting "neutral" or not. There is some discussion that the default should instead be "I don't sign anything", in effect requiring all domains that implement DKIM to publish policy records. I don't consider that matter settled yet. > > > It should be checking the sender signing policy any time that it tries > > to verify a message that does not have a valid signature on behalf of > > the "From:" address. > > So are you saying the the filter should always query for the _policy if > it sees no signature or one that applies? And if there is a "Sender:" > line, it would be checking this, not "From:", right? As the signing policy spec is currently written, the From address is special in one respect: a valid signature for that address is considered a "first party" signature, and allows the verifier to skip the signing policy check. There is one special case involving Sender, which is the extremely rare use of multiple addresses in the From header, in which case the Sender address is used instead. But for all practical purposes, it's just the From address that matters. > >>5) If I send to an unaware mailing list server, my DKIM (or DomainKeys) > >>signatures are preserved, and since the server changes the message, the > >>keys would indicate a failure, of course (I know this is one of the > >>classic problems, and until most or all mailing list servers deal with > >>it, there's always the fear that false positives could be commonplace on > >>mail lists). But since some mailing list servers (I know Mailman does > >>this) insert a "Sender:" line in the header, and the Sender's domain > >>would not match the "d=" part of the signature, why would the validation > >>not realize the key is not a match (and thereby fail with a softer > >>failure)? Or maybe it does realize this, but the result I see does not > >>indicate this explicitly. > > > > > > The fact that signatures might be invalidated by things like > > DKIM-unaware mailing lists is one of the reasons that invalid signatures > > can't be treated as "harder" failures than missing signatures. And if > > we treat messages with Sender: header fields as a softer failure, you > > can be sure that the Bad Guys are immediately going to add Sender: > > header fields, so let's not go there. > > I see your point. What I was thinking is that the verifier would know, > due to the mismatch of the domains between the signature and the sender, > that the signature doesn't apply. So it really is like a missing > signature, or maybe a "stale" one. But you are right that it shouldn't > treat it more leniently. Is the filter even supposed to do this check > and differentiate the error of no applicable signature vs. a bad one > (i.e. I know the signer deduces the sender in order to sign, but does > the verifier even look for a sender, or does it see a signature and > immediately try to validate the messages based on it? Since multiple > signatures seem to be discussed a little in the draft, I would think the > filter is supposed to do a check)? I haven't come up with a case where an invalid signature should be treated any differently from one that isn't present, at least with respect to how the message should be treated by the verifier and recipient. It's up to the verifier whether it looks at the signature first and tries to verify it or just verifies all the signatures and then sees what the role of each signature is (From address, resender, mailing list, etc.). I would think it to be more efficient to start with the signatures that look most useful (probably the one corresponding to the >From address) and then decide whether it's worth checking the others. > > >>BTW, I read the spec, and it implies that if DKIM sees that a "Sender:" > >>line exists now in a message that did not have one when signed, it > >>should resign the message. I did not see this behavior on my own > >>Mailman server. What I had to do is change Handlers/Cleanse.py to > >>delete the DomainKeys and DKIM header lines, and then the milters did > >>resign. I submitted a patch to Mailman for this, so future versions > >>should behave well with DKIM and DomainKeys... > > > > > > I'd be interested in where you're reading that in the spec. There are > > lots of schools of thought on how mailing lists ought to do things, so > > the spec is relatively silent about that (for now). The only time when > > the addition of a Sender: header field should present a problem is if > > the h= of an existing signature contains Sender. This can happen even > > if there isn't a Sender header field, as a way of saying "this signature > > isn't valid if someone later adds a Sender header field". > > I apologize - I was remember reading it in the DomainKeys spec > (draft-delany-domainkeys-base-02.txt), not the DKIM one: > > 'A signer MUST NOT sign an email that already contains a > "DomainKey-Signature:" header unless a "Sender:" header has been added > that was not included in the original signature. The most obvious case > where this occurs is with mailing lists.' > > I had read into this that re-signing implies removing the old > signature(s). But it also states that 'A signer SHOULD NOT remove an > existing "DomainKey-Signature:" header.' This is a frequent topic of debate. I'm mostly in the "don't throw anything out" camp. > In any case, with DKIM, I assume a mail list system should not be doing > the signing ("re-signing"), but rather just preparing the email to the > MTA/milter will sign it. In the Mailman case, my patch of removing the > old [now invalid] signatures allows dkim-milter to re-sign, whereas > leaving the signatures in causes it to not re-sign. I have thought that the MTA would usually sign, but the mailing list could do so as well. There's at least one case I know of where the domain doesn't want to sign everything, but a mailing list hosted there wants to start re-signing, so we'll probably need to figure out a hook for Mailman (and other list managers) at some point. -Jim |
From: Joe P. <jo...@sk...> - 2005-09-16 14:08:29
|
Jim Fenton wrote: > Well, I think this IS an implementation thing, but anyway: the policy > you have ("~", which means "I sometimes sign messages") is currently the > default. The fact that you sign some emails shouldn't make unsigned > messages seem less legitimate; that would discourage incremental > deployment by domains. So since it's the default, I guess it's a toss > up whether it should add Authentication-Results reporting "neutral" or > not. > > There is some discussion that the default should instead be "I don't > sign anything", in effect requiring all domains that implement DKIM to > publish policy records. I don't consider that matter settled yet. I see. Yes, it does seem that someone who publishes a policy should be seen differently, since there are so many domains out there that don't use, or have never even considered, DK or DKIM. If a policy exists, clearly that domain has thought about it and/or intends to sign messages. So I agree that the default should probably change, and it should be required to set a policy if you use DK or DKIM. If a signed message comes from such a domain, I guess it would make sense to ignore the signature... In fact, it would be nice to have a policy of "I sign most emails" or something similar - that would give the same "out," but the receiver could look more carefully at non-signed messages or bad sigs. > As the signing policy spec is currently written, the From address is > special in one respect: a valid signature for that address is > considered a "first party" signature, and allows the verifier to skip > the signing policy check. There is one special case involving Sender, > which is the extremely rare use of multiple addresses in the From > header, in which case the Sender address is used instead. But for all > practical purposes, it's just the From address that matters. I guess that might change (i.e. you'd need to check the _policy) if the default policy changes. It might make things more "defined" if the policy is always checked anyway. >>signature(s). But it also states that 'A signer SHOULD NOT remove an >>existing "DomainKey-Signature:" header.' > > > This is a frequent topic of debate. I'm mostly in the "don't throw > anything out" camp. Yes, probably better, but the current dkim-milter will not add a new signature unless the old one is removed first (this is why I patched Mailman to remove old sigs). In fact, I wonder if it's defined how the milter is supposed to know to "re-sign" if it sees a sig already. -Joe |
From: Joe P. <jo...@sk...> - 2005-09-23 15:40:41
|
I've been doing some more testing dkim-milter in various scenarios (including sending directly and sending through mailing lists), and I wanted to post my results for discussion. I run Mailman mailing lists on two different servers, so I am able to test both with and without my patch that removes previous signatures. I also patched my copy of dkim-milter to always include "Authentication-Results:" so I can see the result, even if the result is "no signature". I am not sure if these are implementation issues or specification issues. --------- Scenario #1: No _policy published and no sig Authentication-Results: shadow.wildlava.net header.unknown=unknown; dkim=fail (no signature) In this case, I sent mail to myself from a domain that does not do DKIM at all. There is no _policy published, and there is no signature in the header. Forcing the results to appear, I get the above, indicating a failure with no signature, and I assume header is "unknown" because there is no sig). This seems wrong to me - if the domain does not publish a _policy, the verifier should not expect a signature, and therefore it should not "fail." It could report that it saw no sig, but that none was expected either. I would think retults would be neutral at worst, but maybe even something different, like "no result" to say that it simply has no information. ---------- Scenario #2: A _policy published ("o=~all") but no sig Authentication-Results: shadow.wildlava.net header.unknown=unknown; dkim=fail (no signature) This is the same result as #1, so I assume whether the _policy is published does not make a difference in this implementation. I do expect that it would complain about no signature, but getting a "fail" is strange, since with this policy ("~all"), a bad signature gets a "neutral" in this implementation. ----------- Scenario #3: A _policy published ("o=~all") with valid sig Authentication-Results: shadow.wildlava.net header.From=jo...@sk...; dkim=pass This is the expected result. ----------- Scenario #4: Through Mailman, old sig removed Authentication-Results: shadow.wildlava.net header.Sender=tes...@sk...; dkim=pass This is the expected result, and the header shows the sender instead of the from, which makes sense, since the "From" signature was removed by [patched] Mailman. ----------- Scenario #5: Through Mailman, old sig not removed Authentication-Results: shadow.wildlava.net header.From=jo...@sk...; dkim=neutral (verification failed) This is a strange one, since the verifier went ahead and used the "From" signature, even though there is now a "Sender" line in the header. And no report was made regarding the fact that a signature using the "Sender" was not found. The receiver only knows now that the verification failed. So I think it's misleading, since this case is more of a missing signature case (not that it should be treated any more leniently, but the receiver should probably know that this is a mail list resend failing the "From" check only, otherwise, if the "From" domain changes it's policy to "-all", mail could get tossed). I can imagine cases in which the domain would want to set to "-all" (if it signs all outgoing email) without knowing that mailing lists will be basically useless for any users on the domain (since there is no control over whether all mail lists one desires to use start using DKIM, etc.). If DKIM becomes adopted, I know I'd want my domain to be able to use "-all" - otherwise the strength of DKIM is diminished. But if I then could never use a mailing list, that would be a problem, so no one but banks or other such entities would ever be able to use the strength of DKIM. ----------- I cannot easily test the multiple signature case through mail lists (i.e. if a "Sender:" line appears and gets signed by the mail list server), since dkim-milter will not add a new sig to an email that already has one, even if there is now a new "Sender:" line. And I would expect to see, perhaps, both results - the one for the "From" case and the one for the "Sender" case - it could then decide what to do based on that, since it has the full info. Of course, the results of a missing sig for From or Sender should probably include whether or not there was a _policy and what that policy was. -Joe |
From: Jim F. <fe...@bl...> - 2005-09-16 05:17:13
|
On Thu, 2005-09-15 at 10:50, Joe Peterson wrote: > Jim Fenton wrote: > >>3) I have set up a _policy._domainkey TXT record, but when I send a mail > >>without a signature, it does not flag the fact that I have a missing > >>signature. Since there are result codes for "No Signature" and > >>"Missing," I assume the latter is for when the _policy says there should > >>be one. Why would it not expect me to have one (i.e. doesn't it check > >>my policy if it sees no sig to determine this - how else would it know > >>one is missing)? > > > > > > Assuming you're referring to the domain you sent your message from > > (skyrush.com), the policy you have in place is that some but not all > > mail is signed. In other words, unsigned messages are to be expected > > and not considered invalid. > > I agree that no action (like rejection or discarding) should be taken > when o=~, but adding an Athentication-Result still seems like the right > thing to do (maybe this is just implementation). And if indeed > "missing" means a signature was even *maybe* expected, the filter would > have to check the _policy for any incoming email without a signature to > see if this is the case. It would be cool to be able to see, from the > header, that the sender does sign some emails, and this email didn't > have a signature. The policy would have to be checked anyway to see the > strictness of the policy, right? Well, I think this IS an implementation thing, but anyway: the policy you have ("~", which means "I sometimes sign messages") is currently the default. The fact that you sign some emails shouldn't make unsigned messages seem less legitimate; that would discourage incremental deployment by domains. So since it's the default, I guess it's a toss up whether it should add Authentication-Results reporting "neutral" or not. There is some discussion that the default should instead be "I don't sign anything", in effect requiring all domains that implement DKIM to publish policy records. I don't consider that matter settled yet. > > It should be checking the sender signing policy any time that it tries > > to verify a message that does not have a valid signature on behalf of > > the "From:" address. > > So are you saying the the filter should always query for the _policy if > it sees no signature or one that applies? And if there is a "Sender:" > line, it would be checking this, not "From:", right? As the signing policy spec is currently written, the From address is special in one respect: a valid signature for that address is considered a "first party" signature, and allows the verifier to skip the signing policy check. There is one special case involving Sender, which is the extremely rare use of multiple addresses in the From header, in which case the Sender address is used instead. But for all practical purposes, it's just the From address that matters. > >>5) If I send to an unaware mailing list server, my DKIM (or DomainKeys) > >>signatures are preserved, and since the server changes the message, the > >>keys would indicate a failure, of course (I know this is one of the > >>classic problems, and until most or all mailing list servers deal with > >>it, there's always the fear that false positives could be commonplace on > >>mail lists). But since some mailing list servers (I know Mailman does > >>this) insert a "Sender:" line in the header, and the Sender's domain > >>would not match the "d=" part of the signature, why would the validation > >>not realize the key is not a match (and thereby fail with a softer > >>failure)? Or maybe it does realize this, but the result I see does not > >>indicate this explicitly. > > > > > > The fact that signatures might be invalidated by things like > > DKIM-unaware mailing lists is one of the reasons that invalid signatures > > can't be treated as "harder" failures than missing signatures. And if > > we treat messages with Sender: header fields as a softer failure, you > > can be sure that the Bad Guys are immediately going to add Sender: > > header fields, so let's not go there. > > I see your point. What I was thinking is that the verifier would know, > due to the mismatch of the domains between the signature and the sender, > that the signature doesn't apply. So it really is like a missing > signature, or maybe a "stale" one. But you are right that it shouldn't > treat it more leniently. Is the filter even supposed to do this check > and differentiate the error of no applicable signature vs. a bad one > (i.e. I know the signer deduces the sender in order to sign, but does > the verifier even look for a sender, or does it see a signature and > immediately try to validate the messages based on it? Since multiple > signatures seem to be discussed a little in the draft, I would think the > filter is supposed to do a check)? I haven't come up with a case where an invalid signature should be treated any differently from one that isn't present, at least with respect to how the message should be treated by the verifier and recipient. It's up to the verifier whether it looks at the signature first and tries to verify it or just verifies all the signatures and then sees what the role of each signature is (From address, resender, mailing list, etc.). I would think it to be more efficient to start with the signatures that look most useful (probably the one corresponding to the >From address) and then decide whether it's worth checking the others. > >>BTW, I read the spec, and it implies that if DKIM sees that a "Sender:" > >>line exists now in a message that did not have one when signed, it > >>should resign the message. I did not see this behavior on my own > >>Mailman server. What I had to do is change Handlers/Cleanse.py to > >>delete the DomainKeys and DKIM header lines, and then the milters did > >>resign. I submitted a patch to Mailman for this, so future versions > >>should behave well with DKIM and DomainKeys... > > > > > > I'd be interested in where you're reading that in the spec. There are > > lots of schools of thought on how mailing lists ought to do things, so > > the spec is relatively silent about that (for now). The only time when > > the addition of a Sender: header field should present a problem is if > > the h= of an existing signature contains Sender. This can happen even > > if there isn't a Sender header field, as a way of saying "this signature > > isn't valid if someone later adds a Sender header field". > > I apologize - I was remember reading it in the DomainKeys spec > (draft-delany-domainkeys-base-02.txt), not the DKIM one: > > 'A signer MUST NOT sign an email that already contains a > "DomainKey-Signature:" header unless a "Sender:" header has been added > that was not included in the original signature. The most obvious case > where this occurs is with mailing lists.' > > I had read into this that re-signing implies removing the old > signature(s). But it also states that 'A signer SHOULD NOT remove an > existing "DomainKey-Signature:" header.' This is a frequent topic of debate. I'm mostly in the "don't throw anything out" camp. > In any case, with DKIM, I assume a mail list system should not be doing > the signing ("re-signing"), but rather just preparing the email to the > MTA/milter will sign it. In the Mailman case, my patch of removing the > old [now invalid] signatures allows dkim-milter to re-sign, whereas > leaving the signatures in causes it to not re-sign. I have thought that the MTA would usually sign, but the mailing list could do so as well. There's at least one case I know of where the domain doesn't want to sign everything, but a mailing list hosted there wants to start re-signing, so we'll probably need to figure out a hook for Mailman (and other list managers) at some point. -Jim |
From: Murray S. K. <ms...@se...> - 2005-09-15 18:36:39
|
Jim covered the spec-related issues, so I'll cover the implementation ones: On Wed, 14 Sep 2005, Joe Peterson wrote: > 1) Is dkim-filter replaceing dk-filter, or will they remain in parallel > deveopment? I don't have any plans to discontinue dk-filter, but DK itself does not appear likely to undergo further evolution at the moment so it's largely dormant unless bugs are found or some really good feature ideas pop up. DKIM is the hotter one, so further releases are likely. A patch has been provided which will allow dkim-filter to verify DK signatures as well as DKIM signatures, so I will probably roll that into the next release. > 2) Is there a way to have the "Authentication-Results:" header line > always insert itself in the email? When it does not appear, I am not > sure it is because of a not-strict policy or because of a "pass." I > would like to see exactly what the validation came up with for all > emails, especially when testing. The header is always added if a signature was present, regardless of whether or not verification passes. It's omitted only if there was no signature on the message and the sending domain doesn't advertise a "signs-all" policy. > 3) I have set up a _policy._domainkey TXT record, but when I send a mail > without a signature, it does not flag the fact that I have a missing > signature. Since there are result codes for "No Signature" and > "Missing," I assume the latter is for when the _policy says there should > be one. Why would it not expect me to have one (i.e. doesn't it check > my policy if it sees no sig to determine this - how else would it know > one is missing)? This is basically answered above; you won't get a status on the message if it was unsigned and comes from a domain which doesn't claim to sign everything. But yes, the policy record will be checked to determine the signer's policy. |
From: Joe P. <jo...@sk...> - 2005-09-15 18:50:45
|
Murray S. Kucherawy wrote: >>3) I have set up a _policy._domainkey TXT record, but when I send a mail >>without a signature, it does not flag the fact that I have a missing >>signature. Since there are result codes for "No Signature" and >>"Missing," I assume the latter is for when the _policy says there should >>be one. Why would it not expect me to have one (i.e. doesn't it check >>my policy if it sees no sig to determine this - how else would it know >>one is missing)? > > > This is basically answered above; you won't get a status on the message if > it was unsigned and comes from a domain which doesn't claim to sign > everything. But yes, the policy record will be checked to determine the > signer's policy. Murray, thanks. I expected to see the results on mails to myself, but I suspect it's just not in verification mode in that case. That begs the other question: if there is a signature there already, the filter would not try to re-sign, of course, but it might be good for it to then go into verification mode, even if it meets the other requirements for signing (-d, -i, -m, etc.), so self-sent mails can be verified. It would be nice to have (at least an option) to see the results even if the policy was not to "sign all." That way, at least the status could be seen, and you'd know that there was a policy for the domain at all. I know no strict action is supposed to be taken, but to have the info there to look at would be great. What do yo think? -Joe |
From: Murray S. K. <ms...@se...> - 2005-09-15 18:58:21
|
On Thu, 15 Sep 2005, Joe Peterson wrote: > I expected to see the results on mails to myself, but I suspect it's > just not in verification mode in that case. That begs the other > question: if there is a signature there already, the filter would not > try to re-sign, of course, but it might be good for it to then go into > verification mode, even if it meets the other requirements for signing > (-d, -i, -m, etc.), so self-sent mails can be verified. You can arrange this. To keep the filters sane against other milters in use that might modify a message in transit, some people set up two instances of dkim-milter. One is in signing-only mode at the end of the chain, and one is in verifying-only mode at the beginning of the chain. A single instance is only ever in one mode, but you can force the mode using command line options and do it that way if you really want to verify mail that both originates and delivers locally. (Or at least that *should* work; I've not tried it.) > It would be nice to have (at least an option) to see the results even if > the policy was not to "sign all." That way, at least the status could > be seen, and you'd know that there was a policy for the domain at all. I > know no strict action is supposed to be taken, but to have the info > there to look at would be great. What do yo think? Sure, if you would find that useful then you can file a feature request on Sourceforge and I'll look at adding it in a future release. |
From: Joe P. <jo...@sk...> - 2005-09-15 19:09:42
|
Murry, one more question prompted by the headers on the recent emails you sent... I have both dk-filter and dkim-filter checking incoming email. I also have the "-h" flags on that inserts the "X-..." header lines. For mails sent to myself, I see both DKIM and DK "X-..." header lines. For mail from you, which went through the Sourceforge Mailman (and there fore will fail the signature test), I only see the "X-DKIM" line (not DK). Also, you only have a DK sig, so I would not expect to see an Authorization-Result for DKIM, but I would expect to see a fail result for DK, but there is none. When I look in my maillog, I see: Sep 15 12:59:19 shadow dk-filter[26566]: j8FIxJiK027075: signature verification failed This is for your most recent email, so the dk-filter sees it, but I see no header lines about it. Do you know why? Thanks, Joe |
From: Murray S. K. <ms...@se...> - 2005-09-15 20:15:15
|
On Thu, 15 Sep 2005, Joe Peterson wrote: > For mail from you, which went through the Sourceforge Mailman (and there > fore will fail the signature test), I only see the "X-DKIM" line (not > DK). Also, you only have a DK sig, so I would not expect to see an > Authorization-Result for DKIM, but I would expect to see a fail result > for DK, but there is none. Which servers are adding those headers? The header contains the hostname that added it. Are you sure they're our headers and not yours? sendmail.com is currently only signing with DK, I believe. We are adding a X-DomainKeys: header on outgoing mail too (just tried it). There's no X-DKIM: line from any of our servers. > When I look in my maillog, I see: > > Sep 15 12:59:19 shadow dk-filter[26566]: j8FIxJiK027075: signature > verification failed That would be beacuse of the mailman alterations of the message. > This is for your most recent email, so the dk-filter sees it, but I see > no header lines about it. Do you know why? We don't assert a "signs-all" DK policy. We're also advertising that DK is in test here. |
From: Joe P. <jo...@sk...> - 2005-09-15 20:34:54
Attachments:
murray_header.txt
|
Murray, I am attaching the full message and headers from the message you just sent. As you can see, there is one X-DKIM with my domain (wildlava.net), so this is from my server. The DomainKey sig is from your server, of course. On emails from myself to myself, I also see a X-DomainKey line (since I run both filters), but not yours (I'd expect to see this for anything my server processes). Why would I see the X-DKIM put there by my server but not the X-DomainKey? And yeah, I expect the failure because of sendmail.net's Mailman, but I figured I'd see an Authorization-Results like from the failure, since your email did contain a signature. I thought what you were saying before is that those Authorization-Results lines only *don't appear* if the email does not have a signature and if the policy is not "sign all." But since it did contain a sig, shouldn't it show the failure result regardless of policy? Thanks, Joe Murray S. Kucherawy wrote: > On Thu, 15 Sep 2005, Joe Peterson wrote: > >>For mail from you, which went through the Sourceforge Mailman (and there >>fore will fail the signature test), I only see the "X-DKIM" line (not >>DK). Also, you only have a DK sig, so I would not expect to see an >>Authorization-Result for DKIM, but I would expect to see a fail result >>for DK, but there is none. > > > Which servers are adding those headers? The header contains the hostname > that added it. Are you sure they're our headers and not yours? > > sendmail.com is currently only signing with DK, I believe. We are adding > a X-DomainKeys: header on outgoing mail too (just tried it). There's no > X-DKIM: line from any of our servers. > > >>When I look in my maillog, I see: >> >>Sep 15 12:59:19 shadow dk-filter[26566]: j8FIxJiK027075: signature >>verification failed > > > That would be beacuse of the mailman alterations of the message. > > >>This is for your most recent email, so the dk-filter sees it, but I see >>no header lines about it. Do you know why? > > > We don't assert a "signs-all" DK policy. We're also advertising that DK > is in test here. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > dkim-milter-discuss mailing list > dki...@li... > https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss > |
From: Murray S. K. <ms...@se...> - 2005-09-15 20:51:48
|
On Thu, 15 Sep 2005, Joe Peterson wrote: > Murray, I am attaching the full message and headers from the message you > just sent. As you can see, there is one X-DKIM with my domain > (wildlava.net), so this is from my server. The DomainKey sig is from > your server, of course. On emails from myself to myself, I also see a > X-DomainKey line (since I run both filters), but not yours (I'd expect > to see this for anything my server processes). Why would I see the > X-DKIM put there by my server but not the X-DomainKey? I don't understand. There is an X-DomainKeys: header from us in the message you included. It is immediately above the signature. X-DomainKeys: might be omitted if, for example, the filter is in "sign" mode but isn't signing your message. This is decided at the end of the headers if conditions required for signing your message aren't met (i.e. it's a domain for which you sign, from a source for which you should be signing, etc.). The process is short-circuited if the filter decides no action is required. A side effect of that decision is the X-*: header is not added. I should probably fix that if/when I ever do another release of dk-milter. You can open it as a bug if you like. dkim-milter has the same issue. However, that's not the case here. > And yeah, I expect the failure because of sendmail.net's Mailman, but I > figured I'd see an Authorization-Results like from the failure, since > your email did contain a signature. I thought what you were saying > before is that those Authorization-Results lines only *don't appear* if > the email does not have a signature and if the policy is not "sign all." > But since it did contain a sig, shouldn't it show the failure result > regardless of policy? You should be seeing failures to verify messages from me through Sourceforge's Mailman, because it alters the message. I'll see if I can reproduce what you're seeing. |
From: Joe P. <jo...@sk...> - 2005-09-15 21:01:09
|
Murray S. Kucherawy wrote: > I don't understand. There is an X-DomainKeys: header from us in the > message you included. It is immediately above the signature. Right - I see that one, but look at the top where there is a X-DKIM but no X-DomainKey line from *my* server. That's the one that's strange. > X-DomainKeys: might be omitted if, for example, the filter is in "sign" > mode but isn't signing your message. This is decided at the end of the > headers if conditions required for signing your message aren't met (i.e. > it's a domain for which you sign, from a source for which you should be > signing, etc.). The process is short-circuited if the filter decides no > action is required. A side effect of that decision is the X-*: header is > not added. Hmm, well, in the message from you, my signing criteria are not met, so it should be in filter mode, right? In fact, the error in the maillog indicated a failed verification of DomainKeys, but I didn't see an X-DomainKey line or an Authorization-Results line. > I should probably fix that if/when I ever do another release of dk-milter. > You can open it as a bug if you like. dkim-milter has the same issue. > However, that's not the case here. It *seems* that dkim-milter does not exihibit this - see my next email with the headers from my own message through sourceforge. It looks like dkim-milter is doing what I'd expect there. > You should be seeing failures to verify messages from me through > Sourceforge's Mailman, because it alters the message. I'll see if I can > reproduce what you're seeing. OK, let me know if I can help! -Joe |
From: Murray S. K. <ms...@se...> - 2005-09-15 21:07:46
|
On Thu, 15 Sep 2005, Joe Peterson wrote: > Hmm, well, in the message from you, my signing criteria are not met, so > it should be in filter mode, right? In fact, the error in the maillog > indicated a failed verification of DomainKeys, but I didn't see an > X-DomainKey line or an Authorization-Results line. What command line flags are you using? If it's in sign-only mode ("-b s") and signing critera aren't met, the filter will do the short-circuit and fail to add the header. That's one example I can think of which would cause X-DomainKeys: to be omitted. |
From: Joe P. <jo...@sk...> - 2005-09-15 21:12:19
|
For dk-filter (the one in question), I'm using: dk-filter -l -h -c nofws -p /var/domainkeys/dk-filter.sock -i /var/domainkeys/ilist -s /var/domainkeys/dk3.private -S dk3 -P /var/domainkeys/dk-filter.pid -u domainkeys I'm not using any "-b" flag at this time. So it seems to me it should be going to verify mode. -Joe Murray S. Kucherawy wrote: > On Thu, 15 Sep 2005, Joe Peterson wrote: > >>Hmm, well, in the message from you, my signing criteria are not met, so >>it should be in filter mode, right? In fact, the error in the maillog >>indicated a failed verification of DomainKeys, but I didn't see an >>X-DomainKey line or an Authorization-Results line. > > > What command line flags are you using? > > If it's in sign-only mode ("-b s") and signing critera aren't met, the > filter will do the short-circuit and fail to add the header. That's one > example I can think of which would cause X-DomainKeys: to be omitted. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > dkim-milter-discuss mailing list > dki...@li... > https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss > |
From: Joe P. <jo...@sk...> - 2005-09-15 21:20:05
|
One thing different is that I omitted the "-d" flag, since I am not signing with DK (I use the -d flag on DKIM). I wonder if that's tripping it up somehow? Joe Peterson wrote: > For dk-filter (the one in question), I'm using: > > dk-filter -l -h -c nofws -p /var/domainkeys/dk-filter.sock -i > /var/domainkeys/ilist -s /var/domainkeys/dk3.private -S dk3 -P > /var/domainkeys/dk-filter.pid -u domainkeys > > I'm not using any "-b" flag at this time. So it seems to me it should > be going to verify mode. > > -Joe > > Murray S. Kucherawy wrote: > >>On Thu, 15 Sep 2005, Joe Peterson wrote: >> >> >>>Hmm, well, in the message from you, my signing criteria are not met, so >>>it should be in filter mode, right? In fact, the error in the maillog >>>indicated a failed verification of DomainKeys, but I didn't see an >>>X-DomainKey line or an Authorization-Results line. >> >> >>What command line flags are you using? >> >>If it's in sign-only mode ("-b s") and signing critera aren't met, the >>filter will do the short-circuit and fail to add the header. That's one >>example I can think of which would cause X-DomainKeys: to be omitted. >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: >>Tame your development challenges with Apache's Geronimo App Server. Download >>it for free - -and be entered to win a 42" plasma tv or your very own >>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>_______________________________________________ >>dkim-milter-discuss mailing list >>dki...@li... >>https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > dkim-milter-discuss mailing list > dki...@li... > https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss > |
From: Joe P. <jo...@sk...> - 2005-09-15 20:42:55
Attachments:
joe_header.txt
|
Just for comparrison, I have attached a copy of my own mail through the mailing list. As you can see, I am signing with DKIM only, and I can see the "X-" header lines for both DKIM and DK put there by my server (wildlava.net). Also, I see the Authentication-Results line showing the DKIM failure due to Mailman. So this is what I expect, but why your email produces different results is strange, unless it's a bug in dk-filter. -Joe |