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 [EMAIL PROTECTED] with FROM: > [EMAIL PROTECTED] > 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. ------------------------------------------------------------------------- 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
