Re: Will mailing lists survive DMARC?

[Douglas Otis <doug.mtview@xxxxxxxxx>]

On Apr 29, 2014, at 4:54 PM, Murray S. Kucherawy <superuser@xxxxxxxxx> wrote:

On Tue, Apr 29, 2014 at 3:00 PM, Douglas Otis <doug.mtview@xxxxxxxxx> 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