Here's a followup on an old thread. Maybe this has been answered already
elsewhere in the meantime.

>> -----Original Message-----
>> From: Murray S. Kucherawy [mailto:[email protected]]
>> Sent: Monday, July 27, 2009 8:56 AM
>> To: dkim-milter general discussion
>> Subject: Re: [dkim-milter-discuss] Verification not failing
>> 
>> There's still an issue in there.  In this case, it's possibly that
>> unsigned mail is skipping the ADSP check altogether, and defaulting to
>> reporting "none".  I need to take a closer look.
> 

It doesn't. It definitely works as it should ... except, things may fail
if a Sender: header is present - as discussed earlier in this thread.

> I was wrong; simply, _FFR_SENDER_HEADERS is missing an important step in 
> doing what it claims to do.
> 
> I'll post a patch when I can get the diffs right.
> 

FWIW, here is a quick patch that fixes ADSP with dkim-milter 2.8.3 for me:

--- dkim-milter-2.8.3/libdkim/dkim.c.orig       2009-04-02 14:38:29.000000000
-0400
+++ dkim-milter-2.8.3/libdkim/dkim.c    2010-03-13 23:38:08.000000000 -0500
@@ -166,12 +166,14 @@
 /* macros */
 #define DKIM_ISLWSP(x)  ((x) == 011 || (x) == 013 || (x) == 014 || (x)
== 040)

-/* list of headers which may contain the sender */
+/* list of headers which may contain the ADSP author domain */
 const u_char *default_senderhdrs[] =
 {
+/*
        "resent-sender",
        "resent-from",
        "sender",
+*/
        "from",
        NULL
 };

If I understand the ADSP RFC correctly, the ADSP policy check is always
done for the From: domain, even if Sender: or similar is present. It
doesn't look like the current dkim-milter implements this behavior
correctly. The "author domain", dkim->dkim_domain, is set in
dkim_eoh_verify, using the list of headers in
dkim->lib->dkiml_senderhdrs[], which is initialized by default to
default_senderhdrs[]. dkim_domain is then later used in dkim_policy for
the ADSP policy lookup. With the given default_senderhdrs[], this may
look for the wrong domain.  Hence, default_senderhdrs[] should be
changed as above.

This change doesn't affect any other part of the library;
dkiml_senderhdrs[] is only used in this one place, in dkim_eoh_verify.
One might quibble that a client can retrieve the list via dkim_options,
and that is true, but it isn't done in dkim-filter. If this is a
concern, one would need two internal lists of headers, or hardcode
"From:" in verify mode - as is already done in dkim_eom_verify as a
fallback (I'm not sure that the fallback code is needed, but it doesn't
hurt either.)

Ole


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss

Reply via email to