This argues for doing key-retrieval by a component in the
receiver's Administrative Environment that operates with
the same connectivity as the receive-time SMTP server...
Yes. This is how my implementation works today. So, in my particular case
it's easy for me to issue an SMTP "421 try later" or some such in the event
of a DNS problem (since my DKIM verifier is very closely married to my SMTP
server). But, there is no requirement that SMTP and it's associated "try
later" mechanism be married to a DKIM verifier and this must be carefully
considered as Dave said. For example, a queue-based DKIM verifier that
operates on files placed into a directory well after SMTP has finished
transacting would be unable to issue a "try later" directive. It could
leave the message files in the queue until the DNS issue is resolved I
suppose. But, in the event of a missing SSP record or a protracted DNS
outage at a site it seems safer to me to assume a policy of "I sign some
mail" rather than "I sign all mail". The latter could very well result in a
message being deleted. That would be terrible for senders that don't do any
DKIM at all. Their messages could be severely negatively impacted just
because of a DNS issue at a DKIM-enabled receiver site. This is just my
opinion.
--
Arvel
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim