Subject: Will mailing lists survive DMARC?

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Apr 2014 13:10:59 +0200

There has been some discussion on what should the IETF do about the
collateral damage experienced by several mailing lists when major
mailbox providers switch their DMARC policies to p=reject.

Mailing lists used to be a legitimate use of email.  Albeit they are
the workhorse of many organizations which are vital for the Internet
itself, such as the IETF and several software projects, statistically
they are a minor Internet feature.  I can understand that after
decades of failed attempts to control email abuse, their disappearance
is not the main concern of "p=reject" proponents.

The discussion on ietf-822 brought some mailing list assumptions
--much needed, since ML were never formally standardized-- as well as
a few proposals.  Now the discussion seems to be fading out, even if
no actionable result was reached.  The solutions proposed, in order of
decreasing ease (IMHO), are:

* Whitelisting,
* weak signatures,
* permission to re-sign, and
* exchange of cryptographic data.

All of those solutions require that originators' relays know whether a
message is destined to a mailing list.  That is a delicate subject in
itself, as it involves privacy considerations --does a subscriber
consent to allowing her or his mailbox providers to know which lists
she or he is on?

The DMARC draft is currently in "AD Followup" state.  A review was
posted here last week, a process which doesn't seem to affect
deployment much.

How is the IETF going to proceed on this issue?

Ale

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Apr 2014 13:22:31 +0200 (CEST)

> is not the main concern of "p=reject" proponents.

Actually, I can't. Not fixing the mailing list and calling it "collateral 
damage but that's ok" is for me totally out of the question. On the other 
hand, this will primarily cause direct problems to users/customers of the 
organisations that decide to do "p=reject" as their participation in 
mailing lists will be crippled.

> How is the IETF going to proceed on this issue?

I would really like to see the standards process for this mechanism be 
stopped until the mailing list problem has been sorted out. I don't really 
understand how it got that far with this problem unsolved.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 29 Apr 2014 13:28:38 +0200

On 29 apr 2014, at 13:22, Mikael Abrahamsson <[email-masked]> wrote:

> On the other hand, this will primarily cause direct problems to users/customers of the organisations that decide to do "p=reject" as their participation in mailing lists will be crippled.

As Mikael says, this is a problem for people in those organisations that choose to have such filter policy together with the de-facto functionality of mailing lists out there.

I ask myself as well what the problem is.

If there was collateral damage on third parties, that would for me have been a different thing. As far as I see here, there is not. The damage is on the people that have chosen to have such policy (or customers of them).

If I have completely misunderstood the situation, my apologies and I'll go back and re-read the flood of email on the topic... :-)

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Apr 2014 22:44:03 +1000

In message <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= writes:
> > On the other hand, this will primarily cause direct problems to
> users/customers of the organisations that decide to do "p=reject" as
> their participation in mailing lists will be crippled.
>
> As Mikael says, this is a problem for people in those organisations that
> choose to have such filter policy together with the de-facto
> functionality of mailing lists out there.
>
> If there was collateral damage on third parties, that would for me have
> been a different thing. As far as I see here, there is not. The damage is
> on the people that have chosen to have such policy (or customers of them).
>
> If I have completely misunderstood the situation, my apologies and I'll
> go back and re-read the flood of email on the topic... :-)
>
>    Patrik

There is also collateral damage to anyone elso on the mailing list
who implement DMARC as the SMTP rejections of the mailing list
messages cause them to be unsubscribed from the mailing list.

There is also collateral damage as administrators of the mail list
have to remove the offending members.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Apr 2014 08:45:28 -0400

On Tue, Apr 29, 2014 at 01:22:31PM +0200, Mikael Abrahamsson wrote:

> I would really like to see the standards process for this mechanism
> be stopped 

Since it's an ISE stream document and its intended status is
"Informational", there is no standards process.  (If one thinks, "Yes,
but everyone treats RFCs as standards," then that's a different
discussion to the current one.)

On Tue, Apr 29, 2014 at 01:28:38PM +0200, Patrik Fältström wrote:
> If there was collateral damage on third parties, that would for me have been a different thing. 

The issue is that the operators in this case are externalizing their
problem.  The operator makes the decision and establishes a policy
that causes mailing list postings from addresses inside the operator's
domain of control to bounce.  The person who has to cope with those
bounces is the mailing list manager, and _not_ the mail domain
operator.  The cost of the side effect is not actually borne by the
mail domain operator.  So there certainly is damage to someone other
than the operator of the mail domain (or its customers).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 29 Apr 2014 14:55:52 +0200

Ok, one more mail...but the last one (I claim)... ;-)

> than the operator of the mail domain (or its customers).

The problem exists if A is publishing such a policy, B is acknowledging the policy, B is generating a bounce, and the bounce is hitting the mailing list provider.

I do not understand why a bounce should be generated (and not the incoming mail to B would be tagged as spam and/or null-routed).

That said, the result of the above is that B is unsubscribed from the mailing list due to large number of bounces, but that is because B is recognizing the policy A is publishing.

Do I get this right?

   Patrik

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Apr 2014 15:03:49 +0200 (CEST)

> discussion to the current one.)

I quickly went through 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 
which I guess is the draft we're discussing? As far as I can tell, it 
doesn't "inform" about the problem DMARC causes in conjunction with quite 
prevalent mailing list functionality.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2014 06:20:57 -0700

On 4/29/2014 6:03 AM, Mikael Abrahamsson wrote:
> doesn't "inform" about the problem DMARC causes in conjunction with
> quite prevalent mailing list functionality.

Well, it does, but not in the most pedagogical fashion one might wish 
for.  "Obscure" wouldn't be an inappropriate characterization...

    Appendix C.  DMARC XML Schema
    ...
    Descriptions of the PolicyOverrideTypes:
    ...
    mailing_list:  Local heuristics determined that the message arrived
       via a mailing list, and thus authentication of the original
       message was not expected to succeed.

The draft BCP is another opportunity to clarify such issues, and already 
has some text:

      http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03

      11. DMARC Commentary -- What were they thinking of...?
      ...
      Why doesn't DMARC solve its problem with mailing lists/gatewats?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Apr 2014 15:29:11 +0200 (CEST)

On Tue, 29 Apr 2014, Dave Crocker wrote:

> Well, it does, but not in the most pedagogical fashion one might wish for. 
> "Obscure" wouldn't be an inappropriate characterization...
>

I also found text in the A.3:

"A.3.  Sender Header Field

    It has been suggested in several message authentication efforts that
    the Sender header field be checked for an identifier of interest, as
    the standards indicate this as the proper way to indicate a re-
    mailing of content such as through a mailing list.  Most recently, it
    was a protocol-level option for DomainKeys, but on evolution to DKIM,
    this property was removed.

    The DMARC development team considered this and decided not to include
    support for doing so, for two primary reasons:
...
2.  Although it is certainly true that this is what Sender is for,
        its use in this way is also unreliable, making it a poor
        candidate for inclusion in the DMARC evaluation algorithm."

So... just because this is a hard problem to solve doesn't mean it's a 
good idea to just gloss over it and say "screw it" for mailing lists.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2014 06:40:57 -0700

> good idea to just gloss over it and say "screw it" for mailing lists.

A counter-argument is the classic "Don't let perfect be the enemy of 
good".  DMARC works well for a very popular -- albeit very constrained 
-- scenario.

For any mechanism, there is always the possibility that someone will 
apply it for scenarios beyond what was originally envisioned.  Often 
that is a large benefit.  Often is not always.

The distinctive issue now is that that extension is being done by very 
large players.  The phrase "Too big to ignore" has been rattling around 
in my brain for the last few weeks...

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Apr 2014 15:52:16 +0200

On Tue 29/Apr/2014 14:55:52 +0200 Patrik Fältström wrote:
> 
> The problem exists if A is publishing such a policy, B is 
> acknowledging the policy, B is generating a bounce, and the 
> bounce is hitting the mailing list provider.
> 
> I do not understand why a bounce should be generated (and not the
> incoming mail to B would be tagged as spam and/or null-routed).

There is also a p=quarantine policy.  Yahoo! and AOL, as well as
PayPal, LinkedIn, Facebook, etcetera use p=reject, though.

> That said, the result of the above is that B is unsubscribed from
> the mailing list due to large number of bounces, but that is
> because B is recognizing the policy A is publishing.

B's domain need to do so in order to reject scams claiming to be
from banks or social networks.

> Do I get this right?

More or less.  Many people set up forwarding to an address at a
domain different from theirs, typically large providers, so there
are multiple places where the bounce may occur.

Ale

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 29 Apr 2014 16:39:11 +0200

