Did you just pass the whitelisting chore to the name servers?
thanks,
Bill
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Douglas Otis
Sent: Mon 3/27/2006 8:03 PM
To: Tony Hansen
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] SSP and o= values
On Mar 27, 2006, at 3:16 PM, Tony Hansen wrote:
I make no assumption on the question of TXT versus other DNS RR's
at all. I view this topic to be totally orthogonal to the DNS
question and unrelated. I see having o=~ as difficult to remember,
describe and use, irrespective of what the DNS record looks like
otherwise.
An ability to recognize an email-address will become increasingly
difficult once the EAI WG concludes. Internationalization requires
less reliance upon email-address recognition and more upon the
signing-domain and key-groups. Trust in the message content should
be based upon both a restrictive key and the signing-domain.
Associations between domains would be useful for message handling,
which is not possible using these simple character flag or mnemonic
assertions.
Establishing an association between various domains contained within
the message and the DKIM signature would be better served using a
domain name list (PTR RRsets). By using syntax within a name list,
the same types of character flag assertions are possible, but where
more information is made available. Rather than indicating some
third-party signature should be acceptable, a specific list can be
created to convey the same assertion, but where specific domains are
listed. This list could be a closed-ended list, where no other
domains are directly associated with the From address. This could
also be expressed as an open-ended list. The use of PTR RRs provides
for name compression. A new RR type would not have this ability.
Where it is common for ESPs to provide outbound mail service without
restricting the From address, the lack of a restrictive key-group,
such as "admin", could warn of a lack of assurance. Annotations
regarding what should be trustworthy should consider both the signing-
domain and the key-group, where further assurances are established by
making explicit domain associations. This approach would allow the
signing-domain to be different from the From email-address domain.
The association would be an assurance offered by the email-address
domain owner, much as the intent of the limited SSP assertions.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html