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