On Dec 27, 2007, at 8:35 PM, Frank Ellermann wrote:
Douglas Otis wrote:
It seems illogical to have IP address path registration records
support a DKIM process
It might be fine for receivers supporting both anyway, they could
use DKIM PASS to overrule an SPF "false positive", and SPF PASS to
overrule an SSP "false positive". Of course this won't help if
SSP's "1st author" (1st 2822-From) doesn't match SPF's 2821-From.
Having DKIM "overrule" SPF's IP address path authorization failures
eliminates the touted overhead advantage achieved basing results upon
the MailFrom's IP address path registration.
It's a timing issue, an implementation can "see" an SPF FAIL before
DATA, and it might be interested to reject it a.s.a.p. Scott's idea
was a flag indicating "we also sign everything", and the MX could
then delay the reject hoping for a DKIM PASS.
Rejections based upon the MailFrom IP address path failures,
regardless of the asserted SSP policy, would diminish DKIM's delivery
integrity. TPA-SSP can better validate MailFrom and is independent of
the registered IP address path. By dealing with backscatter using by-
name validation, many of the problems associated with path
registration can be overcome, and by-name is compatible with DKIM's
advantages.
We're deep in "receiver policy" territory here, of course an MX
supporting both SPF and SSP can use this strategy anyway also
without flag. And with at most two DNS queries for SSP
"accelerating" it is likely pointless. But I'm not yet sure if
those _ssp. label records work everywhere - for obvious reasons
SPF's hijacking of TXT records works everywhere, the new SPF RR also
has no wildcard issues (unlike _ssp. labels).
A new resource record is not a solution, as both record types must
still be published to ensure legacy compatibility. Wildcards for any
policy assertion requires these policy records be replicated at
_every_ existing node, which also makes every node visible. When a
new RR must be introduced to publish a protocol's policy, then
Phillip's concept holds greater promise, and does not result in
records that must contain "everything", including the kitchen sink.
Wildcards create many problems and reduce DKIM policy coverage, as
described in section 4.2 of SSP. The issue involving wildcards really
demands that SMTP should soon mandate publishing MX records to ensure
message acceptance, at least for IPv6 in 2821bis. : )
When controlling back-scatter is desired
Yes, but that's a solved problem, don't worry about it... :-)
Sorry, but SPF neither a safe or compatible solution. Validation by-
name safely scales, is faster, and is compatible with DKIM. : )
-Doiug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html