dkim-milter

On Thu, 26 Mar 2009, Johannes Siebert wrote:
> dkim-keys.c:(.text+0x3b9): undefined reference to `__dn_expand'
> dkim-keys.c:(.text+0x3c4): undefined reference to `__dn_skipname'
> dkim-keys.c:(.text+0x604): undefined reference to `__dn_expand'
> dkim-keys.c:(.text+0x634): undefined reference to `__dn_expand'
> [...]

Those are resolver utility functions.  You may need to add -lresolv or 
some such.

Murray S. Kucherawy wrote:
> On Thu, 26 Mar 2009, Johannes Siebert wrote:
>   
>> dkim-keys.c:(.text+0x3b9): undefined reference to `__dn_expand'
>> dkim-keys.c:(.text+0x3c4): undefined reference to `__dn_skipname'
>> dkim-keys.c:(.text+0x604): undefined reference to `__dn_expand'
>> dkim-keys.c:(.text+0x634): undefined reference to `__dn_expand'
>> [...]
>>     
>
> Those are resolver utility functions.  You may need to add -lresolv or 
> some such.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>   

Thank you for your answer. Where do I need to add this -lresolv?

On Thu, 26 Mar 2009, Johannes Siebert wrote:
> Thank you for your answer. Where do I need to add this -lresolv?

