Douglas Otis wrote:
A single TPA-SSP name association can eliminate transactions
required to support SPF record sets.
Sure, when I wrote "*some* receivers" it was about receivers
using SPF anyway, as an optional SSP-acceleration for *some*
mails (where the relevant domains happen to be identical).
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.
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.
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).
When controlling back-scatter is desired
Yes, but that's a solved problem, don't worry about it... :-)
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html