#34 libar bug, when sending domain uses wildcard prefix
Hi,
I have noticed a problem with dk-filter/libar then a
domain has a wildcard prefix. In this case, there was a
wildcard for the domain, that was pointing on a CNAME
-> (pointing futher) to a CNAME on a another domain. In
the end, the "other-domain" didn't have any
_domainkey.other-domain.com TXT entry at all, so
dk-filter timed out and tempfailed the mail.
From the logfile:
Jul 3 16:42:06 mx1 sendmail[7070]: [ID 801593
mail.info] k63Eg6wT007070: Milter (dk-filter): init
success to negotiate
Jul 3 16:43:08 mx1 sendmail[7070]: [ID 801593
mail.error] k63Eg6wT007070: Milter (dk-filter): timeout
before data read
Jul 3 16:43:08 mx1 sendmail[7070]: [ID 801593
mail.info] k63Eg6wT007070: Milter (dk-filter): to error
state
Jul 3 16:43:08 mx1 sendmail[7070]: [ID 801593
mail.info] k63Eg6wT007070: to=<bredbandsbyte@xxx.yyy>,
delay=00:01:00, pri=63297, stat=Please try again later
The fast solution was to put a empty
_domainkey(.other-domain.com) TXT record in there domain.
/P
Logged In: YES
user_id=370342
I have setup "vfqa.com" with a wildcard setup like the
problem-domain that i noticed. I could mail your testaddress
from that domain, so you may look at the debug output of
dk-milter...
/P
Logged In: YES
user_id=1048957
Originator: NO
Looks kind of normal to me. It just took a while for libar to finish resolving the chain of CNAMEs. Once it's cached, it comes back pretty quick and the behaviour appears correct. Thus, it only failed for me the first time I tried it.
I added some logging to libar and saw:
*** SEND `random._domainkey.vfqa.com' class=1 type=16 id=34049
*** RECEIVE 34049
*** SEND `stupid-wildcard.vfqa.com' class=1 type=16 id=34305
*** RECEIVE 34305
*** SEND `www.palsundet.se' class=1 type=16 id=34561
*** RECEIVE 34561
...which appears to be correct.
If this takes longer than the default value for the DNS timeout (-T, currently 5 seconds), dkim-filter takes its default "DNS error" action. You can lengthen the timeout if you wish, but be careful about extending it past the MTA's timeouts.
Logged In: YES
user_id=370342
Originator: YES
I don't know how you did the test, but the problem occured then the sending domain uses wildcard in DNS, but the sent emails wheren't signed with domainkeys at all.
So if you're sending yourself email from @vfqa.com, don't sign them at all. (looking at your log output, the sent mail seems to be signed with a selector "random")
But this bug perhaps is operatingsystem dependent, so maybe I should test with your debuging code?
/P
Logged In: YES
user_id=1048957
Originator: NO
An unsigned message still produced slow but ultimately positive results:
*** SEND `_domainkey.vfqa.com' class=1 type=16 id=50234
*** SEND `_domainkey.vfqa.com' class=1 type=16 id=50490
*** SEND `_domainkey.vfqa.com' class=1 type=16 id=50746
*** RECEIVE 50234
*** RECEIVE 50746
*** SEND `stupid-wildcard.vfqa.com' class=1 type=16 id=51002
*** RECEIVE 50490
*** RECEIVE 51002
*** SEND `www.vattenfall.com' class=1 type=16 id=51258
*** RECEIVE 51258
So it still looks like a timeout issue to me.
Logged In: YES
user_id=1048957
Originator: NO
Try increasing your read timeout in the MTA to 30 seconds or more.
Logged In: YES
user_id=370342
Originator: YES
I use libar/ar as resolver (so -T doesn't work according to the man-page.)
I already use those milter options: T=S:1m;R:1m
Logged In: YES
user_id=1048957
Originator: NO
Here's the debugging code I added to try to reproduce your problem (patch attached). All it does is print the queries and replies that libar sends and receives along with timestamps. The output goes to stdout, so run your filter with "-f" and not with "-A" when testing.
It took a long time to get an answer this morning and eventually timed out when I tried it with fresh caches. After the caches were loaded, the answer was almost immediate.
File Added: PATCH.ar
Patch to add debugging output to ar.c
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).