Re: Now opendkim-2.3.2 on a busy e-mail server
On Sun, 24 Apr 2011, Gary Mills wrote:
> I did notice a couple of peculiarities in error messages. The oddest
> one was this one:
>
> Apr 22 12:16:48 electra opendkim[7846]: [ID 861613 mail.info]
> p3MHGmT6025602: can't parse From: header value ' fido <www.fido.ca>'
Those were the entire contents of the header field. The part inside angle
brackets, which is supposed to be 'local-part_at_domain', is clearly
malformed.
> I also saw quite a few errors indicating that DNS queries timed out.
> Here are a couple of examples:
>
> Apr 22 19:57:42 electra opendkim[7846]: [ID 467235 mail.error]
> p3N0vFvh004842: key retrieval failed (s=201006181024,
> d=facebookmail.com): '201006181024._domainkey.facebookmail.com' query
> timed out
>
> Apr 23 20:56:18 electra opendkim[7846]: [ID 467235 mail.error]
> p3O1uDZl024176: key retrieval failed (s=beta, d=google.com):
> 'beta._domainkey.google.com' query timed out
>
> The curious thing was that when I did the query almost immediately
> against the same DNS server, it always found the TXT record:
Can you paste the entire log excerpt for one or both of those queue IDs?
That way we can verify that it did indeed wait for a reply rather than
reporting this immediately.
Also of interest might be the ResolverTracing output around the time of
those if you have that enabled and are using libar.
> Was it looking for a different type? Was the timeout so short that it
> didn't get the reply?
It was looking for the same query you did. The timeout in the library
defaults to ten seconds, though if you have DNSTimeout set it will use
that value instead.
At a guess, your nameserver was just busy at the moment it tried and
dropped or lost the query. libar will attempt to resend queries at
intervals matching the default for the system resolver, which is five
seconds, meaning one retry before the timeout expires.
-MSK
Received on Mon Apr 25 2011 - 04:28:27 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:33:09 PST