On Dec 27, 2007, at 4:29 PM, Frank Ellermann wrote:
Jim Fenton wrote:
The SSP extension to key records would never be sufficient; stand-
alone SSP records would need to be published as well. I'd like to
suggest that we concentrate on the "basic" SSP concept for now and
keep optimizations such as this for discussion later.
+1 It's kind of obvious that for *some* receivers and *some* mails
it might help to offer an "SSP-accelerator" in SPF, as proposed by
Scott (in 2006 IIRC). No issue for this WG. ;-)
Adding the scope of the headers validly signed might be something
considered for key records. This could rectify an error in the
current SSP logic. Hopefully this mistake will be fixed soon without
altering key records.
A single TPA-SSP name association can eliminate transactions required
to support SPF record sets. This association can be done efficiently
by adding a parameter to SSP records which indicates the extensions
supported. It seems illogical to have IP address path registration
records support a DKIM process, nor would generating a list of IP
addresses reduce any DKIM overhead. If anything, DKIM in combination
with SSP and a single TPA-SSP can supplant any benefit employing
transactions to construct IP address path registrations. When
controlling back-scatter is desired, TPA-SSP already provides a means
to validate MailFrom domains in a single transaction. Example code
needed to generate TPA labels will be offered shortly as well.
Dealing with abuse requires burdening the transmitter and not the
receiver.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html