From: Florian S. <sa...@ag...> - 2008-09-12 18:48:57
|
Hi, I found the following in the feature list of dkim-milter: SELECTOR_HEADER Enable selection of which selector (and thus which key) to use when signing based on the contents of an arbitrary header. (dkim-filter) I am looking for something similar, a SIGNINGDOMAIN_HEADER: Enable selection of which signing domain to use when signing based on the contents of an arbitrary header (default is signing by the domain in the From header). ---- Is this already possible somehow? If not I'd like to add a feature request. Maybe a fallback to the From header can be implemented if the special header is not available. The background for this feature request: DKIM's reliabilty ends at the domain level, I'd like to continue the trust-chain down to authenticated users of known/certified ISPs. ISPs want to offer to their customers they can use any From headers (=> ISPs don't want to overwrite From headers to known authenticated users). But ISPs accept to add another header to include the mailbox name of the technical sender equal to the authenticated or unique system user. So signing with the domain of the authenticated user would be more precise than using the From header (altough in most cases the "From-domainpart" is equal to the "auth'ed user-domainpart"). For example I add a X-Sender header to each mail header customers sent by SMTP-AUTH and fill its value with the authenticated user --> the signature should depend on this field. Best regards, Florian |
From: Murray S. K. <ms...@se...> - 2008-09-12 19:48:16
|
On Fri, 12 Sep 2008, Florian Sager wrote: > I am looking for something similar, a SIGNINGDOMAIN_HEADER: > Enable selection of which signing domain to use when signing based > on the > contents of an arbitrary header (default is signing by the domain in > the From > header). Doesn't the key list already support this behaviour? For example: us...@ex...:domain1.com:/path/to/keys/for/domain1/foo us...@ex...:domain2.com:/path/to/keys/for/domain2/bar The second field in that table defines the signing domain, and the selector is inferred from the path to the key, so us...@ex... signatures would include "s=foo; d=domain1.com" and us...@ex... signatures would include "s=bar; d=domain2.com". If that's not what's happening then there's a bug. |
From: Florian S. <sa...@ag...> - 2008-10-01 06:41:41
|
Murray S. Kucherawy schrieb: > On Fri, 12 Sep 2008, Florian Sager wrote: > >> I am looking for something similar, a SIGNINGDOMAIN_HEADER: >> Enable selection of which signing domain to use when signing based >> on the >> contents of an arbitrary header (default is signing by the domain in >> the From >> header). >> > > Doesn't the key list already support this behaviour? For example: > > us...@ex...:domain1.com:/path/to/keys/for/domain1/foo > us...@ex...:domain2.com:/path/to/keys/for/domain2/bar > According to my tests the first field of the list always refers to the From header. A SIGNINGDOMAIN_HEADER would help in the following case (we discussed this in our working group): An ISP (isp.tld) allows its users to use arbitrary addresses in the From header, e.g. users send mails by AUTH LOGIN my...@is...d with FROM: my...@is...d If the ISP wants to include his signatures the following could be done: 1) Add a header to the email that contains the authenticated user or its hash to get a unique user level identity inside the domain of the ISP. I am using the following Postfix Regexp in my header_checks = regexp:/etc/postfix/set_auth_sender.regexp for that: >>> if /^X-Sender: .*/ /^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ REPLACE X-Sender: $1 endif if !/^X-Sender: .*/ /^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ PREPEND X-Sender: $1 endif <<< 2) Run dkim-milter with SIGNINGDOMAIN_HEADER=X-Sender to assure that the signing domain (for which the selection in the keylist is done) refers to one of the ISPs own domains. 3) (I should post this one to the dkim-ietf list) As long as the i= attribute inside the DKIM signature is set on behalf of the signing agent I'd like to see an m= attribute that could contain the alleged mailbox that was authenticated on the signing system (if available; the content of X-Sender in my example above). If I (as the receiver) trust a sending ISP I could drag down the reliability of authentication from the signing domain level to the user level with this information (sure, an uncertainty remains; but the uncertainty is higher if I heuristically use the From-header for this drag down of the trust level). Regards, Florian |
From: SM <sm...@re...> - 2008-10-05 18:47:05
|
At 23:10 30-09-2008, Florian Sager wrote: >According to my tests the first field of the list always refers to the > From header. A SIGNINGDOMAIN_HEADER would help in the following case >(we discussed this in our working group): > >An ISP (isp.tld) allows its users to use arbitrary addresses in the From >header, e.g. users send mails by AUTH LOGIN my...@is...d with FROM: >my...@is...d >If the ISP wants to include his signatures the following could be done: > >1) Add a header to the email that contains the authenticated user or its >hash to get a unique user level identity inside the domain of the ISP. I >am using the following Postfix Regexp in my >header_checks = regexp:/etc/postfix/set_auth_sender.regexp for that: > > >>> >if /^X-Sender: .*/ >/^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ >REPLACE X-Sender: $1 >endif >if !/^X-Sender: .*/ >/^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ >PREPEND X-Sender: $1 >endif ><<< > >2) Run dkim-milter with SIGNINGDOMAIN_HEADER=X-Sender to assure that the >signing domain (for which the selection in the keylist is done) refers >to one of the ISPs own domains. That's third party (DKIM) signing. >3) (I should post this one to the dkim-ietf list) As long as the i= >attribute inside the DKIM signature is set on behalf of the signing >agent I'd like to see an m= attribute that could contain the alleged >mailbox that was authenticated on the signing system (if available; the >content of X-Sender in my example above). If I (as the receiver) trust a >sending ISP I could drag down the reliability of authentication from the >signing domain level to the user level with this information (sure, an >uncertainty remains; but the uncertainty is higher if I heuristically >use the From-header for this drag down of the trust level). The i= is the identity. It's an opaque tag and it doesn't have to match the "From:" or any other header. You could use it for an authenticated sender identity instead of creating a m= tag. BTW, it's not an alleged mailbox if the sender was authenticated. As a verifier, I may not know what the local-part of your i= tag means but I might apply a policy based on the signing domain. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2008-10-06 19:14:38
|
On Wed, 1 Oct 2008, Florian Sager wrote: > According to my tests the first field of the list always refers to the > From header. Correct. > A SIGNINGDOMAIN_HEADER would help in the following case (we discussed > this in our working group): > > An ISP (isp.tld) allows its users to use arbitrary addresses in the From > header, e.g. users send mails by AUTH LOGIN my...@is...d with FROM: > my...@is...d > If the ISP wants to include his signatures the following could be done: > > 1) Add a header to the email that contains the authenticated user or its > hash to get a unique user level identity inside the domain of the ISP. I > am using the following Postfix Regexp in my > header_checks = regexp:/etc/postfix/set_auth_sender.regexp for that: > > >>> > if /^X-Sender: .*/ > /^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ > REPLACE X-Sender: $1 > endif > if !/^X-Sender: .*/ > /^Received: .*\s+?Authenticated sender: (.*)\)\s+?by mx.mailserver.tld/ > PREPEND X-Sender: $1 > endif > <<< > > 2) Run dkim-milter with SIGNINGDOMAIN_HEADER=X-Sender to assure that the > signing domain (for which the selection in the keylist is done) refers > to one of the ISPs own domains. What's the action to be taken by dkim-filter if somehow X-Sender: didn't get added? I've actually had this as a low-priority To-Do item for some months now. If it would be really useful, add a feature request to SourceForge and I can see about getting that facility into a future release. (2.8.0 is still in development, so it might be possible to do it there.) > 3) (I should post this one to the dkim-ietf list) As long as the i= > attribute inside the DKIM signature is set on behalf of the signing > agent I'd like to see an m= attribute that could contain the alleged > mailbox that was authenticated on the signing system (if available; the > content of X-Sender in my example above). If I (as the receiver) trust a > sending ISP I could drag down the reliability of authentication from the > signing domain level to the user level with this information (sure, an > uncertainty remains; but the uncertainty is higher if I heuristically > use the From-header for this drag down of the trust level). But isn't that what i= is for in the first place? In any case, you can certainly do that among participants, but adding a new tag to the spec will require a new RFC and you'd probably need to at least start down that road to get most implementations to adopt it. |
From: Murray S. K. <ms...@se...> - 2008-10-13 22:51:29
|
On Wed, 1 Oct 2008, Florian Sager wrote: > According to my tests the first field of the list always refers to the > From header. A SIGNINGDOMAIN_HEADER would help in the following case (we > discussed this in our working group): I replied to this about two weeks ago but never got further response or a feature request on SourceForge. So: 1) Is this still a concern? 2) If so, will _FFR_SELECTOR_HEADER not suffice? |
From: Florian S. <sa...@ag...> - 2008-10-06 12:33:02
|
SM schrieb: > At 23:10 30-09-2008, Florian Sager wrote: > >> 2) Run dkim-milter with SIGNINGDOMAIN_HEADER=X-Sender to assure that the >> signing domain (for which the selection in the keylist is done) refers >> to one of the ISPs own domains. >> > > That's third party (DKIM) signing. > Yes, it *may* be, depending on the content of From. Anything wrong about that? >> 3) (I should post this one to the dkim-ietf list) As long as the i= >> attribute inside the DKIM signature is set on behalf of the signing >> agent I'd like to see an m= attribute that could contain the alleged >> mailbox that was authenticated on the signing system (if available; the >> content of X-Sender in my example above). If I (as the receiver) trust a >> sending ISP I could drag down the reliability of authentication from the >> signing domain level to the user level with this information (sure, an >> uncertainty remains; but the uncertainty is higher if I heuristically >> use the From-header for this drag down of the trust level). >> > > The i= is the identity. It's an opaque tag and it doesn't have to > match the "From:" or any other header. You could use it for an > authenticated sender identity instead of creating a m= tag. BTW, > it's not an alleged mailbox if the sender was authenticated. > As a verifier, I may not know what the local-part of your i= tag > means but I might apply a policy based on the signing domain. > Yes, that's my point: I named it an "alleged mailbox" 'cause from the receiver's viewpoint we cannot guarantee everything below the signing domain. The i= description in the RFC was too unprecise for me but I can fill it with the authenticateduser@signingdomain: how can I instruct dkim-milter to set a certain local-part in i= ? I thought an own header (that can be removed before signing) might be appropriate for that. Offtopic but DKIM-related: there is a programme fixcr for qmail that adds CRs to emails that don't use RFC conforming LFCR at line ends. DKIM relaxed header+body canonicalization don't meet this problem: fixcr-rewritten mails wouldn't DKIM validate. Do you know why this was not considered in the canonicalization algorithms? (I see no problem in adding a preventing canon. rule in general). Regards, Florian |
From: SM <sm...@re...> - 2008-10-06 15:59:01
|
At 05:32 06-10-2008, Florian Sager wrote: >Yes, it *may* be, depending on the content of From. Anything wrong about >that? I was only pointing out how we refer to such signatures. I won't call it wrong. The value of such signatures depend on what kind of assertion we make from them. >The i= description in the RFC was too unprecise for me but I can fill it >with the authenticateduser@signingdomain: how can I instruct dkim-milter >to set a certain local-part in i= ? The identity in the i= tag was explicitly not defined so that signers can apply their own semantics to it. I don't think we can set the i= in dkim-filter currently. That's doable with a patch. >I thought an own header (that can be removed before signing) might be >appropriate for that. You can file a request for enhancement for the above. It would work along the same lines as _FFR_SELECTOR_HEADER. >Offtopic but DKIM-related: there is a programme fixcr for qmail that >adds CRs to emails that don't use RFC conforming LFCR at line ends. DKIM >relaxed header+body canonicalization don't meet this problem: >fixcr-rewritten mails wouldn't DKIM validate. Do you know why this was >not considered in the canonicalization algorithms? (I see no problem in >adding a preventing canon. rule in general). There is a FixCRLF setting in dkim-milter. If you are signing, that should fix such problems. The canonicalizations algorithms expect well-formed messages as that's the only way to ensure that any "fix ups" in transit won't invalidate the DKIM signature. If we DKIM sign messages "as-is" (prevent any canonicalization rule) and the message goes through sendmail, the MTA will fix any bare CRs. To avoid that, we normalize the message to prevent such transport conversions. Regards, -sm |