[ietf-dkim] "third party signing" != "mailing list problem"
dotis at mail-abuse.org
Sun Sep 19 18:10:28 PDT 2010
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.
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.
More information about the ietf-dkim