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 [EMAIL PROTECTED]: 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
