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 [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
