SM writes:
> At 15:43 24-12-2009, Dan Mahoney, System Admin wrote:
> >So, I believe milter-dkim registers the NXDOMAIN as a tempfail. Here are
> >the questions.
> >
> >1) Why? I can understand a servfail or a DNS timeout being cause for
> >this, or a FORMERR, but not an nxdomain. NXDOMAIN is not an error.
> >
> >In my mind, a nonexistent key should mean a dkim fail, to be treated as
> >such, just as though I had made up a key with a bogus selector, and used
> >it to send forged mail.
>
> I'll defer delivery so that you can fix the problem instead of
> treating the message as "forged mail".
In a perfect world wih no time delays, NXDOMAIN would always be a
definitive error, but real world DNS has caching, which introduces
updaate delays, and even delays between updating the start of
authority and slave nameservers. For example, just this morning I
found this:
# host -C google.com
Nameserver ns4.google.com:
google.com has SOA record ns1.google.com. dns-admin.google.com. 1401935 7200 1800 1209600 300
Nameserver ns3.google.com:
google.com has SOA record ns1.google.com. dns-admin.google.com. 1401935 7200 1800 1209600 300
Nameserver ns2.google.com:
[***-->] google.com has SOA record ns1.google.com. dns-admin.google.com. 1401934 7200 1800 1209600 300
Nameserver ns1.google.com:
google.com has SOA record ns1.google.com. dns-admin.google.com. 1401935 7200 1800 1209600 300
ns2.google.com is an *authoritative* nameserver, yet at the time I
happened to query it, it was not yet in sync with the most recent
change to google.com's zone. A minute later it was in sync.
Adding a DKIM key or switching to a new one involve DNS updates, and
there is always a time window during which it is possible to get an
NXDOMAIN after the update. That time window can be substantial when
caching by a local resolver is involved. A busy site can send a lot
of mail during even a short window.
A competent email administrator can avoid the slave server window by
not using a DKIM key until his domain's authoritative servers are in
sync, but even the best admin cannot avoid resolver caching issues.
When I make MX changes in a zone or a user moves a domains, email
continues to come to the old MXs for awhile. Sometimes occasional
messages will come to the old MXs weeks later.
No DNS response is truly definitive unless it is obtained directly
from the start of authority, and even then it may be subject to human
error in creating the entry. I would vote for 4XX responses for all
DNS-based rejections. The cost of giving forged mail a 4XX is
minimal, but the cost of giving even one legitimate email a 5XX could
be substantial.
--
Dick St.Peters, stpeters@...
Gatekeeper, NetHeaven, Saratoga Springs, NY

On Thu, 24 Dec 2009, SM wrote:
> At 15:43 24-12-2009, Dan Mahoney, System Admin wrote:
>> Note: it's christmas eve. I would figure Best Buy would care about this,
>> but with propagation delays and the like I don't think it's fixable or
>> advisable for a major DNS change this soon before Christmas.
>
> This message is copied to Best Buy in case they wish to fix the problem.
I had also copied it to the reporting address indicated by their domainkey
record. I should bounce it along to postmaster@, webmaster@, and track
down the service they're using to manage email as well.
> I'll defer delivery so that you can fix the problem instead of
> treating the message as "forged mail".
I don't think DKIM normally bounces mail for me, I let spamassassin weigh
this and most other factors. I run it at the MTA level because I need to
do this anyway for outbound mail.
>> 1.5) For the purposes of -C actions, does this count as a "dnserror", same
>> as the above conditions (servfail, etc)?
>
> Use On-InternalError to override the behavior.
So the answer there is "yes".
Doing that for now, which also means I accept mail on a servfail, which is
an actual error. I've heard a report that opendkim does not treat
NXDOMAIN as an error, so that seems to be the longer term fix.
>> 2) What's worse is I don't see a way to tune this, either per-domain or
>> per-dns-errortype, in either /etc/mail/access or in dkim.conf. How would
>> I whitelist this, and say, "yes, *.bestbuy.com is having a problem, I'm
>> working around it"? (Note that I see a way to do it by IP in the
>> archives, but not by domain).
>
> It cannot be done per domain.
Shucky-darns. AccessDB seems to be supported by many other milters, just
none that do this.
--
"It would be bad."
-Egon Spengler, "Ghostbusters"
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

