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/[email protected] > 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
