On 7/30/10 1:05 PM, Alessandro Vesely wrote: > On 30/Jul/10 10:58, Douglas Otis wrote: > > On 7/29/10 6:46 PM, Alessandro Vesely wrote: > >> 1. There is no standard way for the domain to learn when any of > >> its users subscribe to a new list. > > > > Disagree. > > I'm happy to hear that. The possibility that a domain becomes aware > of all of its users' subscriptions has been aired various times > before. I think that is in many people's desiderata, and have even > tried to devise a way of collaboratively doing it > (fixforwarding.org.) > > Anyway, let's assume that a domain has somehow managed to maintain a > database of all the lists that its users are subscribed to. That > domain signs all outbound mail and publishes a non-default ADSP.
Assume the community established a list of all informal third party service domains, similar to our product dropped back in 2005. See http://www.mail-abuse.com/enduserinfo_nml.html. This list could be regenerated. Instead of being a nonconforming list, it would be a list of all types of third-party services that invalidate Author Domain Signatures, where only conforming types would be authorized. Of course, non-conforming lists should not be issued any messages. The latest version of TPA-Label has not yet been published, but it now includes the discardable assertion. This assertion can signal an outbound server that it should not send to the nonconforming domain. > I propose that, when a message is destined to a list, the author > domain signs a few header fields only, not the body, and tags the > message with a (signed) list-signature-required sort of advice. Changing signature behavior seems ill advised, as this will be more difficult to implement. Not signing the body will also introduce security issues. > Messages to multiple list and non-list recipients have to be split, > regularly signing the non-list copy. A mailing list is just one possible informal third-party service that could benefit from TPA-Label authorization. The "all tpa-sig" assertion indicates one should check for a domain specific authorization. With this scheme, there is no reason to split message types, or alter how they are signed. > Another way of achieving the same effect would be to standardize all > acceptable message changes, together with a MIME-compliant > canonicalization. We've already noted that in some cases (plain > text, poster-added subject tags, not signing "Content-Type", l=) it > may work as-is. For the general case, and for the time being, the > advice requiring the added list signature guards against replay > attacks: Verifiers must ensure that both signatures are valid, unless > they are the domain whose signature is missing. I don't wish to stand in the way of such a goal, but such a change may take many years to define, and at least as many to gain adoption. > >> 2. Granting a TPA implies a good degree of trust. > > > > Most mailing lists would be safe for a domain in their position to > > authorize. > > Except that phishermen.com may set up a mailing list for the sole > purpose of getting that auth. The community would need to maintain the TPA list information. The future of email will soon become more positive, than negative. I also see TPA-Labels playing a significant role for email being emitted from the IPv6 address space. The complexity of routing paths from this space will cause current client authentication schemes to be come obsolete. With TPA-Labels allowing third-party signatures, this also enables a means to deal with future namespace complexities as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html