At 15:43 24-12-2009, Dan Mahoney, System Admin wrote:
>Note: it's christmas eve. I would figure Best Buy would care about this,
>but with propagation delays and the like I don't think it's fixable or
>advisable for a major DNS change this soon before Christmas.
This message is copied to Best Buy in case they wish to fix the problem.
>Anyway, rather than talking finance, let's post the details:
[snip]
>Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter
>insert (1): header: Authentication-Results: prime.gushi.org;
>dkim=neutral\n\theader.i=noreply@...; dkim-adsp=none
>Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter
>insert (1): header: X-DKIM: Sendmail DKIM Filter v2.8.2 prime.gushi.org
>nBOMTkxC033377
>Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter:
>data, reject=451 4.3.2 Please try again later
[snip]
>So, I believe milter-dkim registers the NXDOMAIN as a tempfail. Here are
>the questions.
>
>1) Why? I can understand a servfail or a DNS timeout being cause for
>this, or a FORMERR, but not an nxdomain. NXDOMAIN is not an error.
>
>In my mind, a nonexistent key should mean a dkim fail, to be treated as
>such, just as though I had made up a key with a bogus selector, and used
>it to send forged mail.
I'll defer delivery so that you can fix the problem instead of
treating the message as "forged mail".
>1.5) For the purposes of -C actions, does this count as a "dnserror", same
>as the above conditions (servfail, etc)?
Use On-InternalError to override the behavior.
>2) What's worse is I don't see a way to tune this, either per-domain or
>per-dns-errortype, in either /etc/mail/access or in dkim.conf. How would
>I whitelist this, and say, "yes, *.bestbuy.com is having a problem, I'm
>working around it"? (Note that I see a way to do it by IP in the
>archives, but not by domain).
It cannot be done per domain.
Regards,
-sm

Note: it's christmas eve. I would figure Best Buy would care about this,
but with propagation delays and the like I don't think it's fixable or
advisable for a major DNS change this soon before Christmas.
Anyway, here's the relevant data:
Two domains that I dkim-verify are being rejected with a key retrieval
error.
The mail is for me, waiting for a "your item is ready for in-store
pickup". Because they don't fully auth my card until I pick it up, if I
wait and wait and don't get that email, and go somewhere else, this is a
revenue loser for them.
Anyway, rather than talking finance, let's post the details:
BIND 9.6.1
Sendmail 8.14.1
dkim-filter: Sendmail DKIM Filter v2.8.2 (upgraded to 2.8.3 after I
started this mail).
Compiled with OpenSSL 0.9.8e 23 Feb 2007
Supported signing algorithms:
rsa-sha1
rsa-sha256
Supported canonicalization algorithms:
relaxed
simple
On the mailer machine:
%grep nBOMTkxC033377 /var/log/maillog
Dec 24 17:29:47 <mail.info> prime sm-mta[33377]: nBOMTkxC033377:
from=<bounce-41_HTML-31948602-4944-97381-2767829@...>,
size=22100, class=0, nrcpts=1,
msgid=<c5fca22e-d25c-4225-ad6e-ef9d799adb77@...>,
bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=aq98.mta.exacttarget.com
[66.231.88.98]
Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter
insert (1): header: X-DomainKeys: Sendmail DomainKeys Filter v1.0.2
prime.gushi.org nBOMTkxC033377
Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter
insert (1): header: Authentication-Results: prime.gushi.org;
dkim=neutral\n\theader.i=noreply@...; dkim-adsp=none
Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter
insert (1): header: X-DKIM: Sendmail DKIM Filter v2.8.2 prime.gushi.org
nBOMTkxC033377
Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377: Milter:
data, reject=451 4.3.2 Please try again later
Dec 24 17:29:48 <mail.info> prime sm-mta[33377]: nBOMTkxC033377:
to=<bestbuy@...>, delay=00:00:01, pri=52100, stat=Please try again
later
On the dkim-filter machine:
Dec 24 18:24:40 quark dkim-filter[63303]: nBONLXQN043249: key retrieval
failed (s=200608, d=emailinfo2.bestbuy.com):
`200608._domainkey.emailinfo2.bestbuy.com' record not found
Dec 24 18:24:40 quark dkim-filter[63303]: nBONLXdo043248: key retrieval
failed (s=200608, d=emailinfo2.bestbuy.com):
`200608._domainkey.emailinfo2.bestbuy.com' record not found
So, I believe milter-dkim registers the NXDOMAIN as a tempfail. Here are
the questions.
1) Why? I can understand a servfail or a DNS timeout being cause for
this, or a FORMERR, but not an nxdomain. NXDOMAIN is not an error.
In my mind, a nonexistent key should mean a dkim fail, to be treated as
such, just as though I had made up a key with a bogus selector, and used
it to send forged mail.
1.5) For the purposes of -C actions, does this count as a "dnserror", same
as the above conditions (servfail, etc)?
2) What's worse is I don't see a way to tune this, either per-domain or
per-dns-errortype, in either /etc/mail/access or in dkim.conf. How would
I whitelist this, and say, "yes, *.bestbuy.com is having a problem, I'm
working around it"? (Note that I see a way to do it by IP in the
archives, but not by domain).
-Dan
--
"SOY BOMB!"
-The Chest of the nameless streaker of the 1998 Grammy Awards' Bob Dylan
Performance.
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

On Wednesday 16 December 2009 18:41:01 mirader@... wrote:
> Was just curious what the c= option should be set at. I have mine set to
> simple and everything is running great. But I noticed a lot of other
> places have c=relaxed. Could someone tell me the diff between the 2?
See:
http://www.rfc-editor.org/rfc/rfc4871.txt
section: 3.4. Canonicalization
and the 'c' tag in:
3.5. The DKIM-Signature Header Field
The 'c=relaxed/simple' seems to be a good compromise,
or just stick to the basic c=simple/simple (which is a default
and need not be specified).
Mark

