On Apr 29, 2014, at 4:54 PM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com> wrote:
On Tue, Apr 29, 2014 at 3:00 PM, Douglas Otis
<doug(_dot_)mtview(_at_)gmail(_dot_)com> wrote:
There will be an effort made to better generalize the TPA expired draft.
http://tools.ietf.org/html/rfc6541 (ATPS) was hostile to existing
mailing-list services and, as such, could not be deployed. Nor was it more
suitable for high volume email services. An effort to change From header
fields will have users guessing which field indicates who authored the
message and in the end will provide no benefit.
ATPS was deployed as part of an open source package since before it was
published. It has seen negligible use, and I suspect that's because there
has not to date been any demand for third-party signing mechanisms of any
kind. In particular, nobody has said anything even a little bit like "I
would use ATPS if only it were changed in the following way(s): ...",
including (and especilaly) the large messaging providers that use that open
source package.
To me, this may lend credence to John Levine's claim that the list signing
the message is as good or better than the author signing the message.
In any case, ATPS, TPA, and its variants all run up against a whitelisting
scaling problem. I think that's the more interesting thing to discuss.
Dear Murray,
Two significant changes from TPA occurred during the development of ATPS that
made its use impossible.
1) Unique DKIM signatures became necessary to enable third-party services.
(IESG requirement as I understand.)
This special signature requirement expects all services to change before ATPS
becomes usable. (Impossible impediment deliberately imposed.)
2) Optional labeling scheme requiring domain unique references. (Requiring a
reference to determine label encoding???)
Variable labeling makes scaling or exchanging data time consuming and difficult.
TPA offered a functional scheme without any third-party services first
changing. These third-party services could sign using DKIM, authorize outbound
MTA using SPF, depend on EHLO validation, or whatever validation condoned by
the Author Domain. TPA even add a required List-ID alignment to further
constrain authorizations for mailing-lists or specific Senders to selectively
enable other types of third-party services. TPA did not even require DKIM (nor
does DMARC for that matter).
I agree with you and John about list management, but those seeking to defend
their Author domain must be able to decide which exceptions are permitted as a
means to foreclose on abuse.
TPA scales better than restful JSON or other technologies or protocols
currently available. The author domain would publish concise static
information that only changes in response to reports of abuse. This approach
was used to report on thousands of MTAs for very large ESPs where their
recipients added a unique label to the query since this was to establish a paid
service to fund largely legal expenses. Once a too big to ignore domain using
DMARC, ADSP, or yet to be determined restrictive policy implements TPA (which
uses consistent labeling), other domains being similarly managed could share
the same _tpa subdomain. The scaling issue that you describe would involve
mostly static resources based on feedback monitoring to allow exceptions after
confirming management of third-party services.
TPA does not shift the senders problems on to recipients as DMARC does when
applied against user accounts. TPA does not demand third-party services make
changes in their process as did ATPS.
Stop being concerned about scale. Much much more than 30,000 third-party
services can be trivially supported using the TPA single query scheme.
Regards,
Douglas Otis