On 9/18/10 2:06 AM, Michael Deutschmann wrote: > On Fri, 17 Sep 2010, Douglas Otis wrote: > > Review the TPA-Label draft. The Third-Party Authorization > > specifies > > True, TPA does have support for identifying a DKIM-ignorant list > based on MAIL FROM: (Although I don't see any support for sites that > sign all first-person-mail but are ignorant of user subscriptions.)
One should not authorize any service that redistributes messages without first verifying recipient subscriptions. Many years ago we provided a database of IP addresses identified as non-conforming mailing-lists where the lack of subscription verification would lead to a listing. This represents a type of abuse unrelated to DKIM or message handling based upon asserted signing practices. http://www.mail-abuse.com/enduserinfo_nml.html Spammers would "subscribe" their victims to a mailing-list, and then submit their messages and have it redistributed by the mailing-list. > But, the problem I'm focusing on is that TPA is so much more > complicated than plain ADSP. If a protocol was designed to just > cover the mailing list problem, it could likely be simpler. The idea behind the TPA-Label scheme is to place the burden (complexity) onto the sender. When recipients make a transaction against a message not signed by the Author Domain they are provided _actionable_ information with authentication specifications needed to protect domains and brands. Any sender able to offer this type of information would curtail a high percentage of any message spoofing, where recipients benefit from a reduction of spoofing within a minimal number of transactions. The TPA-Label scheme also permits a graceful introduction of stronger, more efficient, and safer methods. The TPA-Label scheme also allows this complexity to be handled by different entities from that of the sender, who might specialize on monitoring of third-party services, much as what was being done about 6 years ago when mailing-lists were being abused. The TPA-Label scheme requires senders to be cognizant about where their messages are being sent, or to be reliant upon a service that tracks sender authentication and possible abusive sources. > The third-party signing use cases that do not overlap the mailing > list problem do not seem to be needed badly enough to justify the > complexity, IMO. You could say 3PS in SSP tried to piggyback those > costly yet less-important cases on top of the mailing-list support, > but the extra weight caused the effort to collapse entirely. Thus > resulting in the dead-simple yet hostile-to-lists ADSP. Disagree. The TPA-Label scheme can encompass E-invites, mailing-lists, and providers used by traveling users. Restrictive ADSP/DKIM makes _any_ third-party service difficult to administer. The TPA-Label scheme eliminates a bad practice of distributing private keys given to various third-parties where authorization becomes hidden. Such transparent authorization makes it difficult to respond when a server becomes compromised, especially when this server handles messages for thousands of domains, which is not unusual. Unlike transparent authorization, the TPA-Label authorization is able to mandate any desired SMTP client authentication and message elements that might be needed to ensure acceptance from legitimate sources and the proper message sorting. When there is a problem, there will be less confusion about the actual source. With the TPA-Label scheme, problem sources and those responsible for confirming subscriptions remain apparent. The TPA-Label scheme offers a graceful transition stratagem not predicated upon changes in how mailing lists handle their messages. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
