Douglas Otis wrote:
See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt
Oops, I didn't know this style of URL, Henrik's tools are amazing.
Unlike SPF, the tpa-ssp method scales without invoking hundreds
of DNS transactions. This draft extends the current SSP draft.
As always "hundreds" is nonsense. Minor nit, maybe s/*FWS/[FWS]/g
in your draft, I think you never want more than one FWS in a row.
Please add some examples, I almost missed the point where you're
using the base32( sha-1( lcase( signing-domain ))) construct.
Let's say mail "from" (one or more of your scopes) domain.example
is sent via third party signers isp1.example and isp2.example,
what are those signers and later receivers supposed to do, and
when is whatever they do okay from the POV of domain.example ?
The use of the From is sure to create problems for mailing-lists.
As with SPF, SSP also lacks policy scope which is unfortunate.
For SPF in the sense of v=spf1 it's fine, it's limited to SMTP,
HELO + MAIL FROM need no complex scopes. The PRA and 4405 cases
are also clear if publishers stay away from %h (HELO) macros in
their PRA policies.
You only run into problems when you're talking about something
like 2822-From, neither PRA nor envelope sender. BTW, I think
you could replace your "O" by PRA with a reference to RFC 4407.
If there's one thing we don't need it's "yet another definition
of 'originator'".
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html