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