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, [email protected]
Gatekeeper, NetHeaven, Saratoga Springs, NY
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
