On Fri, 28 Jul 2006, Hector Santos wrote:
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
Those are the ones I reviewed, the "dl" appears in the table in section 4
Are you suggesting it be "dl=" again?
3pl= is fine; personally I don't care much as long as its consistent.
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.
Which is why this type of redirection is better.
With DNS-TCP you end up with 9 packets: 2 for UDP to find out that
response is too large and change to TCP, 3 for SYN/ACK to establish
TCP session, 2 to send actual request and receive a response and
2 more for FIN session end (I maybe slightly wrong by 1 or 2 packets
as some of the packets can possibly be combined, i.e. FIN).
For above redirection you always end up with 4 packets (2 for original
request/response and 2 more for 3pl={d} redirected request/response).
Also if you have very large dns record this is bad (dns is not
designed for it and many such records are operational problems
both due to abuse and due to use of dns cache on ISP systems).
With redirection you will always end up with small dns record -
the first one for DSIP policy itself with list very small just
containing macro (3pl={d}) where as second dns record just needs
to exist but actually can be 0 size (or we can talk about what can
be put there that matters), this is like "a" operator in SPF.
The size of the records will also not change even if you have
1000 domains so dns queries will all be small.
Additional benefit is that with redirection whoever put up the
policy can actually produce some statistics about which of the
3pl listed domains are actually seen in the emails (based on
dns logs for <domain>._3pl._policy).
The worst case is a UDP Truncate response followed up by a TCP Stream
query, so 2 lookups.
Its not quite that simple when comparing UDP to TCP - see above.
It is better to recommend to always begin with a TCP request to minimize
the request?
This is not how DNS-TCP supposed to work and in general TCP Session
establishment is expensive on its own; in the end up you still have
packets being exchanged then 2 separate dns udp requests and add
to that slight overhead for OS network kernel associated with each
TCP session too.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html