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
