----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: <arvel(_dot_)hathcock(_at_)altn(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, July 26, 2006 11:30 AM
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options
I've always wondered why dkim is taking on the task of supporting
"I don't send mail" since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with by someone else, who might also think about saying "I only
send mail that's less than 1MB", or, "I only send invoices".
A "No Mail Expected" policy is going to very powerful policy for domains
where mail is never expected. You find this now with SPF. Altavista.com
has a "Alway Reject" policy.
"All mail claiming to be from altavista.com is forged"
"v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"
"This domain sends no email"
"Null SPF is for tracking purposes only"
If we do want SSP to allow the "I send no mail" statement then I
think we need to explicitly justify that being done here.
Just in contrast, a statement like "I sign no mail" would be much
more clearly within our scope. (Note: I'm not saying I prefer that
one, I just understand the scoping better.)
The two are different.
With no signature existing, you will always need to check the SSP in order
to check for a "Always Sign" or "We don't send mail from domain. Its
Forged." expectation.
With a signature existing, you will always need to check the SSP in order to
check for a "Never Sign" or "We don't send mail from domain. Its Forged"
expectation.
So you always need to check for SSP first.
I don't think you should eliminate the 3rd party signature potential, but I
can see where you might have a BASE SSP draft designed for Original Domain
expectations versus a 3PS SSP Draft higher layer that supports the BASE SSP
with new 3PS logic as well.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html