ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Another take on "all email from us is dkim signed"

2009-03-11 17:36:02
On Wed, Mar 11, 2009 at 4:53 PM, Mark Delany
<markd+dkim(_at_)yahoo-inc(_dot_)com<markd%2Bdkim(_at_)yahoo-inc(_dot_)com>
wrote:

Outside of DNS query related technical issues,  the first operational
repercussion is  the lost of handling legacy mail.   We need to use an
"standard anchor" something we know will always be there, which as it is
now, is the From: domain lookup.


For those subset of folk who want to do that, nothing stops you storing the
ADSP query result with the email when you write it to your local disk. Your
disk, your rules.


Right, and also which was Fenton's points out in regard to dns caching
currently employed - you define your timeouts on your DNS records hence
there would be local dns client caching.

My only come back there (a minor one) is that the DNS client API used
defines how that caching will be done, if any.  So sure, the receiver should
probably keep in mind the possible need to do its own caching.

Overall, I don't think this part is an non-issue and as was pointed out by
some, many receivers are already doing all kinds of lookups, SPF, RBL,
SENDERID, etc.  It would be a dream to have one universal lookup that covers
all, nonetheless, that is not the case and an additional ADSP should not be
an issue.


Besideswhich, since only signed mail could legitimately contain the "I
don't sign everything anymore" you'll have to somehow track that across to
unsigned emails when you store them or maintain a state change history per
domain so you can correctly analyze unsigned legacy mail.


+1.  IIR, this was all covered.  Caching is a plus in all this.


-- 
hls
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html