In dkim-filter/Makefile.m4, you need to add something like:

 	APPENDDEF(`confLIBS', `-lresolv ')

...right before the first bldPRODUCT_END line.  If other applications also 
complain, move that to above the first bldPRODUCT_START line.

Murray S. Kucherawy wrote:
> On Thu, 26 Mar 2009, Johannes Siebert wrote:
>   
>> Thank you for your answer. Where do I need to add this -lresolv?
>>     
>
> In dkim-filter/Makefile.m4, you need to add something like:
>
>  	APPENDDEF(`confLIBS', `-lresolv ')
>
> ...right before the first bldPRODUCT_END line.  If other applications also 
> complain, move that to above the first bldPRODUCT_START line.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>   
No change at all. Exactly the same output:


/home/andy/dkim-milter-2.8.2/dkim-filter
Configuration: pfx=, os=Linux, rel=2.6.22.19-0.1-default, rbase=2, 
rroot=2.6.22.19-0, arch=x86_64, sfx=, variant=optimized
Making in 
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter
make[1]: Entering directory 
`/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter'
cc -o dkim-filter -lpthread -L/usr/lib  -L/usr/lib config.o dkim-ar.o 
dkim-arf.o dkim-crypto.o dkim-db.o dkim-filter.o stats.o test.o 
util.o      -lmilter  
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a 
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libsm/libsm.a 
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libar/libar.a  
-ldl -lssl -lcrypto
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a(dkim-keys.o): 
In function `dkim_get_key_dns':
dkim-keys.c:(.text+0x3b9): undefined reference to `__dn_expand'
dkim-keys.c:(.text+0x3c4): undefined reference to `__dn_skipname'
dkim-keys.c:(.text+0x604): undefined reference to `__dn_expand'
dkim-keys.c:(.text+0x634): undefined reference to `__dn_expand'
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a(dkim-policy.o): 
In function `dkim_get_policy_dns':
dkim-policy.c:(.text+0x4d7): undefined reference to `__dn_expand'
dkim-policy.c:(.text+0x4e2): undefined reference to `__dn_skipname'
dkim-policy.c:(.text+0x703): undefined reference to `__dn_expand'
dkim-policy.c:(.text+0x751): undefined reference to `__dn_expand'
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a(dkim-test.o): 
In function `dkim_test_dns_get':
dkim-test.c:(.text+0x7a2): undefined reference to `__dn_comp'
dkim-test.c:(.text+0x85b): undefined reference to `__dn_comp'
dkim-test.c:(.text+0x9d1): undefined reference to `__dn_comp'
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a(util.o): 
In function `dkim_check_dns_reply':
util.c:(.text+0xf3): undefined reference to `__dn_expand'
util.c:(.text+0xfe): undefined reference to `__dn_skipname'
util.c:(.text+0x1bb): undefined reference to `__dn_expand'
util.c:(.text+0x1f0): undefined reference to `__dn_expand'
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libar/libar.a(ar.o): 
In function `ar_sendquery':
ar.c:(.text+0x157a): undefined reference to `__res_nmkquery'
/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libar/libar.a(ar.o): 
In function `ar_dispatcher':
ar.c:(.text+0x1b6e): undefined reference to `__dn_skipname'
ar.c:(.text+0x1b90): undefined reference to `__dn_skipname'
ar.c:(.text+0x213b): undefined reference to `__dn_expand'
collect2: ld returned 1 exit status
make[1]: *** [dkim-filter] Error 1
make[1]: Leaving directory 
`/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter'
make: *** [all] Error 2

At 00:05 27-03-2009, Johannes Siebert wrote:
>No change at all. Exactly the same output:
>
>
>/home/andy/dkim-milter-2.8.2/dkim-filter
>Configuration: pfx=, os=Linux, rel=2.6.22.19-0.1-default, rbase=2, 
>rroot=2.6.22.19-0, arch=x86_64, sfx=, variant=optimized
>Making in 
>/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter
>make[1]: Entering directory 
>`/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter'
>cc -o dkim-filter -lpthread -L/usr/lib  -L/usr/lib config.o 
>dkim-ar.o dkim-arf.o dkim-crypto.o dkim-db.o dkim-filter.o stats.o 
>test.o 
>util.o      -lmilter 
>/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a 
>/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libsm/libsm.a 
>/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libar/libar.a 
>-ldl -lssl -lcrypto
>/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-

rm -rf /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64

then run sh Build

Regards,
-sm

SM wrote:
> At 00:05 27-03-2009, Johannes Siebert wrote:
>   
>> No change at all. Exactly the same output:
>>
>>
>> /home/andy/dkim-milter-2.8.2/dkim-filter
>> Configuration: pfx=, os=Linux, rel=2.6.22.19-0.1-default, rbase=2, 
>> rroot=2.6.22.19-0, arch=x86_64, sfx=, variant=optimized
>> Making in 
>> /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter
>> make[1]: Entering directory 
>> `/home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/dkim-filter'
>> cc -o dkim-filter -lpthread -L/usr/lib  -L/usr/lib config.o 
>> dkim-ar.o dkim-arf.o dkim-crypto.o dkim-db.o dkim-filter.o stats.o 
>> test.o 
>> util.o      -lmilter 
>> /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libdkim/libdkim.a 
>> /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libsm/libsm.a 
>> /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64/libar/libar.a 
>> -ldl -lssl -lcrypto
>> /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-
>>     
>
> rm -rf /home/andy/dkim-milter-2.8.2/obj.Linux.2.6.22.19-0.1-default.x86_64
>
> then run sh Build
>
> Regards,
> -sm 
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>   

This worked!!!! Thank you. Can you give a short info on what the problem 
was?

On Fri, 27 Mar 2009, Johannes Siebert wrote:
> No change at all. Exactly the same output:

Did you do "sh Build -c"?  Makefile.m4 is only read when you wipe out the 
build and start over.

At 02:37 27-03-2009, Johannes Siebert wrote:
>This worked!!!! Thank you. Can you give a short info on what the problem was?

The fix that Murray provided did not work as you forgot to do a clean 
build after modifying the Makefile.m4 file.  The command I suggested 
removes the existing object tree.  The new settings will take effect 
the next time you compile the source code.

Regards,
-sm

On Fri, 20 Mar 2009, Robert Barty wrote:
> If the POP client then reboots and is given a new IP address filter does 
> not sign the mail.
>
> The log shows:
>
>    Mar 20 06:42:41 mydomain dkim-filter[31928]: n2KAgdkN003974 not POP
> authenticated

This is expected behaviour.  When you login via POP, your POP server 
updates the authentication database with the IP address from which you 
logged in.  That's the database dkim-filter will query when it's deciding 
whether or not to sign something.  If your POP client gets assigned a new 
IP address for whatever reason, the new IP address is (presumably) not in 
the database, and so the above condition occurs and the mail won't be 
signed.

The database would be updated again when you log in to the POP server to 
retrieve mail.  Presumably that's not happening.

> If I restart the dkim filter it works again (signs mail from the POP 
> client with the new IP address).

The filter doesn't maintain any state about the POP database, so 
restarting it doesn't change anything.  The database is queried for every 
message passing through the filter.

> It seems the filter reads the my popauth.db file only once and never 
> reads it again to refresh the list of POP client IP addresses.

No, that's not the case.

Hi Murray,

Thank you very much for your time to reply. I have done a bit more 
investigation and signing POP before SMTP definitely doesn't appear to 
function as expected.

I performed the following test showing the unhashed popauth.db and 
syslog output. My POP client is a Win XP laptop (in Thailand) using 
Thunderbird on a DSL line connecting to my mailserver in the US.

1. Start dkim-filter

POP Client IP:
    124.157.238.182
POP before SMTP email to sa-test:
    Result: DKIM signature confirmed GOOD
popauth.db:
    124.157.238.182 1237901201
syslog:
    ...dkim-filter[22156]: Sendmail DKIM Filter v2.8.2 starting (args: 
-x /etc/mail/dkim-filter.conf)
    ...dkim-filter[22156]: n2L4qCus007868 no MTA name match
    ...dkim-filter[22156]: n2L4qCus007868 mode select: signing
    ...dkim-filter[22156]: n2L4qCus007868 "DKIM-Signature" header added

In previous test I found as long as I keep this IP my POP mail is signed.


2. Restart DSL connection to get new IP (this simulates the almost daily 
problem of service dropouts with Thai ISPs), 10 minutes later send 
another test mail.

POP Client IP:
    58.147.46.31
POP before SMTP email to sa-test: 
    Result: (no result present)
popauth.db:
    58.147.46.31    1237901985
syslog:
    ...dkim-filter[22156]: n2ODfe8S032583 no MTA name match
    ...dkim-filter[22156]: n2ODfe8S032583 external host 
mx-ll-58.147.46-31.dynamic.tttmaxnet.com attempted to send as 
templeofthai.com
    ...dkim-filter[22156]: n2ODfe8S032583 not internal
    ...dkim-filter[22156]: n2ODfe8S032583 not authenticated
    ...dkim-filter[22156]: n2ODfe8S032583 not POP authenticated
    ...dkim-filter[22156]: n2ODfe8S032583 mode select: verifying
    ...dkim-filter[22156]: n2ODfe8S032583: no signature data

In previous tests I found it did not matter how long I waited before 
trying again, POP mail  was verified and not signed. I sent many, many 
test emails and the longest time I waited 48hrs and it still refused to 
sign. Assigning new IP addresses and waiting also failed to sign mail 
even though  the IP  appeared  in  the popauth.db.

3. Keeping same IP address, restart DKIM,

POP Client IP:
    58.147.46.31
popauth.db:
    58.147.46.31    1237901985
POP before SMTP email to sa-test: 
    Result: DKIM signature confirmed GOOD
popauth.db:
    58.147.46.31    1237901985
syslog:
    ...dkim-filter[22426]: n2ODloGV030056 no MTA name match
    ...dkim-filter[22426]: n2ODloGV030056 mode select: signing
    ...dkim-filter[22426]: n2ODloGV030056 "DKIM-Signature" header added

Restart  DKIM and it works for the new IP in the popauth.db

I can provide my dkim conf file if necessary. I don't want to resort to 
restarting DKIM on a cron.

What could possibly be wrong? If not a dkim problem could it be sendmail 
(8.13.1) or perhaps the Berkley DB?

Thank you,

Rob Barty

Murray S. Kucherawy wrote:
> On Fri, 20 Mar 2009, Robert Barty wrote:
>   
>> If the POP client then reboots and is given a new IP address filter does 
>> not sign the mail.
>>
>> The log shows:
>>
>>    Mar 20 06:42:41 mydomain dkim-filter[31928]: n2KAgdkN003974 not POP
>> authenticated
>>     
>
> This is expected behaviour.  When you login via POP, your POP server 
> updates the authentication database with the IP address from which you 
> logged in.  That's the database dkim-filter will query when it's deciding 
> whether or not to sign something.  If your POP client gets assigned a new 
> IP address for whatever reason, the new IP address is (presumably) not in 
> the database, and so the above condition occurs and the mail won't be 
> signed.
>
> The database would be updated again when you log in to the POP server to 
> retrieve mail.  Presumably that's not happening.
>
>   
>> If I restart the dkim filter it works again (signs mail from the POP 
>> client with the new IP address).
>>     
>
> The filter doesn't maintain any state about the POP database, so 
> restarting it doesn't change anything.  The database is queried for every 
> message passing through the filter.
>
>   
>> It seems the filter reads the my popauth.db file only once and never 
>> reads it again to refresh the list of POP client IP addresses.
>>     
>
> No, that's not the case.
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>

Hi Robert,
At 07:39 24-03-2009, Robert Barty wrote:
>Thank you very much for your time to reply. I have done a bit more 
>investigation and signing POP before SMTP definitely doesn't appear 
>to function as expected.
>
>I performed the following test showing the unhashed popauth.db and 
>syslog output. My POP client is a Win XP laptop (in Thailand) using 
>Thunderbird on a DSL line connecting to my mailserver in the US.

Please see whether there are any dkim-milter related warnings or 
errors in the syslog output when POP before SMTP does not appear to work.

Regards,
-sm

On Tue, Mar 24, 2009 at 7:39 AM, Robert Barty <rbarty@...> wrote:
>
> In previous tests I found it did not matter how long I waited before trying
> again, POP mail  was verified and not signed. I sent many, many test emails
> and the longest time I waited 48hrs and it still refused to sign. Assigning
> new IP addresses and waiting also failed to sign mail even though  the IP
> appeared  in  the popauth.db.

These are wild guesses, don't be surprised if I'm totally in the wrong
direction.

Does the client which is writing the popauth.db write directly to the
file?  Does it make a copy, modify the copy, delete the original and
then rename the copy to the original? (check if the inode changes).
Does the client change the ownership or permissions of the file?  Is
the client chrooted? (meaning, is the client writing to the same file
as dkim-milter is reading)

-- 
Regards...      Todd
All truth passes through three stages. First, it is ridiculed. Second,
it is violently opposed. Third, it is accepted as being self-evident.

On Tue, 24 Mar 2009, Todd Lyons wrote:
> These are wild guesses, don't be surprised if I'm totally in the wrong 
> direction.

They're very good guesses, actually.  If the agent updating the POP DB 
replaces the file rather than simply updating it, then dkim-filter will 
have the old one still open while the new one is visible in the 
filesystem.  This would explain the symptoms being reported.

On Tue, 24 Mar 2009, Robert Barty wrote:
> What could possibly be wrong? If not a dkim problem could it be sendmail 
> (8.13.1) or perhaps the Berkley DB?

It's certainly not sendmail since it has no idea about POP.  The only 
possibilities are the one that has been suggested (your POP server is 
replacing the database rather than simply updating it) or Sleepycat DB is 
doing negative caching, although I find that quite unlikely.

Which POP server are you using?

On Tue, 10 Mar 2009, deiva shanmugam wrote:
>     When an header containing control characters like form feed, page 
> eject(^L) , vertical tab(^K) etc. is canonicalized using relaxed 
> canonicalization algorithm, vertical tab is converted to a space.

^L and ^K are illegal in headers according to RFC5322.  See section 2.2.

> But, according to the RFC, stripping/reducing the WSP, unfolding of headers
> etc. alone are being specified. Nothing regarding the special characters is
> being told. So, in that case, canonicalization shouldn't disturb the control
> characters?
>
> Header passed to the canonicalization:
>
> Content-Type:*^L*multipart/alternative;*^K*
> boundary=^M"----=_NextPart_000_0000_JLZRZLJO.OULDWYUC"

The ^L and ^K are not allowed in headers (see above).  The ^M is only 
allowed if it folds headers, which means it would have to be followed by 
whitespace (section 2.2.3).  In your example, it's not.

> Result of relaxed canonicalization using sendmail's dkim code:
>
> content-type:multipart/alternative;
> boundary=^M"----=_NextPart_000_0000_JLZRZLJO.OULDWYUC"
>
> So, what is the procedure that need to be followed, when control 
> characters are encountered?

It's unspecified, since the standard doesn't allow them.

I imagine the MTA is using the ^L as whitespace separating the header 
field name from its value so it just gets dropped; it's discarding the ^K 
since it's not allowed; and it's keeping the ^M as the next line isn't 
really a new header so it must be a continuation of the one previous.

I got it all working.  Thanks so much to Mike Markley for his time and 
patience.

It seems to now be working as I'd like (and it should).  It took:
1) creating a file to list the domains I wanted the system to sign for.
2) Adding the _domainkey and <selector>._domainkey entries to each of 
those domain's DNS records.

thanks again,
tony


SM wrote:
> At 17:08 01-03-2009, Tony Birnseth, 1st Source IT, LLC wrote:
>   
>> I have installed the 'sendmail' version of DKIM since I can't find a
>>     lib64 binary specifically for postfix.  I made links to get the key
>>     locations to resolve and that seems to be working ok.
>>     I created a regex file to perpend an DKIM Signature: header for every
>>     email sent "from" this system whether that be from the system itself or
>>     on behalf of an authenticated smtp connection (I.e one of the domains I
>>     support)...
>>     I have this option in the main.cf file:
>>     smtpd_sender_restrictions = hash:/etc/postfix/sender_access,
>>     check_client_access pcre:/etc/postfix/ez-merchant-hosting-dkim-header.re
>>     which contains:
>>     /^/ PREPEND DKIM-Signature: v=DKIM1; a=rsa-sha1; t=y; s=ezms1;
>>     d=ez-merchant-hosting.com; c=simple; q=dns;
>>
>> b=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2amdz0mVsDr9mXDOa0eDKKnuhBMHCEXW+7wBniEZejtQ9WLhA21KUchkv8vnJCOotz3/CObPSl7rc2pRHD2GYfBIKH2rq7vsDHzrbszWXIOGMoCDFc4F9tVvOi1DCUs2b0EXO8ewfazggJjXx7G8D+BW6b5UbW57gUYUrPdBTMwIDAQAB
>>     I sent mail to autorespond+dkim@... hoping to validate the
>>     DKIM installation.
>>     However, the server responds with:
>>
>> - Ignored:
>>     DKIM Signature validation: DKIM-Signature could not be verified
>>     DKIM Author Domain Signing Practices: no DNS record for 
>> _adsp._domainkey.1sit.com
>>
>>     DKIM Selector: ezms1
>>     "v=DKIM1; g=*; k=rsa; 
>> p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2amdz0mVsDr9mXDOa0eDKKnuhBMHCEXW+7wBniEZejtQ9WLhA21KUchkv8vnJCOotz3/CObPSl7rc2pRHD2GYfBIKH2rq7vsDHzrbszWXIOGMoCDFc4F9tVvOi1DCUs2b0EXO8ewfazggJjXx7G8D+BW6b5UbW57gUYUrPdBTMwIDAQAB; 
>> ----- DKIM"
>>     
>
> The public key in DNS is incorrect.  That part should be:
>
> MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2amdz0mVsDr9mXDOa0eDKKnuhBMHCEXW+7wBniEZejtQ9WLhA21KUchkv8vnJCOotz3/CObPSl7rc2pRHD2GYfBIKH2rq7vsDHzrbszWXIOGMoCDFc4F9tVvOi1DCUs2b0EXO8ewfazggJjXx7G8D+BW6b5UbW57gUYUrPdBTMwIDAQAB
>
>
>   
>>     *I append this header to all emails from verified smtp auth connections
>>     vi the smtpd_sender_restrictions directive:
>>     *DKIM-Signature: v=DKIM1; a=rsa-sha1; s=ezms1;
>>     d=ez-merchant-hosting.com; c=simple; q=dns;
>>
>> b=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2amdz0mVsDr9mXDOa0eDKKnuhBMHCEXW+7wBniEZejtQ9WLhA21KUchkv8vnJCOotz3/CObPSl7rc2pRHD2GYfBIKH2rq7vsDHzrbszWXIOGMoCDFc4F9tVvOi1DCUs2b0EXO8ewfazggJjXx7G8D+BW6b5UbW57gUYUrPdBTMwIDAQAB*
>>     
>
> You are appending the public key instead of having dkim-milter sign 
> the message.
>
>   
>>      I guess I would expect the "checker" to:
>>     1) Use the info in the header to check the dkim info  (I.e.
>>     ezms1._domainkey.ez-merchant-hosting.com)
>>     2) Validate against those credentials.
>>     
>
> That's what it does.
>
>   
>>     I'm trying to avoid setting up unique dkim info for each client that
>>     uses this system.  Maintenance nightmare.  Is that even possible?
>>     
>
> Yes, that is possible.
>
>   
>>     What am I doing wrong? My bet is that since the From field does not have
>>     the same domain name as the DKIM-Signature that it is trying to find the
>>     domain key info based on the From domain.
>>
>>     Headers sent to the autoresponder are:
>>     
>
> [snip]
>
>   
>>     DKIM-Signature: a=rsa-sha1; s=ezms1; d=ez-merchant-hosting.com; 
>> c=simple; q=dns; 
>> b=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2amdz0mVsDr9mXDOa0eDKKnuhBMHCEXW+7wBniEZejtQ9WLhA21KUchkv8vnJCOotz3/CObPSl7rc2pRHD2GYfBIKH2rq7vsDHzrbszWXIOGMoCDFc4F9tVvOi1DCUs2b0EXO8ewfazggJjXx7G8D+BW6b5UbW57gUYUrPdBTMwIDAQAB
>>     
>
> See above comments about how to sign the message.  Ignoring the 
> "DKIM-Signature:" part, that header looks like a DomainKeys signature.
>
> Regards,
> -sm 
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> dkim-milter-discuss mailing list
> dkim-milter-discuss@...
> https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
>
>

On 2 Mar 2009 at 11:01, Dave CROCKER wrote:

> Folks,
> 
> I believe there was only one response to Murray's query.  His request
> was not from idle curiosity.
> 

> Murray S. Kucherawy wrote:
> > This is probably of particular interest to those of you who are
> > familiar with the internals of DKIM, i.e. the standard document and
> > thus the protocol itself, but everyone is invited to participate.
> > 
> > Are there any portions of DKIM you feel are not useful to you?  That
> > is, are there things in DKIM which, if they weren't there to begin
> > with, wouldn't make a difference to you?  Or, on the flipside, are
> > there some things outside of the obviously mandatory features which
> > without which you would consider DKIM not useful?  Or possibly, are
> > there some features you're not using now but you plan to use in the
> > future?

Following is a combined list of the features that I use on a Postfix installation 
supporting several mail domains.  I had some issues when trying to implement DKIM on a 
single process processing all mail, but after splitting it into three processes handling 
outgoing preprocessing, outgoing signing, and incomming, things have been running quite 
smothly.  

ADSPDiscard           Yes
ADSPDiscard           No
ADSPNoSuchDomain      Yes
ADSPNoSuchDomain      No
AlwaysAddARHeader     No
AlwaysAddARHeader     Yes
Background            Yes
Canonicalization      simple/simple
DontSignMailTo        
ExternalIgnoreList    
InternalHosts         
KeyList               
Mode                  s
Mode                  v
OmitHeaders           X-Spam
On-BadSignature       
On-DNSError           
On-Default            
On-InternalError      
On-NoSignature        
On-Security           
On-SignatureMissing   
RemoveOldSignatures   No
RemoveOldSignatures   Yes
SendReports           Yes
SignatureAlgorithm    rsa-sha256
SubDomains            Yes
Syslog                Yes
SyslogFacility        local1
SyslogSuccess         Yes
UMask                 017
X-Header              Yes

On the single system there were issues with determining which outgoing mail to sign, and 
which incomming mail to check.  I did get it working with a lot of help from Murray, but 
it was a bit fragile.  Other than the debuging bits, I currently don't plan to use any of 
the other features.

The area that needed the most help, was installation on a non-sendmail system.  Quite a 
bit of frustration trying to get all of the necessary bits to get a clean complile.



...don

dhughes (at) microtechniques.com
White Plains, NY

On Mon, Mar 02, 2009 at 11:01:58AM -0800, Dave CROCKER <dhc2@...> wrote:
> Folks,
> 
> I believe there was only one response to Murray's query.  His request was not 
> from idle curiosity.
> 
> There is a serious discussion underway, looking for DKIM features that are 
> clearly essential and those that might not be.  This requires feedback from the 
> folks using DKIM.  Like yourselves.
> 
> Dkim-milter is a significant, free resource.  It really is not asking all that 
> much of those benefiting from this free software that they (yoou) provide some 
> feedback about the system is enables.
> 
> Please reply to Murray's survey, indicating the features you rely on now.  Feel 
> free also to indicate the ones you do not expect to ever use.

Frankly, I don't see myself NEVER using any of these features. With that
said, if we're framing it as essential vs. non, I'd say i= is essential,
and g= is possibly so (although I don't know if it's gained much
deployment).

q= becomes essential the moment a key query mechanism that isn't DNS
becomes available. Whether one will is harder to say. If DNSSEC finally
gets moving, the impetus to do so may not be there, but the potential
use cases are myriad.

In my estimation, x= and t= are non-essential but useful. z= is
essential for debugging. I don't see a use for n=, but others might.

l= is potentially useful, albeit controversial, and far from perfect--
it's really only reliable for its intended purpose when dealing with
messages with a single plain-text body part. Except for corner cases,
I'll never deploy it at my day job where people use HTML email almost
exclusively.

> > In signatures:
> >  	x= (signature expiration)
> >  	t= (signature timestamps)
> >  	l= (body lengths)
> >  	i= (signing identity)
> >  	q= (query method)
> >  	z= (original signed header set)
> > 
> > In keys:
> >  	g= (key granularity; restricting keys to specific users)
> >  	n= (free-form comment)

-- 
Mike Markley <mike@...>

I know not with what weapons World War III will be fought, but World
War IV will be fought with sticks and stones.
- Albert Einstein.

Thanks for the response.  As for you squib at the end of your note, hope this 
helps, if belatedly:


Rob MacGregor wrote:
> On Mon, Mar 2, 2009 at 19:01, Dave CROCKER <dhc2@...> wrote:
>> Please reply to Murray's survey, indicating the features you rely on now.  Feel
>> free also to indicate the ones you do not expect to ever use.
...
> Part of the problem of lack of reponse may be that the DKIM site
> doesn't lend itself to easily finding information.  I don't really
> want to wade through hundreds of lines of RFC to understand what the
> header options are ;)



 From the RFC 4871 table of contents:


3.5 The DKIM-Signature Header Field

     <http://dkim.org/specs/rfc4871-dkimbase.html#dkim-sig-hdr>

     These are the tags inside the DKIM-Signature: header field


3.6 Key Management and Representation

     <http://dkim.org/specs/rfc4871-dkimbase.html#keys>

     These are the parameters in the DNS TXT record for a DKIM key


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net