Murray S. Kucherawy wrote:
> This is fixed in OpenDKIM v1.1.0 (v1.2.0 is current) by creating special handling for this case that defaults to "accept".
>
> It's not clear if or when a patch would be made available to dkim-milter to resolve this.
>
What is the relationship between OpenDKIM and dkim-milter. Looking at
opendkim.org I learned that OpenDKIM is based upon dkim-milter 2.8.3.
Can OpenDKIM be used instead of dkim-milter as a milter? Is dkim-milter
2.8.x dead and should I switch to OpenDKIM?
/rolf

This is fixed in OpenDKIM v1.1.0 (v1.2.0 is current) by creating special handling for this case that defaults to "accept".
It's not clear if or when a patch would be made available to dkim-milter to resolve this.
________________________________________
From: Mark Martinec [Mark.Martinec@...]
Sent: Thursday, December 17, 2009 5:43 AM
To: dkim-milter-discuss@...
Subject: Re: [dkim-milter-discuss] Milter rejected message
On Thursday 17 December 2009 14:13:20 SM wrote:
> At 01:53 17-12-2009, Rolf E. Sonneveld wrote:
> >Seems these messages carry a DKIM signature, but their DKIM DNS
> >entry is not correct. I assume the dkim-filter status is then not
> >'reject' but maybe the mail server is interpreting the result of
> >dkim-filter as a temp. failure, giving back a 4.x.y status code to
> >the SMTP partner?
>
> Yes, that's what happening. You can override that behavior with
> "On-InternalError accept".
This should be fixed. A NXDOMAIN is a definite and permanent answer
from a DNS resolver, it can in no way be treated as an 'internal error'
or a temporary failure.
Mark

Hi Mark,
At 05:43 17-12-2009, Mark Martinec wrote:
>This should be fixed. A NXDOMAIN is a definite and permanent answer
>from a DNS resolver, it can in no way be treated as an 'internal error'
>or a temporary failure.
The "default" behavior was changed in OpenDKIM. There were also
changes to the code to distinguish between "internal error" and
"temporary failure" conditions. In DNS terms, the NXDOMAIN is a
definite and permanent answer. Application-wise, it's different. It
would probably be off-topic if I compare this with what mail servers do.
Regards,
-sm

Hi Rolf,
At 03:10 17-12-2009, Rolf E. Sonneveld wrote:
>Seems dkim-filter responds with a 't' in this situation; I would expect
>that if a domain does not exist (nmvf.us does not exist, so a _domainkey
>subdomain cannot exist either), dkim-filter would not return a Tempfail
>status? I would expect an 'Accept'.
Dkim-milter does not determine whether nmvf.us exists. The DNS query
is done to retrieve the public key.
This is an unusual case as the message is being "signed" using a
domain that does not exist. I would expect an "Accept" in this case
but that means an additional DNS query. The domain part would have
to be determined using heuristics.
Regards,
-sm

On Thursday 17 December 2009 14:13:20 SM wrote:
> At 01:53 17-12-2009, Rolf E. Sonneveld wrote:
> >Seems these messages carry a DKIM signature, but their DKIM DNS
> >entry is not correct. I assume the dkim-filter status is then not
> >'reject' but maybe the mail server is interpreting the result of
> >dkim-filter as a temp. failure, giving back a 4.x.y status code to
> >the SMTP partner?
>
> Yes, that's what happening. You can override that behavior with
> "On-InternalError accept".
This should be fixed. A NXDOMAIN is a definite and permanent answer
from a DNS resolver, it can in no way be treated as an 'internal error'
or a temporary failure.
Mark

At 01:53 17-12-2009, Rolf E. Sonneveld wrote:
>Seems these messages carry a DKIM signature, but their DKIM DNS
>entry is not correct. I assume the dkim-filter status is then not
>'reject' but maybe the mail server is interpreting the result of
>dkim-filter as a temp. failure, giving back a 4.x.y status code to
>the SMTP partner?
Yes, that's what happening. You can override that behavior with
"On-InternalError accept".
Regards,
-sm

At 09:41 16-12-2009, mirader@... wrote:
>Was just curious what the c= option should be set at. I have mine
>set to simple and
>everything is running great. But I noticed a lot of other places
>have c=relaxed. Could
>someone tell me the diff between the 2?
The difference is the "c=relaxed" allows messages that have undergone
some minor modifications (e.g. whitespace removed) to pass DKIM
verification. "c=simple" does not allow any modification to the
message. If "c=simple" works for you, there is no need to change
it. There are some security issues when using "relaxed" for the message body.
Regards,
-sm

Was just curious what the c= option should be set at. I have mine set to simple and
everything is running great. But I noticed a lot of other places have c=relaxed. Could
someone tell me the diff between the 2?
Thank you very much!
Bob

At 21:59 13-12-2009, Steve Johnson wrote:
>but my problem persists. Nothing seems to have changed except that
>the new canonization scheme is noted in the emails. A simple test
>email now looks like this:
You probably have masquerading enabled. Your milter won't see the
rewrite being done when it DKIm signs the message.
Regards,
-sm