> that is a large benefit.  Often is not always.

Mailing lists are hardly an obscure corner case in email. 
 
> The distinctive issue now is that that extension is being done by
> very large players.  The phrase "Too big to ignore" has been
> rattling around in my brain for the last few weeks...

The problem would be big enough if even a minor actor did this and
it affected niche lists. The IETF endorsing FSVO endorsing a method
that breaks mailing lists if implemented in a way that suits systems
processing large amounts of email is simply not good enough.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Are we THERE yet?

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 Apr 2014 10:39:18 -0400

An odd, and somewhat nasty, thought...

So far, the two organizations (at least of which I'm aware) that
have made more or less public announcements of their intentions
to use the sort of restrictive policies that cause mailing list
problems are not only large providers of email but also large
providers of online forums, social group discussions, etc.  So
are several of the other member-contributor organizations to
dmarc.org.  As far as can be observed from the outside, those
forums and discussion groups make considerable contributions to
the bottom lines of those providers -- in most cases, they allow
those organizations to sell advertising and/or to sell their
users and their interest profiles to advertisers.   Email, by
contrast, is typically a service they provide in conjunction
with those other services but is not, itself, generally a profit
center.

For many of the users and uses of the extended Internet, mailing
lists are the historical predecessor, and sometimes a
contemporary alternative, to those forums and centralized
"social network" discussions.  

If one examines those relationships, there is a case to be made
that the problems they cause to mailing lists is not "collateral
damage" at all.  Even if the effects were discovered by
accident, continued use of DMARC with restrictive policies has
the consequence of driving traffic away from mailing lists,
perhaps especially mailing lists operated by smaller providers
and non-profits, toward use of the for-profit systems operated
by those same (to quote another recent comment) "too big to
ignore" operators with a positive effect on their bottom line to
the detriment of  other operators and ways of doing things.

Behaviors by large ("dominant", "too big to ignore", etc.)
industry actors that have the effect of driving alternate
solutions or providers out by mechanisms other than fair
competition in the marketplace, especially when those mechanisms
come out of collaborations among such actors, are, if other
conditions are met, rather seriously illegal in many countries.
If intent can be demonstrated, they are even more so.

So, as a purely hypothetical set of questions (I am not
recommending anything), I wonder what would happen if some of
the people who have been claiming they or the general public are
harmed by this would, instead of asking what the IETF can do
about something that is not an IETF Standard, went to their
local "competitiveness" or "antitrust" authorities, explained
the situation and started complaining?   I also wonder whether
the IETF and ISOC have, or should seek, legal advice about how
to keep adequate distance between themselves and this situation
should some relevant jurisdiction initiate an investigation or
enforcement action.

Just curious.
    john

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 29 Apr 2014 15:10:18 +0000

FWIW, we at Comcast just posted on this subject on our Postmaster page at http://postmaster.comcast.net/dmarcupdate.html.

- Jason

Pasted here as well:
Background

Comcast recently emplemented the Domain-based Authentication, Reporting, and Conformance (DMARC)<http://dmarc.org/> specification as a new way to help prevent phishing messages from reaching our customers’ mailboxes. DMARC enables a domain to publicly indicate (via DNS) what action should be taken for mail claiming to be from that domain that does not pass authentication and get reports about phishing and spam messages that did not come from approved mail servers.

Recent History
Recently, the policies that AOL and Yahoo published instructed mail servers that use DMARC to reject mail if it claims to be from aol.com or yahoo.com but failed authentication – meaning the mail did not originate from an approved mail server run by AOL or Yahoo, respectively. This has reportedly caused issues for some people using AOL or Yahoo addresses with email discussion lists and other mail sending tools. More information from AOL was posted here<http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/>.

While AOL and Yahoo may be addressing spam and phishing issues in making this change, it does not yet appear to be typical DMARC usage. We have been asked whether Comcast plans to make similar changes soon, and we can confirm we have no such plans.

Comcast’s Future DMARC Plans
To help us improve our detection of those who use the comcast.net domain maliciously we have published a DMARC record for comcast.net, but that change WILL NOT disrupt legitimate messaging. This policy will not ask other services to reject messages that did not originate from us, but rather report those instances to us for research. We will also publish DMARC reject policies in the coming months for the domains used by our Xfinity Billing, Xfinity Home, and Customer Security Assurance notifications. These originate from specific domains and servers that we maintain. This will not negatively affect email discussion lists but will help us prevent some of phishing messages that might attempt to target our customers.

If You Have Been Negatively Affected by AOL’s and Yahoo’s Changes
If you are an Xfinity Internet customer, use an AOL or Yahoo email account regularly, and are having problems getting email from email discussion lists or other tools at those addresses, we invite you consider activating or using your comcast.net email account.

To signup, add, or change your email account - Click Here<http://customer.comcast.com/help-and-support/internet/stay-connected-with-email/>

Once your email address is registered, you can access it in several ways:
For webmail users - Click Here<http://customer.comcast.com/help-and-support/internet/using-xfinity-connect-for-comcast-email/>
For email client users - Click Here<http://customer.comcast.com/help-and-support/internet/email-client-programs-with-xfinity-email/>
For mobile email users - Click Here<http://customer.comcast.com/help-and-support/internet/comcast-email-mobile-devices/>

On 4/29/14, 10:39 AM, "John C Klensin" <[email-masked]<mailto:[email-masked]>> wrote:

Just curious.
    john

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2014 16:47:59 -0000

In article <[email-masked]> you write:
>providers of online forums, social group discussions, etc. ...

You're not the first to suggest this, but simpler explanations
explain the situation.  I blogged about it here:

http://jl.ly/Email/aoldmarc.html

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2014 17:56:06 -0000

>The problem exists if A is publishing such a policy, B is acknowledging the policy, B is
>generating a bounce, and the bounce is hitting the mailing list provider.
>

DMARC lets you say p=reject or p=quarantine.  For whatever reason, AOL
and Yahoo are saying reject.  Using that p=quarantine would be nearly
as bad, with list mail eternally vanishing into spam folders.

>That said, the result of the above is that B is unsubscribed from the mailing list due to
>large number of bounces, but that is because B is recognizing the policy A is publishing.

Yes, but there are complicating factors.

One is that it's entirely possible to use DMARC responsibly.  It's
been around for a year, domains like paypal.com have published
p=reject, with no problems because nobody sends real paypal.com mail
via mailing lists or mail-an-article or the other stuff that is broken
by DMARC reject.

What changed is that two of the largest consumer mail providers had
huge security breaches where crooks stole user info including their
address books (both admit it, no conspiracizing needed) and used DMARC
as a sledgehammer to try and mitigate the damage.  I don't think
anyone is opposed to mitigating damage, but these particular efforts
had the predictable side effect of dumping costs on unrelated third
parties which AOL and Yahoo have so far done nothing to address.
Yahoo's blog admits that they are affecting 30,000 other providers, so
they know this is not a trivial problem.

Finally, the DMARC group includes the largest mail providers in the
world (I've seen DMARC bounces from Gmail, Yahoo, Hotmail, AOL, and
Comcast), who have such a large market share and so much market power
that it is not realistic to exclude users at those providers and tell
them to take their business elsewhere, no matter how well deserved
that advice might be.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Apr 2014 14:11:36 -0400

> consent to allowing her or his mailbox providers to know which lists

You keep thinking this is MLM problem.  NO, this is for all systems to 
follow. Even a BANK for example:

    "Ok, we need your email address for our new eBanking service!"

    "hmmmmm, oh, I'm sorry, your email domain receiver doesn't
     support DMARC so you will alway be open to fraud problems
     with your email address.  Have another address?"

    "Ok, hmmmm, oh, I'm sorry, that one too is no good to use."

    "No Problem, you can use our ONLINE service, with our EMAIL
     address or you can go another ESP mail service that offers
     DMARC operations."

It doesn't have to be a mailing list.

> How is the IETF going to proceed on this issue?

Get control of the DMARC draft with greater policy design advocate 
participation and begin to get operational policy discussions going in 
order to define new mail handling policy options.

Overall, the first principle thing is to:

    * HONOR THE PROTOCOL FIRST

This has the been the fundamental issue with the middle-ware market. 
Its not just the mailing list system. It could be any mail hosting 
service who may wish to begin (re)sign mail.

In all cases, the remailer has to check author domain signing policies 
and so far, they have refused to do so.  They prefer to do this in an 
unrestricted way that doesn't require the author domain permission. 
They wanted to change in order to ADD DKIM, but not change to ADD 
POLICY.  Its not just about the mailing list but any 3rd party 
resigner.   This is burned into the DKIM abstract:

    DKIM separates the question of the identity of
    the Signer of the message from the purported author
    of the message.

This was a fundamental flaw since it was not possible to separate the 
author from the message without violating the signer's signature of 
the message.  This would be another suggestion to do an DKIM RFC6376 
errata to remove this conceptual flaw and update the DKIM Assessor 
input requirements that would include the Author Domain Identity 
RFC6376 intentionally, refused to recognize or defined in the document.

I think the middle-ware operations who would be doing DKIM will do the 
right thing and add the DKIM+POLICY layer its been sourly missing if 
the IETF can correct DMARC or even ADSP to allow the resigner to exist 
in a proper protocol defined way.   All we had was IETF resistance to 
allowing policy to exist.  It made ADSP historic!  DMARC snuck in. 
Disaster!

There was a fundamental error in making ADSP historic so perhaps we 
should revisit why and learn from the engineering that was done and/or 
explored in order to update DMARC with the 9 years of multiple RFC 
development and insights.

I have an ethical engineering problem with ignoring protocol policies 
with offering by-passing suggestions.  The DMARC drafts needs to be 
updated if we want the middleware to coexist with it.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Apr 2014 15:00:12 -0700

> they know this is not a trivial problem.

Dear John,

From our experience, similar security problems affect social websites due to poor browser plugin vetting or poor cookie management.  Being highly balkanized, no equivalent DMARC policy will likely impact social websites since damage to privacy or security seldom become public.

No cryptographic mailing-list token or a list of trustworthy mailing-lists by outside vendors can remedy this problem due to liability risks.  Companies that deployed p=reject against user accounts neglected serious security issues for years.  In many cases, their services are on behalf of other ISPs.  Fortunately, gmail.com has not asserted p=reject.

Redirecting responsibility by using DKIM or SPF is at the crux and the basis for DMARC.  Neither of these schemes authenticate the domain introducing the message and ignore intended recipients. This indirection has become endemic and makes it difficult to scale for IPv6 or to permit valid third-party services.

One viable method agnostic to verification schemes is http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 (TPA).  Yahoo and AOL can compile their needed TPA exceptions.  This scheme should scale better than other extensions in use, especially DKIM or SPF.  

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.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 29 Apr 2014 16:54:35 -0700

On Tue, Apr 29, 2014 at 3:00 PM, Douglas Otis <[email-masked]> 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.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 29 Apr 2014 17:03:12 -0700

> posted here last week, a process which doesn't seem to affect

The ISE asked me for a revision to correct a couple of IANA things.  That
revision was posted the same day.  My understanding is that it's now just
waiting for its turn ISE's queue.

As I understand it, there's no responsible AD in the ISE stream, except
maybe as an IESG liaison thing.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 29 Apr 2014 21:11:22 -0400

> scaling problem.  I think that's the more interesting thing to discuss.

I completely agree.  Dunno if that belongs in ietf-822 or ietf-smtp.

It seems to me that the way you scale is to limit the number of 
whitelists, and leverage the information that large players already have, 
e.g., the 30,000 mail hosts that Yahoo said they knew they broke.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Apr 2014 18:30:54 -0700

On Apr 29, 2014, at 4:54 PM, Murray S. Kucherawy <[email-masked]> wrote:

> 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

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Apr 2014 21:37:27 -0400

On 4/29/2014 7:54 PM, Murray S. Kucherawy wrote:
> On Tue, Apr 29, 2014 at 3:00 PM, Douglas Otis <[email-masked]
> <mailto:[email-masked]>> 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.

Disagree, because you went at it half-hearted. You made it 
experimental and your abstract even stated that it probably means 
nothing. More importantly, Levine and Crocker didn't support the 
effort, so it didn't have a chance at all.

Its call marketing just as it was done with DMARC which is less 
flexible than any other policy system.  If you don't champion it, it 
goes nowhere.

> 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.

It was already discussed. Unless you are sharing this "Whitelist" in 
some centralized fashion, it won't be a persistent and consistent 
protocol solution.  What it will promote is targeted abuse at those 
sites that do not have the same whitelist -- You ware making it so 
that "Batteries Required" in order to function.

We been thru this already.  We need a standard consistent and 
persistent domain based solution all can apply equally and one that 
you don't need to buy "Batteries" to get any payoff.  Even with all 
the "small use cases" belief that is being proven wrong about policy, 
you guys are still in denial about policy.   Everyone is telling you 
guys you got it all wrong, and you still won't listen. This thing will 
never be solved with a status quo.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Apr 2014 13:24:02 +0200

Hi,

> If intent can be demonstrated, they are even more so.

That picture can get even more compelling by comparing DMARC's core
with SPF policies as historically proposed.  It was well known that
SPF breaks forwarding while ADSP breaks mailing lists.  DMARC chose to
err on the ADSP side, by confining SPF to an auxiliary author's domain
verification role.  One might malign that forwarding is requisite for
free-mail providers who draw users among people who already own a
mailbox somewhere.

However, I'm for a teleonomic view, where chance and necessity
determine the selection of fitter coalitions of structures and
functions.  The outcome favors for-profit systems because that is
(still) what our society is built upon.  If IETF, ISOC, or open-source
movements aim at promoting a different model of human cooperation, I
regret to conclude that the likely negative answer to the question in
the subject is to be considered something of a defeat.  Some competed
for an alternative evolution (recall the endless discussions since
MARID) but found no consensus.

> the situation and started complaining?

I'm neither a lawyer nor an ML admin, so I'm not going to claim
damage.  Yet, like most of us, I'll be harmed if MLs stop working well.

> I also wonder whether the IETF and ISOC have, or should seek, legal
> advice about how to keep adequate distance between themselves and
> this situation should some relevant jurisdiction initiate an
> investigation or enforcement action.

Rather than rebuffing responsibility, I'd expect the IETF to invent
something new, which works much like ML used to, but is compatible
with DMARC.  Yes, we may continue to call them "mailing lists".  The
alternative, to blame domains which follow the leading trend, doesn't
seem to be very promising...

Ale

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Apr 2014 09:13:33 -0400

> damage.  Yet, like most of us, I'll be harmed if MLs stop working well.

This was only a surprise to the people we were resistance to adding 
policy support.  Author Domain Policies had the same "know your 
network" migration issues SPF did.  Domains had to adjust by switching 
to more relaxed domains to participate in a public networking arena. 
I did the same. I remove all public usage of company's exclusive 
domains santronics.com and winserver.com and switched them to isdg.net 
where its a more relaxed author domain policy and one I can use to 
explore with.   Everyone serious about this stuff were aware of this 
stuff for nearly 9 years.

Besides, it was written in the DKIM abstract with its questionable 
"responsibility" semantics which I kept saying it really needs to get 
removed or get rephrased.

    DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message by associating the domain with the
    message.

If you are going to ask domains to begin signing, put investment in 
it, then why would anyone thing they would not want to invest in 
protecting the signature, and thus the message?

The only way to do this was with the original proof of concept -- 
AUTHOR DOMAIN SIGNING POLICIES!  Hate yelling it but is seems to be a 
central key point in all this forgotten.

Of course, the other argument could be that we don't want such strong 
and food for legal eagles semantics in our docs.  We continue to face 
this passé mail design attitude for relaxation, incremental changes, 
yet, the problems do not get resolved this way.  Without the strong 
semantics, you can't deal with the legacy abuse mail operations. You 
lack a payoff. DMARC has forced that "relaxed" mail design mentality 
to change for the IETF.

> seem to be very promising...

They keep saying they don't think think the MLS needs to change, too 
historic. Its ok to add DKIM, but not Policy?  I don't buy it. I'm a 
long time MLS developer we have hundreds of operators with list 
operations.  It didn't make sense to me why you would add something 
that was half-ass complete.  Probably explains I'm one of the few 
implementators, if not the only one, of DKIM+POLICY (ADSP, ATPS) n a 
mailing list server product.

Adding DMARC is not going to be a problem.   It remains the same, it 
will be just like before with ADSP with the end of the day setup 
semantics:

     p=reject     is only for EXCLUSIVE domains for SYSTEM-WIDE 
application.
     p=quarantine is only for EXCLUSIVE domains for PER USER (junk 
bins) application.
     p=none       is for all, but with unknown handling.

If that is how it needs to be doc for my sysops, so be it.

The only issue would be to add a deployment option for p=reject

   [X] Enable DMARC

    (o) p=none
    (_) p=quarantine
    (_) p=reject
        (o) SMTP Reject with response ____________________
        (_) Accept and discard
        (_) Accept and keep

Or something like that.

-- 
HLS