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
