On 4/26/10 10:36 AM, McDowell, Brett wrote:
On Apr 23, 2010, at 6:28 PM, Murray S. Kucherawy wrote:
Something like: X sends to a list at Y that then relays to Z; Z trusts Y to
implement DKIM and Authentication-Results and all that properly, so Z
believes Y when it says "X had a signature on here that verified" even if
X's signature on arrival at Z is either invalid or absent.
That's interesting. Let's make this concrete... I'll use myself as an
example.
X = me/PayPal.com
Y = this list/ietf-dkim(_at_)mipassoc(_dot_)org
Z = Google's Gmail service [1]
It is my assumption that someone subscribed to this list has a gmail.com
account (or a Yahoo.com account [2]). Therefore, my use case is simple. I
would hope that those of you reading this from your Gmail or Yahoo! accounts
actually receive this message. If Z breaks the signature, you won't see this.
So if it simply isn't practical to expect lists to maintain the signature,
then offering the option for the list to validate the signature coming from X
and send a new signature to Z that Z *can* (but doesn't have to) "trust", is
something immediately useful.
Brett,
Is there interest in a scalable mechanism able to selectively endorse
any number of mailing-lists known by the d=domain as safely relaying
headers and body content?
This scheme could use the tpa-label conventions, where domains such as
PayPal.com could publish a CNAME to a domain containing hash lists of
mailing-lists vouched for by the domain being pointed to by the CNAME?
The tpa-label itself could narrow the endorsements for specific types of
messages of messages as well.
The CNAME at the tpa-label location could point to something like:
safe-mailing-lists.vouching-service.org.
In this way, special arrangements are not needed for those wishing to
use a restrictive ADSP. This could then avoid disrupting reputable
mailing-lists.
If there is any interest, the tpa-label draft could be pursued
individual submission, so I understand.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html