ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP complications, wa The URL to my paper ...

2006-07-28 09:37:45

----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>

That "3pl" may have been misspelled in the table listing possible tags
as "dl". Please check.

You reviewed an earlier draft-01 which had it as "dl". I changed it to 3PL,
made other reviewer changes/input, renumbered the draft to 00 and submitted
as so. Hopefully it will be announced today. The latest is:

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.xml

Are you suggesting it be "dl=" again?

One initial and obvious design consideration is length limit related.
One reviewer did suggest some 'include' concept or protocol to access
large list.

SPF has worked those details out so you might consider its apprach.
But personally I think general "include" is too open and better
is to use something similar to SPF macros where reference can be
made to another locator (with locator dns name based on From email
address or domain) to verify that domain is listed there but
there would never be any more then one additional dns lookup.
An illustration of that concept is:
  3pl={d}._3pl;
which when present with "From: alice(_at_)example(_dot_)com" causes lookup
at 'example.com._3pl._policy...'

Yes, you suggested this for the draft.  But I think this is still open how
to best do this, if at all.  The barrier is DNS packet size limitations.
The worst case is a UDP Truncate response followed up by a TCP Stream query,
so 2 lookups.  It is better to recommend to always begin with a TCP request
to minimize the request?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com




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