Subject: [dmarc-ietf] DMARC ATPS Interop Note

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 15:54:55 -0400

Since 05/2014, I have published DMARC records for several of my 
domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag 
extension was added to my records. For example, for my non-corporate, 
"play around" domain isdg.net, I have:

   "v=DMARC1; p=none; atps=y; rua=mailto:[email-masked]; 
ruf=mailto:[email-masked];"

ATPS draft rev04 was written as a ADSP extension.  With Rev05 and the 
final ATPS rfc6541, ATPS was made an extension off the DKIM record 
instead, not ADSP.

What I did was added ATPS support to the DMARC record as an 3rd party 
Extension allowed by DMARC.

I am happy to report that after two years, there is no indication for 
an interop problem.  The unknown tag to non-supported ATPS receivers 
does not interfere with the DMARC processing.   The reports received 
come from a wide number of domains.

I am also happy to report that the concept works very well in 
authorizing third party resigners using the ATPS (rev04) protocol. 
Here is an actual Auth-Res for a list message ietf.org resigner.  I 
put a divider line for better viewing:

Authentication-Results: dkim.winserver.com;
  ----
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=pass policy=all author.d=isdg.net asl.d=ietf.org;
  dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps 
signer);
  ----
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 
header.i=isdg.net;
  adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer);
  dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net 
(originating signer);

The first bottom triplet results are for the original signature. It 
fails the DKIM signature with a body hash mismatch. Both ADSP and 
DMARC pass as original signers (author == signer). In reality, if the 
rejection switch was enabled, this should be a FAIL because the 
signature is invalid.

However, for the ietf.org list resigner triplet results, it passed as 
an ADSP ASL resigner and ATPS record resigner  (author != signer).

DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our 
commercial Application Hosting package used by customers in the field.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 16:27:19 -0400

>commercial Application Hosting package used by customers in the field.

I think it's wrong to describe that as a DMARC result.  For DMARC as specified, that's a fail.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 16:31:51 -0400

> I think it's wrong to describe that as a DMARC result.  For DMARC as specified, that's a fail.

Not following  you.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 16:36:51 -0400

> I think it's wrong to describe that as a DMARC result.  For DMARC as specified, that's a fail.

Oh, you mean, there should be a "atps=" auth-result?  oK, I can buy 
that but then again the AUTH-RES is for internal consumption not 
external, having it a single source result to a DMARC result reader, 
would be ok.

Nonetheless, the end result is the same, the ATPS would authorized the 
resigner. No other DKIM signature related changes need.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 16:53:07 -0400

Scott,

If this is what you are talking about, there should of been an 
AUTH-RES line for "atps=",  I can understand that valid technical 
point, but I don't agree it is absolute.

First, it is a DMARC extension and long as it is an indicated marker 
in the DMARC result, then should be ok.

Second, related, one of the problems with AUTH-RES and the reason 
there is so many changes to it, is because its doesn't quite satisfy 
what an receiver might need.  I had that problem with just adding ADSP 
to it.  It didn't even support getting SPF fully reported.

In other words, the dynamics are still changes in order to get a solid 
AUTH-RES reporting header completed.  In fact, if your point is taken 
serious, then AUTH-RES will need even more updates to support other 
results, such as the double signature proposal.

So this is a side issue that really has nothing to do with the overall 
basic protocol issue we are dealing with, but it is a good note to 
point out because you will run into the same "separation" issue with 
any other additional layer you want to add on top of DKIM and into the 
AUTH-RES header.

Thanks for the note.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2015 14:09:09 -0700

> specified, that's a fail.
More precisely, for both DKIM and DMARC it's a fail.  For DKIM+ATPS-04,
it's a pass, but DMARC doesn't pay attention to that.

I think it's also important to note that this only proves interoperability
with a single implementation (granted, in multiple roles), unless there's
data indicating multiple implementations are involved.  This seems
unlikely, since as far as I know there aren't any other implementations of
ATPS-04 or even the RFC version.  OpenDKIM did the RFC version, and it's
not compatible with -04.

Also, this is only part of the whole story.  There's still that pesky
registration problem to address.  I think for ATPS or anything like it to
be considered a plausible thing to pursue, that's critical.  It might be
interesting to know some of the characteristics of the largest operator
involved in that report (total domains, total users, details about MLM
traffic, etc.).

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 18:03:22 -0400

On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote:
> On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> More precisely, for both DKIM and DMARC it's a fail.  For
> DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that.

Now we are getting into definition and software engineering.

DMARC result is a PASS when it is an extension, and in this case, it 
is an extension, and it is noted as an extension:

In other words, does the AUTH-RES protocol allow it itself to be 
extended, it is flexible enough?   If not, then AUTH-RES will need to 
be updated again.

> I think it's also important to note that this only proves
> interoperability with a single implementation (granted, in multiple
> roles),

Running code.

> unless there's data indicating multiple implementations are
> involved.

The more the merrier, but it is running code.

> This seems unlikely, since as far as I know there aren't
> any other implementations of ATPS-04 or even the RFC version.
> OpenDKIM did the RFC version, and it's not compatible with -04.

I wish I was there to "protest" making it extend off the DKIM code 
which required a change to it.  That is enough reason to not support 
it.  I wouldn't either.   That should be noted.

> registration problem to address.

Separate issue.  SPF would not be here if you used this same criteria. 
None of the big domains you are concern about have hard fails for SPF 
for the same reason -- it can not "register" their SPF network of 
possible users.  Same problem.   Didn't stop SPF from moving forward, 
first externally,  and then as an IETF "experiment" because making it 
a "proposed standard" back then during MARID would of cause much protest.

> I think for ATPS or anything like it
> to be considered a plausible thing to pursue, that's critical.

Its important for its success, but I don't buy its a problem nor 
should it be barrier to establish the DNS-base protocol.  DNSSEC is 
problematic for the same reasons (lack of record support) Don't stop 
people from moving forward with it despite its pretty much useless to 
the general market as a whole.

> It
> might be interesting to know some of the characteristics of the
> largest operator involved in that report (total domains, total users,
> details about MLM traffic, etc.).

It would be interesting but I don't think that proves anything whether 
it was a million, thousand or just one -- Dimensional Analysis is 
applicable.

When you design the protocol properly, it applicable to all sizes. 
Thats the mark of a good IETF protocol -- it doesn't choose size and 
its doesn't create conflicts of interest.  You and scott don't believe 
it is and I believe that is somewhat hypocritical of the fact that SPF 
has the same exact registration issue that prevented many of the 
larger public service domains from using the "-ALL" policy.

Whatever is done, you will always need the "Data" but you need the 
protocol in place and by far, the most feasible way to do this, is by 
leaving DKIM alone and work on the policy layer.  If the alternative 
requires DKIM changes for the same purpose and you going to nix ATPS 
and go with some double signature method, I think it is necessary from 
an IETF standpoint that you also offer the baseline solution which is 
the DNS call method.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 19:24:23 -0400

> involved in that report (total domains, total users, details about MLM

No, it's OK for DKIM.  The trick is d=ietf.org, which doesn't align for DMARC 
purposes.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 19:42:08 -0400

> extended, it is flexible enough?   If not, then AUTH-RES will need to

A-R is certainly extensible, but there are IANA registries that need to be 
updated.

RFC 7489 defines DMARC.  In fact, if you look at the registry [1], it points to 
RFC 7489 for the definition of how to use A-R for DMARC.  If you are doing 
something different than that, you're doing it wrong.  Call it something else 
and a comment isn't sufficient.  An A-R header field should be able to be 
automatically processed without reading the comments.

Neither author.d nor signer.d are not defined.  Given the use of unknown 
properties with a known method, I think any implementation might reasonably 
ignore this entire result.

I think this should be registered (if it merits continued development and 
deployment) as its own method.  Then you might have something like:

dmarc-atps=pass header.from=isdg.net signer.d=ietf.org
dmarc=fail header.from=isdg.net

Consumers can then decide if they care about dmarc-atps without having to 
interpret a new authentication method's results if they don't.

Scott K

[1] http://www.iana.org/assignments/email-auth/email-auth.xhtml

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 19:46:21 -0400

> any other additional layer you want to add on top of DKIM and into the

ATPS is assigned in the registry {1] as dkim-atps.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 21:48:30 -0400

> A-R is certainly extensible, but there are IANA registries that need to be

Its not extendable (meaning its optional as well) if you can not use 
the same namespace. Think flexible I/O functional interfacing with 
null/default parameters. You
want to use the same I/O otherwise more updates are required.

> RFC 7489 defines DMARC.

True, just consider per DMARC (RFC7489) section 3.1.3

   3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

This means that AUTH-RES semantics requires to be functionally 
compatible (extendable) as well from an integration standpoint.

>In fact, if you look at the registry [1], it points to
> something different than that, you're doing it wrong.

First, the work predated DMARC and second, Murray was made aware 
AUTH-RES was not flexible enough for DKIM+ADSP+ATPS as it wasn't for 
SPF.  It may be today. I haven't checked.

> Call it something else and a comment isn't sufficient.

So why was it acceptable by you for SPF?

> An A-R header field should be able to be automatically processed
> without reading the comments.

I agree, but software is smart it can do a "(atps signer)" string 
check, just like you accepted the "(comment) kludge to complete SPF 
AUTH-RES reporting as well.

> ignore this entire result.

AUTH-RES is constantly being updated and IMO prematurely registers 
stuff because it actually is a real standard in practice.  But this is 
all besides the point.  You are going off on an tangent that has 
nothing to do with this.  Plus, it wasn't defined so you do what you 
need.  It SHOULD NOT break any current Auth-Res reader.  Lets also 
note the AUTH-RES is for internal consumption and actually more for 
reporting because odds are good they are internal ways to do the 
handling anyway.  Lets not not assume it will all be done by reading 
AUTH-RES, i.e. SMTP level rejection at DATA.

> interpret a new authentication method's results if they don't.

Those are details. I agree we want to a consensus on a common 
nomenclature, but its all besides the point.

I did not want to make this issue about Auth-Res, but if you ask me, 
from a plug and play standpoint, if you have an DMARC handling reading 
Auth-Res as it written with a
"dmarc=" namespace, I would not propose a new "dmarc-atps" namespace. 
  Its an extension of DMARC therefore it belongs in the same "dmarc=" 
namespace.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 May 2015 21:51:43 -0400

> ATPS is assigned in the registry {1] as dkim-atps.

As stated already, the work predated what Murray did after ATPS rev04.

But its good to know that is this is the case and this is yet another 
good reason to continue with ATPS work.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 23:05:24 -0400

> good reason to continue with ATPS work.

I'm really not sure what you're talking about (and equally not sure I need 
to), but in version -00 of the ATPS draft it already had:

   Method  dkim-atps

   Defined In  [THIS MEMO]

   ptype  header

   property  from

If you want to document a ATPS result in an A-R header, there's a way to do it 
and that's how it should be done.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 07 May 2015 23:18:26 -0400

> want to use the same I/O otherwise more updates are required.

All that goes in the DMARC part is the deader.from and the result.  It doesn't 
need to be extended to add a new auth method.

> compatible (extendable) as well from an integration standpoint.

And it is.  You put the new information in a phrase of the header field 
dedicated to the new method.  It only changes the result for DMARC once DMARC 
has been extended to include it, which it hasn't been yet for ATPS or any 
other method.

> SPF.  It may be today. I haven't checked.

For SPF, it's adequate to communicate the result.  It's not adequate to allow 
someone to independently reconstruct and assess the validity of that result, 
so it's less useful as a trace header field than Recieved-SPF, but given it's 
goals, it meets them.

> So why was it acceptable by you for SPF?

You get an identity and a result which is all that's absolutely needed to 
machine parse the SPF answer.  As above, it's adequate even if not, from my 
PoV ideal.

> AUTH-RES reporting as well.

No.  If you make any assumptions about the contents of a comment field, that's 
a poor design.  You can, but you shouldn't.

> AUTH-RES, i.e. SMTP level rejection at DATA.

It's true that A-R was designed for consumption inside an ADMD.  It doesn't 
necessarily follow that all software within that ADMD is provided by a single 
vendor.  A-R is standardized to make that internal communication easer.  I 
think your point about internal consumption is true, but not particularly 
relevant.  Also, people have proposed extending the structure to carry 
authentication information from a trusted mediator to a receiver which is at 
most only sort of internal to an ADMD.

As long as in your experimentation you don't interfere with what's already 
standardized (and IMO your example did), then I'm fine with it.

>   Its an extension of DMARC therefore it belongs in the same "dmarc="

As above, no.  It's an auth method that DMARC uses, not a internal part of 
DMARC (SPF and DKIM results are not reported inside a DMARC= namespace and 
this is no different).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 May 2015 00:05:32 -0400

> and that's how it should be done.

Thanks for the "bug" report.

I should of stated it predated all of the ATPS work.  Before ATPS, 
there was Doug's TPA and my ASL (Allowed Signer List) which came from 
the DSAP 2006 I-D.  ATPS is a simpler version of TPA, uses the similar 
base32(sha1()) hashing function logic for the sub-domain signer domain 
label.    ASL is a ADSP "asl=resigner-list" tag for the smaller scale 
that can fit into a single UDP byte limit.

I should note this was all done when RFC5451 AUTH-RES was written. 
Only DKIM and SPF recorded by this moving target specification.  I 
only recorded DKIM since SPF already had Received-SPF and DKIM was 
still working on ADSP.  AUTH-RES and I meant RFC5451, was still 
incomplete and still a moving target.  It was noted (a post/comment) 
that it didn't cover the needs required.

It was all experimental and still early exploration.   In any case, 
thanks for the bug report.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 May 2015 23:08:12 -0700

> No, it's OK for DKIM.  The trick is d=ietf.org, which doesn't align for

We're saying the same thing, I think.  I'm presuming a post-MLM message
with an author domain signature and an MLM domain signature.  The aligned
author signature will presumably fail, and the ietf.org signature will
presumably pass.  That's all pure DKIM will tell you.

DKIM+ATPS would tell you the additional bit that the From: domain signer
also approved the ietf.org signature, but as presently specified, DMARC
doesn't care about that.

-MSK

---

From: Anne Bennett <[email-masked]>
Date: Fri, 08 May 2015 13:29:33 -0400

Murray S. Kucherawy writes (with respect to ATPS if I got this right):

>> There's still that pesky registration problem to address.

Hector Santos writes:

> possible users.  Same problem.

I'm not convinced that it's the same problem at all.

In the case of SPF, I am (supposed to be!) in control of
and knowledgeable about which IP addresses are used by my
outgoing mail relays, including any third parties I might hire
to send out bulk mail on my behalf.  Their registration by me
into my own DNS is trivial.

Now of course we all know that if I used "!all" in my SPF
record, this would break messages from my users who:

  1 - ... are currently offsite but set their From: line to
      my domain, then submit mail through another provider.

  2 - ... post through a mailing list offsite which doesn't
      munge "From:".

  3 - ... send to recipients who in turn forward their mail
      (without fancy workarounds) to a third site.

I don't think that anyone would suggest that the correct fix
for any of the situations above would be to add the relevant
IP addresses (of my offsite user's ISP's mail relay, of the
mail relays of all the mailing lists to which my users might
post, or of my users' recipients' "forwarding" mail relay)
to my SPF record.

Therefore, I don't think that SPF has a "registration problem".
It has plenty of other problems, but not that one.  ;-)

But if I understand correctly, it's being suggested that for
various proposals made here to work, either the sender's mail
system or the final receiver's mail system would have to become
aware of all of the "legitimate" (definition purposely left
out!) mailing lists to which its users subscribe.

To me, *that* is a registration problem.

I believe that some people have claimed that this problem is
easily overcome (or perhaps "worked around" would be a better
expression) by examining mail headers and gathering statistics,
and this may well be the case, but addressing the problem in
this way will always depend on heuristics, just like any other
anti-spam method.

I cannot see how it would approach a reliable pass/fail result,
which I've been told is what DMARC is all about: don't make the
users have to decide anything!  Handle it all before delivery!

What am I missing?

Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email-masked]                                    +1 514 848-2424 x2285

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 May 2015 18:47:58 -0400

> into my own DNS is trivial.

How about your roaming users?  How about when users use other MSA 
sites?   If you have such a mail network among your domain, then for 
the most part, the domain is restricted to relaxed policies.   It 
can't use hard policies.

Please note, as an early explorer, I didn't believe it was a problem 
for SPF, nor do I believe its a problem for ATPS-rev04.  SPF suffered 
through the same basic "scale" and lack of path independence 
arguments.  "SPF was not path independent. It didn't scale." DKIM was 
suppose to be the alternative as a path independent solution -- that 
was the marketing behind it.

> record, this would break messages from my users who:

Do you mean "-ALL" hardfail policy?

>        my domain, then submit mail through another provider.

Roaming user. :)

>    2 - ... post through a mailing list offsite which doesn't

5322.From is not SPF related.  You mean the 5321.MailFrom?

>        (without fancy workarounds) to a third site.

A simple relay, sure, SPF has that problem you will only see for -ALL 
policies.

> post, or of my users' recipients' "forwarding" mail relay)

I don't think anyone has suggested that. That is the domain's business 
and it may also mean the domain is not a candidate for strong policies.

That is what surprised everyone when Yahoo.com flipped the rejection 
switch.  Its a long time public service domain with a wide network of 
users, many roaming around.  But the market is changing with more 
centralization and domains wishing to finally clean up their aged and 
spam-polluted domains.

> It has plenty of other problems, but not that one.  ;-)

To me, it is pretty much deja vu. :)  I didn't have the problem as 
most private, corporations, non-public service domains do not have 
this problem.  Only the public service domains have a bigger issue 
with it.  The corporate Microsoft.com domain can do a -ALL but can not 
use a hard fail for outlook.com, hotmail.com and msn.com public 
service domains.

Note again, I was not one to agree it was a problem for SPF as I don't 
believe it is a problem for ATPS-rev04.  But the same/similar issues 
were raised. DKIM was argued as a better solution because it didn't 
have the path independent problem.   That was a flawed idea.  They 
both had mail path problems once you have a DKIM policy layer.

> To me, *that* is a registration problem.

Sure, but its a typical one and IMO, generally considered as an 
implementation issue, more related to the business itself.  You can 
argue that its a barrier to adoption too, but its not something that 
preempts protocol designs. APTS follows a standard client/server 
negotiated Lookup methodology/solution that SPF, DMARC currently 
enjoys as DNS-based applications.   We are trying to fit in another 
lookup or make it piggy back off the existing lookups to minimize the 
overhead.

> this way will always depend on heuristics, just like any other

I agree. This is why it is a separate implementation issue.  We are 
looking for a deterministic protocol solution.   The lack of not 
having the "registration" in place first should not stop one from 
"checking" to see if it exist.  If this becomes wasteful with no 
payoff, we can later deprecate it, turn it off.   We desire a short 
term adoption, adaptation, migration, etc, but it can be long term 
too.  Just considered, all this started around 2003 and we are still 
fussing with it.

> users have to decide anything!  Handle it all before delivery!

Yes, deterministic, system level, no mail acceptance at SMTP, a 55x 
return code. This can be also a SMTP accept/discard mode of operation 
(250 and this discard it) or possibly the accept/quarantine mode of 
operation which keeps it from the user's main in-box, but he can still 
see it in a spam folder.

> What am I missing?

Nothing. :)

You appear to have roaming user problems. You can't use a hard SPF 
policy because you can't register all these users in how they send the 
mail.   Therefore, you have a more open, public, relaxed policy. 
Millions of domains have more control and use a -ALL policy.  They do 
not expect their users from using their domains in public unknown ways.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 May 2015 17:19:35 -0700

> Murray S. Kucherawy writes (with respect to ATPS if I got this right):

You did.

> [...]

Agreed.

> To me, *that* is a registration problem.

Agreed again.  And as Terry has said and I think we can infer about other
large operators, it's incorrect to assume (and plain wrong to assert) that
this is an easy problem for them to solve in a reliable way.

> this way will always depend on heuristics, just like any other

Right; the claim is that this is a well understood problem and that the
cost of implementing it is low.

I don't agree.  In addition to the above, no two operators will have
exactly the same idea of what fits here, or what components of their local
system they need to include.  Punting on this as an "implementation issue"
leaves a pretty substantial hole in whatever gets rolled out.  To me it's
like buying a car with a completely absent steering mechanism, and you have
to do the research to figure out which one fits and works for you, and
probably build it yourself too.

At a minimum, we need to describe detailed requirements of this component.
Having something open source that works in general would also be helpful,
but at best we only have a rough sketch of what that would look like right
now.

> What am I missing?

Not a thing.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 May 2015 19:01:42 -0700

> this is an easy problem for them to solve in a reliable way.

The current situation is NOT producing reliable results nor
can it get better without additional information being made
available from the DMARC domain requesting restrictive
handling against non-transactional exchanges.  DMARC must
stop ignoring the role of Sender header fields, or make an
effort to avoid disrupting legitimate, well formed, SMTP
compliant, and socially beneficial exchanges.
> cost of implementing it is low.

For the DMARC domain, identifying legitimate third-parties
can represent rather straight forward results determined by
comparing recent output logs against DMARC feedback. 
Information that only the DMARC domain is able to
authoritatively confirm.  Arguing about cost misses the fact
that expecting recipients to make this type of determination
before imposing requested and possibly disruptive policy is
simply not practical.

We would love to have the opportunity to demonstrate the
implementation of such a system at scale on behalf of a
large provider.  ATSP won't work, but can be altered to
avoid requiring special DKIM signatures or indeterminate
labels.  Since this scheme would only come into play when
handling otherwise restrictive handling, the impact would be
small but highly beneficial by eliminating the disruption of
valid, and socially desired messages.  If there is a case to
be made that restrictive handling is needed but is being
misapplied against non-transactional messages, then there
are two ways forward. 

1) Recipients will decide the DMARC policy is too disruptive
and not honor the requested handling by the disruptive domains.

2) Senders can recognize they must provide additional
information to avoid disrupting socially valued services
exchanging properly formed messages where the author remains
apparent to recipients.
> probably build it yourself too.

Which is why we volunteered to help at implementing a
solution that provides recipients DMARC domain derived
information necessary to prevent unwarranted disruption of
services.
> I cannot see how it would approach a reliable pass/fail result,
A pass/fail result is possible only when DMARC domains offer
necessary information that only they can assemble. The cost
of sharing this information is extremely low for both the
sender and the recipient.  We  did this as a free service
for about 80% of the world's email at one time.

Assembly of information may not be immediate but the
collection of this information should be fairly stable. 
There may be some prompting required to ensure there are no
gaps in coverage. 
>> users have to decide anything!  Handle it all before delivery!
Removing risk exposure from recipients is fine.  But don't
toss out valued messages or obscure authors because avoiding
disruption seems like too much effort.  It is not. 
Shortcuts working without the necessary information will
intimately prove even more problematic.  I have an
increasing number of legitimate messages ending up in my
spam folder along with their look-alikes.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 May 2015 00:40:30 -0400

On 5/8/2015 8:19 PM, Murray S. Kucherawy wrote:

>Punting on this as an
> "implementation issue" leaves a pretty substantial hole in whatever
> gets rolled out.  To me it's like buying a car with a completely
> absent steering mechanism, and you have to do the research to figure
> out which one fits and works for you, and probably build it yourself too.

I don't get the metaphor. Who will buy a car with a steering problem? 
  Anyway....

It is an implementation issue.  You can even use RFC6541 if you wish 
to illustrate there was a lack of adoption. The Interop report should 
research why.  We can probably say:

   - Short or Long Term adoption of publishing records,
   - Requires DKIM Code Change,
   - Migration issue. ADSP was implemented and then abandoned,
   - It was labeled experimental.

It was a moving target. ADSP was being played down. With ATPS-Rev04, 
no DKIM code change was required.  Running code is in the field.   You 
might want to say (repeat) why the public service domains have a 
harder time at publishing records or can use this technology.

> At a minimum, we need to describe detailed requirements of this

Probably as implementation notes, but it shouldn't be a barrier.

I do believe Functional Requirements should be defined because there 
are at least 3-4 proposals and I am about to throw in there one or two 
myself.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 09 May 2015 18:00:24 +0900

Murray S. Kucherawy writes:

 > Agreed again.  And as Terry has said and I think we can infer about
 > other large operators, it's incorrect to assume (and plain wrong to
 > assert) that this is an easy problem for them to solve in a
 > reliable way.

Please define "reliable."  I gather you all think that missing some
mailing lists is a bigger problem than missing all of them, but for
the life of me, I cannot see why.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 May 2015 10:09:34 -0400

>the life of me, I cannot see why.

How many solutions do you think operators will be willing to implement? As I indicated in my utility assessment framework, I think we get a maximum of one solution that requires cooperative implementations in multiple parts of the originator/mediator/receiver trilogy. Given that, it had better be reasonably comprehensive. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 9 May 2015 08:07:49 -0700

> the life of me, I cannot see why.

I'm having trouble coming up with a heuristic that is even certain to grab
"most" of them.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 10 May 2015 02:09:09 +0900

Scott Kitterman writes:

 > How many solutions do you think operators will be willing to
 > implement?

As many as have an expected benefit/cost ratio greater than 1, of
course.

If you want numbers, my expectation is about 0.5 (the odds are
perceptibly better than even that *nothing* will be done), but I would
hardly be surprised by 2 or more, since it seems likely that mailing
lists and 3rd-party originated messages will require different
solutions, and I think the operators would like to implement given a
favorable benefit-cost ratio.

 > As I indicated in my utility assessment framework, I think we get a
 > maximum of one solution that requires cooperative implementations
 > in multiple parts of the originator/mediator/receiver trilogy.

Hm.  That's strange.  They've already implemented SMTP, SPF, DKIM, and
DMARC.  By my count, that puts them a minimum of three solutions past
what what you expect.

 > Given that, it had better be reasonably comprehensive.

I expect that levine-dkim-conditional + "register addresses found in
List-Post as candidates for delegation when an authenticated user
posts" is as cheap as it's going to get, and will cover more than half
of mailing lists.  I think that's pretty comprehensive for a start,
and thus something worth thinking about and looking for improvements,
rather than rejecting because it won't eliminate world poverty in 30
days.

---

From: Hector Santos <[email-masked]>
Date: Sat, 9 May 2015 13:11:21 -0400

Heuristics for this are quite simple to generate.  But it needs verification, confirmation, authorization before it can be automated.  That is what makes it a heuristic and doesn't belong in the SMTP transport where this protocol can be implemented if only from a delayed learning concept, i.e. similar to a grey listing concept.   In general, A typical reason to automate is to reduce the human involvement cost.

It was long known this would be a complex integrated solution.  No matter what, the MLM receiver must also follow policy protocol, all receivers, there is not just one, but two at a minimum with this type of mail steam.   Even if the simplistic DNS call solution is (erroneously) pushed aside, again, the MLM must still support the rejection at the submission point for those that do not wish to have a more complex, costlier, alternative delegation or any resigner involved.  If not, it didn't solve the problem and it just made the DKIM integration design extremely more complex!  

--
Hector Santos
http://www.santronics.com

> On May 9, 2015, at 11:07 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
>> On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull <[email-masked]> wrote:
> I'm having trouble coming up with a heuristic that is even certain to grab "most" of them.
> 
> -MSK
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Hector Santos <[email-masked]>
Date: Sat, 9 May 2015 13:13:15 -0400

Your bar is too unrealistically high for typical IETF project work that is still in the experimental stages.   You should be thankful, we didn't apply this bar to the SPF experiment.

> On May 9, 2015, at 10:09 AM, Scott Kitterman <[email-masked]> wrote:
>

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 10 May 2015 03:03:45 +0900

> I'm having trouble coming up with a heuristic that is even certain

Without definitions of "certain", "'most'", and "them", how is anybody
supposed to meet such a requirement?

Pending receipt of such definitions, I'll go see if I can get some
statistics on how many of two large collections of mailing lists add
RFC 2369 List-Post fields.

---

From: Terry Zink <[email-masked]>
Date: Sat, 9 May 2015 18:11:57 +0000

The reliability aspect is realistic to set a high bar. The decision to allow unregulated users to publish to the zones of Hotmail.com/outlook.com/msn.com/live.com/Hotmail.ca/outlook.ca/live.ca... etc. is one that comes with its own security challenges. This now no longer a way to allow indirect mailflow to pass DMARC, but instead how to figure out a way to secure your DNS zone. For the amount of work that would be, I would rather just inventory all mailing lists and if an email comes from it into a domain filtered by Microsoft, suppress DMARC. 

It's not just Microsoft's consumer brands. Office 365 hosts email for small, medium, and large businesses - each with their own DNS zone. If we have 500,000 domains [1] and there are 100,000 mailing lists, are we going to publish DNS records for the full matrix of combinations - 50 billion? Or even 1 billion? We don't control customer's DNS zones, so we'd have to convince our customers to publish these records and to do it on a regular basis. I can see nobody agreeing to do that. And if it won't work for Office 365 then it won't work for Hotmail, outlook.com, live.com, etc.

I can't see the solution of publishing things in your DNS zone as a workable solution. That's why I like the conditional @fs DKIM signature better (or some variant of it) - it's done on the MTA level. A customer domain, example.com, can sign up for the Office 365 service and not have to publish any mailing list third party authorization in their zone. Instead, the sending MTA adds the required DKIM signatures and the receiving MTA decodes the incoming receiving signatures and does the right thing. The process is transparent to end users, most of whom don't want to update their DNS zones.

-- Terry

[1] I don't know exactly how many domains we have, I just picked this as an example.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 May 2015 14:52:52 -0400

>favorable benefit-cost ratio.

0.5 is about my estimate too.

>DMARC.  By my count, that puts them a minimum of three solutions past

I meant how many solutions to the DMARC mediated sender problem. Yahoo, for example, already consider the impact of this and other breakage to be less than the benefit of p=reject.  I expect their willingness to invest engineering resources in further reducing a level of breakage they've already determined is acceptable will be limited.

>rather than rejecting because it won't eliminate world poverty in 30

I think that's at least one more than gets implemented. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 May 2015 15:01:59 -0400

On May 9, 2015 1:13:15 PM EDT, Hector Santos <[email-masked]> wrote:
>Your bar is too unrealistically high for typical IETF project work that
>is still in the experimental stages.   You should be thankful, we
>didn't apply this bar to the SPF experiment.

It wasn't brought to be the IETF until it had substantial deployment. 

Actually, the idea behind MARID was to come up with a single solution and if not for one company insisting on licensing terms that would have precluded free software implementations, I think we would have succeeded. 

So I disagree. I think what I'm describing isn't that different than the non-political aspects of how SPF was handled. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 May 2015 16:47:29 -0400

Hi Terry,

No one ever proposed an open-ended user access to DNS or APIs that 
access the backend, server side files.  No, thats a clear security 
threat.  As a design rule of SE thumb, you MUST never give normal 
and/or unregulated users access to system level operations.  That is 
typically reserved for system operators and administrators, "gods" of 
the system.  A compromised system, an inside job, bad guy got in, 
would be the #1 security threat as it always is for anything else.

When it comes to hosting, a customer with one domain has the same SMTP 
and mail hosting functional and technical operational needs and 
requirements that a customer with a million domains.   If you have a 
problem, its a bug whether its small, mid, large and operate 
privately, publicly or mixed with its domains.  That is how I've 
designed hosting products that is for all customer types.

For this application need, how one registers domains is entirely up to 
the domain including not registering at all as a corporate policy. 
Thats a product feature.  It SHOULD also be a product feature that 
domains MAY register resigner domains in DNS for the purpose of 
performing domain authorization queries.

Either way, its a feature to have for those who can do it and many 
customers will have the ability to handle their delegation of 
resigners using DNS.  If one of your domains has a tougher problem 
with it, then you can't do it, period.  That is why microsoft.com has 
an SPF hardfail but the other microsoft property public service 
domains do not.

Let me ask you this, if you implement the conditional @fs method for 
your MLM,, are you going to honor the restrictive policies of incoming 
domains, those who will not want to have resigners of any kind and 
will not use the conditional @fs method themselves (no need)?   Will 
you honor this rejection policies at the MLM, and in reality, across 
all Microsoft domains receivers?

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Sat, 09 May 2015 14:44:42 -0700

> I'm having trouble coming up with a heuristic that is even certain to grab

Dear Murray,

I'll create another DKIM extension to implement required
replication of header fields for third-party domains.  This
can be implemented by just those originating the messages
AND those implementing DMARC.  Most mailing lists should not
be impacted by the required header field approach, but this
should remove a presumed need for yet another DKIM
signature.  I will have the DKIM extension draft published
shortly. 

Also, you seem to dismiss a sizable corpus of DMARC feedback
that can be verified by recent outbound logs. Of course only
a DMARC domain imposing restrictive policies will have any
need to implement this scheme which they should also see as
their obligation if they have any desire to have their
policy requests used.  That said, the update to DKIM should
be able to simplify what is contained in TPA-Label.

Together, these methods only require implementation by the
sender AND those imposing restrictive DMARC policy.

Regards,
Douglas Otis

---

From: Anne Bennett <[email-masked]>
Date: Sun, 10 May 2015 01:33:48 -0400

Hector,

> Do you mean "-ALL" hardfail policy?

Yes, sorry.

>>        my domain, then submit mail through another provider.

... for which I think the correct solution is SMTP AUTH to *my*
relay.

> 5322.From is not SPF related.  You mean the 5321.MailFrom?

Yes, the SMTP "MAIL FROM".  Sorry again.

> A simple relay, sure, SPF has that problem you will only see 
> for -ALL policies.

[...]

> "checking" to see if it exist.

Certainly a protocol could be defined with "apply local policy here,
and return ACCEPT or REJECT based on the results", and from the point
of view of a protocol, that works and is implementable.  We already
have that with SMTP, where we can return "550 Get lost spammer" if we
wish, based on whatever heuristics or rules we like.

But I thought the point of DMARC was to determine reliably
(using cryptographic keys and/or IP addresses as published by
the alleged originating domain in the DNS under their control)
whether the domain in the "From:" header is really responsible
for originating a given message, and I thought the problem
we're trying to solve here is how we can prevent DMARC from breaking
"mediated" mail (such as mailing list mail).

So far our options seem to be:

  - Pass the mail through entirely unmunged, to avoid invalidating the
    DKIM signature - which means giving up features that have been
    useful on mailing lists for decades,

  - Munge the "From:" header to have the mailing list "take ownership"
    of the message, at least for messages sent by users in p=reject
    domains - which is already implemented as an option in at least one
    major MLM, but is not popular philosophically (because people
    expect the From: line to specify the author of a post) or in
    practice (because it makes it harder for the recipient to choose
    to reply to the list or to the original sender as they wish),

  - Come up with a scheme allowing the mailing list to "re-sign"
    a slightly munged version of the message, which is what
    I think we're arguing about.

The apparent problem is that a spammer or fraudster or malware
propagator can do to a message anything a mailing list can do.  There's a
suggestion that if legitimate mailing lists can somehow be identified
(the "registration problem"), all will be well.  If I can summarize
my understanding of the argument so far, some people are saying "apply
heuristics to the registration problem, that should take care of things
well enough", and others are saying "no, no, no, we had a deterministic
thing of beauty with DMARC, you mustn't wreck it with non-deterministic,
implementation dependent heuristics".

Well, I myself wouldn't call something a thing of beauty when it
wrecks the functioning of mailing lists when used as intended, but I
also think it's pointless to try to specify a protocol that allows for
implementation-dependent heuristic decisions to "solve this problem".
Any e-mail provider can already arbitrarily decide to ignore DMARC for
mail they think is list mail, if they want to.  Sure, then they couldn't
call themselves "DMARC compliant", but who would lose sleep over that?
Honestly, are Google and Yahoo competing for each other's e-mail users
by advertising that they're the best because they're DMARC compliant?
Perhaps I'm naïve about the politics of all this (actually, that is
certainly the case!), but I suspect that almost all sites, especially
the big ones, do as they please.

If I can step back a bit, all DMARC does is ensure that the site in
the "From:" line signed (or, via SPF, transmitted) *this* message.
A malefactor can send DKIM-signed or SPF-approved messages as easily as
anyone else.

Some of the proposed solutions involve a mediating site making
modifications, and signing its specific modifications.  A malefactor can
do that too, of course, but is this really any worse than the original
situation?

A receiver doesn't stop checking a message after it passes DMARC as
currently specified, because it may be that the site @spammer.com is one
whose messages we don't want, or it may be that [email-masked]
had his account phished and is suddenly sending trash.

A receiver wouldn't stop checking messages after the munged and
re-signed version passes a "new DMARC", for the above reasons *and*
because it might not want messages from "@spamlists.com", or because
"[email-masked]" could sometimes pass a bad message.

Nothing about DMARC or DKIM states that a message is okay - that part
is checked by other (yes, heuristic) parts of the mail system.
Nothing about an expanded DMARC or DKIM with "re-signing of
modifications" needs to be construed as stating that a message is
okay.

Hmm, Hector, I think you've forced me to convince myself that you're
on the right track: I think that the "registration problem" is a red
herring after all.  There's no deterministic way to decide what's a
legitimate mailing list (or other re-signer), any more than there's any
way to deterministically decide what's a legitimate originator.  Those
determinations are made heuristically outside DMARC.

Meanwhile, DMARC (and potentially an expanded "re-signing" version)
can verify only the authenticity of the originator (and of the
re-signer), and thus the authenticity of the original message (and of
the modifications), which is still useful.

> Nothing. :)

... except a copy editor.  ;-)

Anne.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 May 2015 02:01:43 -0400

> determinations are made heuristically outside DMARC.

If that's the case, we're done.  Large providers already do this reasonably 
well.  

I think you've got it backwards.  There's no deterministic way to determine 
what's a legitimate mailing list, so any solution that insists you do so, it's 
feasible.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 9 May 2015 23:07:31 -0700

> determinations are made heuristically outside DMARC.

Numerous proposals have appeared over the years to solve the Mediator
problem and its ilk, all of which involve advertising in some way that two
domains are related somehow.  The favorite example is "A can sign B's
mail", with the implication being "and you should act as if B signed it".

There are several problems with an approach like this:

1) The favorite way to advertise and check this is DNS.  There are several
arguments about why this needs to be avoided, so doing it again always
draws them out again.

2) There isn't a nice way so far to do this at other than the domain
level.  That means any actor inside "A" can sign mail that claims to come
from "B".  So if "A" is compromised, "B" is hosed.  The "B"s of the world
tend not to be so thrilled with this.

3) Very large operators have millions or even billions of users.  For "A
can sign B's mail" to work, the set "A" for those operators is potentially
enormous.  (I think Yahoo quoted numbers well into five figures.)  The "B's
of the world tend not to be thrilled with this at all either, because every
domain in the set "A" is a potential exposure.  How do we populate the
set?  Either we do it (a) heuristically, because as you said it's not
deterministic; (b) via a central authority (trusted by whom, exactly?); or
(c) by letting the users of "B" populate it (which is obviously, one would
hope, a huge abuse vector).

This "How do we populate the set?" is "the registration problem".  There
are some implicit "safely" and "at scale" adverbs in there too, just for
flavor.

So suppose you come up with a heuristic that works for you.  It reliably
(magically?) adds a domain to the set "A" when a user at your domain
subscribes to a list operated by a mediator within that domain, and
reliably (magically?) removes it the minute all such relationships with
that domain are broken.  You are still faced with (1) and (2) above.

Moreover, the magic you have to come up with would presumably watch your
incoming and outgoing mail looking for things that look like lists, and
update "A" when such are observed.  Now I'm a Bad Guy(tm).  I want to be
able to send people mail that they believe is at least endorsed by you.  I
send mail to a random user at your site that looks like list traffic coming
from BadGuyDomain.com.  Your heuristic adds that domain to "A" because you
don't want to mess with that user's list experience.  Voila, I am now able
to phish as you.

So yes, DMARC doesn't necessarily need to spell out a solution to the
registration problem.  But that's not the issue; the concern is whether
endorsing a solution that requires a registration step, regardless of how
it's accomplished, is a pragmatic thing to pursue in the first place.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 9 May 2015 23:14:07 -0700

> determinations are made heuristically outside DMARC.

I suppose the tl;dr version of my last reply is:

The registration problem is not a red herring because it doesn't exist, but
because it is intractable.  Thus, any response to the third-party problem
that relies on a solution to that problem (which includes ATPS, DSAP, and
TPA) is probably not viable.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Sun, 10 May 2015 06:29:28 +0000

> The registration problem is not a red herring because it doesn't exist, but because it 
> is intractable.  Thus, any response to the third-party problem that relies on a solution 
> to that problem (which includes ATPS, DSAP, and TPA) is probably not viable.

+1.

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Saturday, May 9, 2015 11:14 PM
To: Anne Bennett
Cc: [email-masked]
Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note

On Sat, May 9, 2015 at 10:33 PM, Anne Bennett <[email-masked]> wrote:

I suppose the tl;dr version of my last reply is:
The registration problem is not a red herring because it doesn't exist, but because it is intractable.  Thus, any response to the third-party problem that relies on a solution to that problem (which includes ATPS, DSAP, and TPA) is probably not viable.
-MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2015 10:04:33 -0400

On 5/10/2015 2:14 AM, Murray S. Kucherawy wrote:
> On Sat, May 9, 2015 at 10:33 PM, Anne Bennett <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> The registration problem is not a red herring because it doesn't
> exist, but because it is intractable.  Thus, any response to the
> third-party problem that relies on a solution to that problem (which
> includes ATPS, DSAP, and TPA) is probably not viable.

Thats a fine opinion, but you have no evidence to show whether it was 
possible or not because the efforts to do were crippled or hampered by 
other focuses.  Brush off work, crippling it should not be used as 
evidence of lack of traction or difficulty in publishing records.

Besides the trust focus during DKIM-WG, ADSP was being down played and 
the MLM was encouraged not to support it. With the level of demotion 
that existed primarily because of its conflict with the MLM, it was 
hard to imagine anyone that wasn't nimble and flexible to support it. 
  It wasn't complete. It was all in pieces.

But you replaced ADSP with DMARC and when you did so, you didn't 
update ATPS to work off DMARC where it was suppose to be at.  So that 
was the proper next step.  It isn't an equal situation until then.

Now you got DMARC support -- meaning, RECEIVERS are doing the lookup 
for these records and actually honoring the rejection policy.

Therefore, ATPS-rev04 should be updated for DMARC or revert rfc6541 to 
make it work off the DMARC record.  Then maybe the Yahoos will *think* 
about it, because they would have a choice to do so. When ready, they 
can add simple tag(s) to DMARC:

      [atps=y; [atpsh=hash-method;]]

All optional and give the receivers a simple choice to look it up:

     if dmarc["atps'] == "y" and author is not the signer then
        do a atps(author, signer) lookup

That's the optimized solution.  At this point we don't really need the 
dmarc "atps=y" signal.  We can use use the idea that the author does 
not equal the signer.

I would like to see ATPS-rev04 resurrected with the DMARC optimizing 
hook or off the mismatch of author and signer.

-- 
HLS

---

From: Anne Bennett <[email-masked]>
Date: Sun, 10 May 2015 10:05:09 -0400

Murray,

>> I think that the "registration problem" is a red

> problem and its ilk, all of which involve advertising in some way that
> two domains are related somehow.  The favorite example is "A can sign B's

Ah, okay; in that case I will respond to your summary:

> third-party problem that relies on a solution to that problem
> (which includes ATPS, DSAP, and TPA) is probably not viable.

I agree.

But I think that some of the "re-signing" schemes being proposed at
the moment do *not* require this type of registration, so in those
cases, the registration problem wouldn't apply.  If A is not "signing
B's mail", but rather, "signing its own modifications to B's message",
then the evaluation of the two signatures doesn't require a published
or pre-existing relationship between the two domains.

Under at least one of the proposals, it can be determined that "yes, A
signed the mods, and if the mods are removed to re-generate the original
message, B signed the original message".  If we have that, then I think
the question becomes: if this is to be a DMARC-like scheme, how do we tie
A's signature to some kind of relevant header field, since the "From:"
header is already "reserved" for the original signer.

Now despite injunctions on this list against referring to the user
interface, the fact is that DMARC uses the "holy From: header" to extract
the "alignable domain".  Unless I'm gravely mistaken, the reason for
that *is* indeed that this field is shown to the user (in some form)
by every user agent out there, and the user is thought to place a fair
deal of confidence in the "truth" of that header.  Unless we can state
something similar with respect to another header, I suspect that
anything we propose will be considered to be watering down DMARC to an
unacceptable extent.  :-(

Anne.

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2015 10:37:40 -0400

Scott,

MARID got started when Microsoft introduced CEP, the XML version of 
SPF.  As an early explorer before MARID, I supported CEP as well as 
most of the LMAP ideas such as DMP which predated SPF.
LMAP was a framework for an IP Domain Association protocol; LMAP = 
IP::DOMAIN and we had the same resistance and arguments about 
complexity, DNS management issues, false positive, DoS issues, 
overhead and waste issues, name it, the same arguments.

Yet, you pleaded to consider the small guy and not allow "complexity" 
to not hamper progress.

    http://www.imc.org/ietf-mxcomp/mail-archive/msg02197.html

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2015 11:53:31 -0400

> or pre-existing relationship between the two domains.

The signers still needs a "database" to determine when to add the 
double signature and the MLM receiver still needs to support the 
detection of this in order to allow it or not if missing.

IOW, the MLM receiver still needs to reject the MLM submission and the 
final receivers still need support it as well otherwise the bounces 
will still occur that causes automated unsubscribe problems. So no 
matter what, the MLM still needs to support it.

- Signer needs to know when it double signs,
- MLM receiver filters restrictive domains, allows double signers, 
resigns doubles.
- End-User Receivers support the resigned double signers.

So there are changes at three places with a registration concern as 
well.  At best, with the alternative to the DNS lookup, you have done 
two things;

    - got the DNS administrator out the picture and
    - maybe less endorsement requirement from the DNS community.

But it comes with a higher risk of security problems -- potential, 
theoretical. Doesn't mean it can happen and probably a way to get 
around that too, for example, its possible to have a double From: exploit:

    From: user1@domain1  <----  unprotected, unsigned from
    From: user2@domain2  <----  hash bound DKIM protected

If the MUA displayed the first one, you have fraud, phishing 
potential, etc.  We addressed that by making it a responsibility of 
the receiver to check for a valid RFC5322 first.   But DKIM should 
also check it too just in case the MTA doesn't check it.

Doing a munge of the 5322.From is a old industry taboo. If any system 
does it, to me, and strongly believe many of my industry peers as 
well, they are renegades, no control and liable to legal issue. I 
wouldn't trust them.  Its an ethical thing and I would probably appeal 
any recommendation to do so within an IETF mail protocol document. 
Its the same exploitable idea of a Double From and it will probably 
encourage filter writers to seek out a From Munged transaction 
detection strategy and immediately reject it.

Now we are creating wars when you do that and the IETF should not 
encourage such mail matters.  From Munging SHOULD NOT be an 
recommendation coming from the IETF.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 11 May 2015 00:55:22 +0900

Scott Kitterman writes:

 > Yahoo, for example, already consider the impact of this and other
 > breakage to be less than the benefit of p=reject.

True, but the benefit of p=reject is huge: Yahoo! claims malicious
mailflows of more than a million messages per minute disappeared like
magic when they published p=reject.  Such a flow surely stressed their
systems, and I'm sure they consider the potential for high losses due
to contact-list-based phishing to be important, if only for the damage
to their reputation that would ensue.

 > I expect their willingness to invest engineering resources in
 > further reducing a level of breakage they've already determined is
 > acceptable will be limited.

Of course it's limited.  But the only cap I can be sure of is the
difference between benefit of p=reject (see above) and cost (1 day of
manager-admin meetings to decide to do it, and 15 seconds of admin
time to change the DNS record, ie, basically zero).  I believe that
difference to be orders of magnitude larger than the cost of
implementing a dozen delegation protocols, and therefore irrelevant.

What matters is the benefit that the p=reject domains perceive to
improving service to their mailbox users.  I have no information about
that.  Of course I suspect that the value to them of such improvements
is close to nil, but until they actually say that, I'm going to hope.

If you have better information about how much they value such
improvements, I'd love to hear about it.  But I rather doubt you do;
the techs surely don't have the authority to say they will do it, and
at best a guess of what they need to offer management to get
permission, and management won't discuss the value of a bird in the
bush (not if they have half a brain amongst them, anyway).

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 May 2015 12:48:13 -0400

>bush (not if they have half a brain amongst them, anyway).

I don't have any particular insight. I do think that the group ought to be paying close attention to those who do.  As I attempted to communicate in my assessment framework proposal, whatever solution the group coalesces around has to be workable for entities from the largest to the smallest. 

I think we have three outcomes:

1.  We develop something that's broadly deployable

2.  Single actor approaches such as from rewriting dominate the solution space

3.  Mediated mail communication becomes rare

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 May 2015 16:53:45 -0000

>header is already "reserved" for the original signer.

You don't even need to be able to tell what part of the message is
attributable to which party.  All you need to know is that the first
signer considers it to be close enough.

Remember the key axiom of mail reputation: you cannot say good things
about yourself, only neutral or bad things.  (This should be obvious
if you think about it for a moment, since any assertion a nice sender
can make, a nasty sender can also make.)  Good stuff has to come from
trusted third parties, and given the difficulty of establishing trust,
that means the number of third parties has to be small.

Hence DMARC answers the question "is this a bad message?" It only
tells you whether a message is so awful that the recipient should
throw it away.  Once it's passed that test, the recipient then does
whatever it does with any other mail to decide how spammy it is and
what to do with it.* If the SPF or DKIM identity happens to belong to
someone the receiver likes or trusts, that's fine but it has nothing 
to do with DMARC.

That means that if a message has passed through two entities or
mediators or whatever, the recipient does not care what part of the
message originated where because it's going to deliver or reject the
whole message, not the individual parts.  If my MTA gets a 419 from a
mailing list, it doesn't care whether the list is leaking 419s from
the original sender, or the list is 419-izing innocent mail.  It's
going to bin it either way.

That's why I made my double signing proposal the way I did, it's just
enough that the original signer can say, yeah, close enough.  The
other more complex proposals can tell the recipient lots of other
stuff, but it's not stuff that is useful to the recipient (except
perhaps for exotic forensic purposes) so there's no value to the
extra complication.

R's,
John

* - someone will probably disagree with this, but he is wrong

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 11 May 2015 02:05:55 +0900

Anne Bennett writes:

 > >> aware of all

"All" has been asserted.  Why it needs to be "all" has not been
explained, and when I ask that question, the response I get is
"because I don't think you can get close to 'all'".  (I expect the
next round to go "So, why do we need to get 'close to "all"'?"
"Because I don't think you can get close to 'close to "all"'.  Young
man, you are very clever, but it's 'can't get close to' all the way
down!" ;-)

 > >> of the "legitimate" (definition purposely left

[...]

 > for originating a given message,

It's only half-reliable.  A DMARC pass is reliable per protocol.  A
DMARC fail is 100% unreliable (SHOULD NOT be considered to provide any
new information that isn't available outside of the DMARC protocol).

 > and I thought the problem we're trying to solve here is how we can
 > prevent DMARC from breaking "mediated" mail (such as mailing list
 > mail).
 >
 >     expect the From: line to specify the author of a post)

It's worse than that.  RFC 5322 (like all of its predecessors)
*specifies* that the content of the From field is the author's mailbox
(or authors' mailboxes) and optionally name(s) or other description.

 >     or in practice (because it makes it harder for the recipient to
 >     choose to reply to the list or to the original sender as they
 >     wish),
 > 

 > implementation-dependent heuristic decisions to "solve this

"Legitimate" is always heuristically determined by the receiver, as
you argue below.  So people who argue that policy should be an
absolute determinant of disposition just don't use the same Internet
the rest of us do.

 > mail they think is list mail, if they want to.

That doesn't help.  To solve the problem lists face, *all* recipients
*must* ignore DMARC.  Otherwise subscribers at domains that *do*
respect p=reject get their bounce counts increased while not receiving
desired mail.

 > Sure, then they couldn't call themselves "DMARC compliant", but who
 > would lose sleep over that?

Nobody, since they *can* call themselves conforming as long as they
report.  Accepting mail from a p=reject domain that fails the From
alignment test is explicitly permitted (with "MAY").

 > A malefactor can send DKIM-signed or SPF-approved messages as easily as

And in fact, any malefactor can send from Yahoo! or AOL, and get those
domains to sign their messages.  It's more difficult, but they can
even send malicious mail "From" those domains, which will be signed if
it does escape the outgoing filters.

 > modifications, and signing its specific modifications.

We already do sign messages, although in most cases it is not possible
to identify the specific modifications with current protocols.  I am
sure that many large providers already maintain reputation databases
for quite a few mailing lists, and those signatures help get our mail
through to their mailboxes.

 > herring after all.

It's not a red herring.  Identifying lists and other frequent senders
of indirect mail, and only authorize resigning by those who pass
further heuristic tests for "legitimacy", is an useful heuristic.
Without a plausible approach involving reasonable cost to generating
such a list, delegation protocols won't fly.

I just don't think solving the "registration problem" should be a
blocker for developing a delegation protocol, because the List-Post
heuristic is a good start for any size of domain.  I'm sure the large
domains can do *much* better for themselves, and for smaller domains
we can help develop substantial improvements, including sample
implementations in software.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 10:24:59 -0700

> that means the number of third parties has to be small.

This is an interesting observation when compared to DKIM and SPF, where you
only actually know something about the message when they report a "pass".
But that's authentication, not reputation.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 10:37:06 -0700

> or pre-existing relationship between the two domains.

Yes, exactly; re-signing in some way that is entirely self-contained (i.e.,
does not mandate further queries to establish a relationship between A and
B) appears to be far more promising than anything requiring a registration
component.

The theory behind some of my proposals tries to extend the basic notion of
DKIM, which "allows a domain to take some responsibility for a message";
the idea in the extensions is to allow the different actors to claim
responsibility for different parts of the content, and let the receiver
decide what to do with that additional information.  You allude to this
here:

> header is already "reserved" for the original signer.

In general, what you're hoping to do is confirm a relationship between A
and B.  A system involving a registration scheme seeks to query a registry
for such relationships.  The favorite way to do this is the DNS of B, where
the set A would be published somehow.  These other re-signing methods (and
their variants) are seeking to confirm this relationship via two signatures
that are somehow associated.

That is, for a registration scheme, you might be testing for the existence
of a DNS record called A._related._dmarc.B.  For a re-signing scheme,
you're looking for a signature from A that is somehow endorsed (for some
definition thereof) by a signature from B.  The beauty of that mechanism is
that the signer gets to decide when to apply that endorsement, and with
what parameters.  In fact, it's possible that A doesn't even know that B is
doing it.  B could do it for all messages, which is simpler but increases
exposure; it could decide to apply the aforementioned heuristics and only
include the endorsement when it feels it's appropriate, which is safer but
requires a lot more internal infrastructure to support.  Both camps are
enabled.

> anything we propose will be considered to be watering down DMARC to an

I agree with both your context and conclusion here.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 11 May 2015 02:40:34 +0900

Murray S. Kucherawy writes:

 > That means any actor inside "A" can sign mail that claims to come
 > from "B".  So if "A" is compromised, "B" is hosed.  The "B"s of the
 > world tend not to be so thrilled with this.

I think only Hector and Douglas would argue with you, and I predict
they will.  Let's agree to disagree, and move on to something that the
rest of us think might possibly work if we fix a few details.

 > This "How do we populate the set?" is "the registration problem".
 > There are some implicit "safely" and "at scale" adverbs in there
 > too, just for flavor.

Sure, but even with the adverbs it's not a "problem" for per-message
delegation proposals like yours and John's.  For those proposals, we
already have technology in place for incoming messages (eg, Gmail user
filters) which could easily be applied to collect information from
incoming messages (and optionally from the users) and add delegation
fields computed *per user* per *outgoing* message.  It's a *task* with
*costs* that can be estimated, they're not outrageous, and they
provably scale because they're already implemented at scale (for
different purposes).

Those costs may still be too big to be justified by the prospective
benefits, but we need to come to some consensus on protocols and how
much risk of abuse they entail before we can estimate benefits, and
compute benefit/cost ratios.

---

From: "John Levine" <[email-masked]>
Date: 10 May 2015 17:42:58 -0000

>> about yourself, only neutral or bad things. ...

>But that's authentication, not reputation.

Right, the assertion is "this is me" which is neutral without
something else to decide what you think of me.

I find that between the axiom and your observation that third party
trusted entities do not scale, you can pretty quicky tell whether a
proposed hack is likely to be workable.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 10:44:00 -0700

> compute benefit/cost ratios.

Right, that's also a benefit of the dual signature approaches: the decision
can be made based upon the characteristics of each message, in theory,
where having to consult with a registry via the DNS implies the
relationship is established for all mail.  In the resigning methods, the
registry, if one even exists, is completely internal and detached from the
protocol.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 11:00:00 -0700

> requires a lot more internal infrastructure to support.  Both camps are

Sorry, I sent that too quickly.  A couple of other points:

In both schemes, you need a "registry", which is the set A as maintained by
B through whatever means B wishes.  Any DNS mechanism, however, requires
that all mail flows from B via A are endorsed for as long as that DNS
record is published (or cached); with the re-signing scheme, B gets to
choose which specific messages carry that endorsement, via whatever logic
it cares to apply, and for how long the endorsements are effective, and
with what cryptographic strength and other parameters.

We have evidence in hand that the queryable registry solutions are not
attractive, evidence in the form of ATPS (RFC6541) for which the adoption
rate was above zero by only a vanishingly small amount despite three years
of open publication and an open source implementation.  Despite other
claims, there has never been evidence shown of interoperability of ATPS.
The posting at the top of this thread makes such a claim, but it describes
a single pre-RFC implementation interoperating with itself, rather than
distinct implementations interoperating together; it is the latter that we
tend to consider probative in IETF work.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 11:04:13 -0700

> proposed hack is likely to be workable.

A re-signing scheme also has to have some mechanism for deciding which
third parties get the endorsement ("@fs=") from the author domain.  One
might think of that as a "registry" with similar problems to those we've
been discussing, but it's just an entirely private one.  So I'm not sure we
can plainly say registries are off the table, because you always have to
have some way to decide whether to affirm the relationship.  It's a matter
of the method by which you do so.

But in your case, that registry doesn't need to be published anywhere; it's
implicit in the signature parameters, and is much easier to control
tightly, because it's per-message, and DKIM has a lot of parameters to play
with.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 11 May 2015 03:18:22 +0900

Scott Kitterman writes:

 > I don't have any particular insight. I do think that the group
 > ought to be paying close attention to those who do.

What is the sound of a closed mouth speaking?

 > As I attempted to communicate in my assessment framework proposal,
 > whatever solution the group coalesces around has to be workable for
 > entities from the largest to the smallest.

I think that's very desirable, but to me it's not obviously a
blocker.  That's my current opinion, I'll think about it more.

 > 3.  Mediated mail communication becomes rare

In 1, s/we/somebody/, and I agree completely.

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2015 14:33:50 -0400

> On May 10, 2015, at 2:00 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
>> On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy <[email-masked]> wrote:
>> That is, for a registration scheme, you might be testing for the existence of a DNS record called A._related._dmarc.B.  For a re-signing scheme, you're looking for a signature from A that is somehow endorsed (for some definition thereof) by a signature from B.  The beauty of that mechanism is that the signer gets to decide when to apply that endorsement, and with what parameters.  In fact, it's possible that A doesn't even know that B is doing it.  B could do it for all messages, which is simpler but increases exposure; it could decide to apply the aforementioned heuristics and only include the endorsement when it feels it's appropriate, which is safer but requires a lot more internal infrastructure to support.  Both camps are enabled.
> 
> In both schemes, you need a "registry", which is the set A as maintained by B through whatever means B wishes.  Any DNS mechanism, however, requires that all mail flows from B via A are endorsed for as long as that DNS record is published (or cached); with the re-signing scheme, B gets to choose which specific messages carry that endorsement, via whatever logic it cares to apply, and for how long the endorsements are effective, and with what cryptographic strength and other parameters.
> 
> We have evidence in hand that the queryable registry solutions are not attractive, evidence in the form of ATPS (RFC6541) for which the adoption rate was above zero by only a vanishingly small amount despite three years of open publication and an open source implementation.  Despite other claims, there has never been evidence shown of interoperability of ATPS.  The posting at the top of this thread makes such a claim, but it describes a single pre-RFC implementation interoperating with itself, rather than distinct implementations interoperating together; it is the latter that we tend to consider probative in IETF work.

First, ATPS was hampered by the fact ADSP was being demoted.

Second, RFC6541 raised the barrier by extended it off the DKIM signature.  We were already tired of more changes to DKIM, we did not need more.  Instant barrier to adoption.

Third,  ATPS was an experiment and the author was included stuff, "it won't work anyway".   It can't do that.  Doesn't help the  technical marketing.  It doesn't.

So yes. It was poorly proposed in my opinion,  but it was understandable given the focus to use thrust rather than policy.
 
But we can't compare the situation because now you have interest in a "Super-ADSP" [sic], which mean the 3rd party hook off DMARC should of be the proper integrated step.

FInally. It is running code between different operators and the IETF take it into account. Which means I can send mail to a list, expected it to be resigned and my own system and others can do the lookup for the resigner authorization.   You forget that a system can support it for authorization  but does not itself need or can publish records.

In all, all your points and my points should be part the interoperating report but I totally disagree it is not an overall IETF technical protocol feasible solution.  It will probably never be a feasible solution for the limited domains in question, no matter what is done.  But that should not stop the protocol from being part of the DKIM policy layer.  It didn't stop any other similar DNS application.   Now,  If we are trying to avoid the intense IETF  DNS community review sure to follow, I can see a valid point, but avoiding it is just as bad.  I suggest that a proper DNS lookup model is still the proper most feasible solution and that will be presented during review.  At some point we need to stop the DKIM changes.  You just made it a STD.  Maybe we could probably retract that STD status with and addendum if it a going to continue to change.

---

From: "John R Levine" <[email-masked]>
Date: 10 May 2015 15:54:21 -0400

> of the method by which you do so.

Yeah.  I think there's a general rule in there, but it's subtle.  It's 
clear that a whitelist that resenders sign up for won't work, largely 
because any such list big enough to be interesting is also big enough to 
have entries that don't belong on it (Marx' Rule, see *).  It's less clear 
what the rule should be for private white or other lists.

For the current question of a private list of mailing lists that get 
special treatment on outgoing mail, it still seems to me that small 
systems can just allow double signing for everything, and large systems 
can come up with a pretty good list of their own from a combination of 
their own incoming mail and the DMARC aggregate reports.  The reports will 
tell you what IPs are sending mail with a combination of your own DKIM 
signature (valid or broken) and a second signature, so if a host is doing 
that, and the IP's reputation is not awful, the second signature is an 
excellent candidate for that list.

I have about 35,000 aggregate reports here, should do a little data mining 
and see how well it works.

R's,
John

* - http://www.brainyquote.com/quotes/quotes/g/grouchomar122546.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 May 2015 17:38:54 -0400

On 5/10/2015 3:54 PM, John R Levine wrote:

> systems can just allow double signing for everything, and large
> systems can come up with a pretty good list of their own from a
> combination of their own incoming mail and the DMARC aggregate
> reports.  The reports will tell you what IPs are sending mail with a
> combination of your own DKIM signature (valid or broken) and a second
> signature, so if a host is doing that, and the IP's reputation is not
> awful, the second signature is an excellent candidate for that list.
>
> I have about 35,000 aggregate reports here, should do a little data
> mining and see how well it works.

I agree.

Small systems can manage their DNS resigner management. Generally, the 
Mail/DNS team are the same folks.  Larger systems do have the mail 
reporting data and SMTP rejection signals with the programming 
resources and tools to come up with up with administrative system 
scripts, including creating/updating zone files, if allowed.  It can 
be prepared it so it is readable by the DKIM signer engine.  It 
doesn't have to be done via the DNS protocol but it can certainly by 
managed as well.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Sun, 10 May 2015 16:37:24 -0700

On 5/10/15 11:00 AM, Murray S. Kucherawy wrote:
> of open publication and an open source implementation.
Dear Murray,

ATPS included an onerous task for any third-party service
likely used on a gratis basis. Each third-party was expected
to learn specific hash algorithms of each From domain.  A
difficult process on top of changing their structure of DKIM
signatures repeated tens of thousands of times for each
different first party domain. In addition, reputations based
on the third-party relationship could not be leveraged
because of the optional hashing.

Very close to what is likely to become yet another signature
scheme.  At least John's scheme does not have third-parties
guessing about parameters needed in new signatures. 
Guessing based on an option that should have never been
allowed.  ATPS self imposed two monstrous hurdles avoided by
TPA-Label.  DMARC signaling easily supplants rationale used
by ATPS to justify its new DKIM signature.

Even an alternative of having a DMARC domain adding limited
signatures replayed by third parties where the entire
message body can change along with selected header fields. 
People need time to respond and to then receive a subsequent
posting.  A period likely longer than many days.  I just
responded to a posting on another list about a week after
the initial posting.  There are only so many hours in a day.

In the event of a limited signature scheme becoming
exploited, what response is available to the DMARC domain? 
Wait for the x=parameter to timeout?

I will propose a scheme similar to John's limited signature
that includes a means to revoke implied authorizations based
on detected abuse.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 10 May 2015 22:08:12 -0700

> because of the optional hashing.

I continue to find this repeated claim specious at best.

Section 7 of ATPS describes the structure of the experiment and invites
feedback from anyone who tries it.  Apart from Hector's recent declaration
and one hobby user of my open source implementation that enabled it, there
has been no feedback from the community at large that anyone has tried it
or any variant of it.

Given the pain point that a widely adopted authorized third-party
signatures scheme (in general, not just RFC6541) would solve, one would
think we'd have heard something in this regard in the last three years.
Nothing beyond what I just mentioned has materialized.

If you intend to claim that this is because of specific aspects in RFC6541
of how the DNS records are generated, I suggest you consider that even
small operators don't have a problem computing hashes or populating DNS
zones, because computers are good at automating things.  Even if they did
see those things as burdens, such operators tend to be the sort to provide
that kind of feedback even about a protocol they ultimately can't use.
Seriously, what person in the email space that you've met in the last N
years would not take an opportunity to provide feedback, constructive or
otherwise?  We are a rather opinionated bunch and love the sounds of our
own voices.  Someone would've said something by now.  But it hasn't
happened.

TPA has existed even longer than ATPS has, and it has enjoyed similarly
goose-egg-shaped amounts of adoption.  DSAP was around even before that,
and the story is the same.  What they all have in common is that they are
not even close to something that serious operators would be willing to
try.  They are plagued by -- you guessed it -- the registration problem.

Absent a change in that posture by the community at large, this is
manifestly a dead end, and we really, seriously, need to stop burning any
more of our precious cycles on it.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 May 2015 08:14:38 -0400

I don't think it correct to be implying "we gave it an old college 
try" when in fact, everything was being done to kill policy ideas.

Murray, Crocker and Levine where the key IETF cogs working on the DKIM 
project and all three were pushing a Trust Model, removing the author 
domain from the picture and in fact, militantly refused to even define 
the author identity in the DKIM-BIS work which became a STD.   Levine 
was advocating the receiver do not support ADSP and therefore 
alleviating the MLM problem.  Levine refused to update ADSP.   At this 
point, proposing ATPS, well, anything related to POLICY, it was pretty 
much too late at this point. ADSP was dead. ADSP was abandoned in the 
DKIM-WG.

But as I said, the different now that DMARC replaced ADSP.   You got a 
whole different set of application users here that desperately need a 
wide policy solution.  You made that happen but you didn't complete 
the job of making ATPS work off DMARC.  So you left the holes there.

Instead, you made ATPS work off DKIM and that was yet another instant 
barrier to adoption. It was like, "lets do this, but lets make it hard 
to do."  It was pretty a given that it wasn't going to work.

Now you have an opportunity to finally see if this going to work 
because the focus is with DMARC.  You didn't have that POLICY focus 
before.  It wasn't there.  Until you do, you are going to continue to 
have this powerful proof of concept hanging over DKIM.

If you updated ATPS to make it work off DMARC, and it doesn't get 
traction now, I will retire from the DKIM project.  I put a huge 
investment into a commercial DKIM/ADSP/ATPS project and the rug was 
pulled from under me when you pushed to abandoned ADSP.  I am trying 
to replaced ADSP with DMARC as you want and that includes having the 
ATPSrev4 piece.   It works.  Thats a given.

You got to do it right.

-- 
HLS

On 5/11/2015 1:08 AM, Murray S. Kucherawy wrote:
> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Section 7 of ATPS describes the structure of the experiment and
> invites feedback from anyone who tries it.  Apart from Hector's recent
> declaration and one hobby user of my open source implementation that
> enabled it, there has been no feedback from the community at large
> that anyone has tried it or any variant of it.
>
> signatures scheme (in general, not just RFC6541) would solve, one
> would think we'd have heard something in this regard in the last three
> years.  Nothing beyond what I just mentioned has materialized.
>
> If you intend to claim that this is because of specific aspects in
> RFC6541 of how the DNS records are generated, I suggest you consider
> that even small operators don't have a problem computing hashes or
> populating DNS zones, because computers are good at automating
> things.  Even if they did see those things as burdens, such operators
> tend to be the sort to provide that kind of feedback even about a
> protocol they ultimately can't use.  Seriously, what person in the
> email space that you've met in the last N years would not take an
> opportunity to provide feedback, constructive or otherwise?  We are a
> rather opinionated bunch and love the sounds of our own voices.
> Someone would've said something by now.  But it hasn't happened.
>
> TPA has existed even longer than ATPS has, and it has enjoyed
> similarly goose-egg-shaped amounts of adoption.  DSAP was around even
> before that, and the story is the same.  What they all have in common
> is that they are not even close to something that serious operators
> would be willing to try.  They are plagued by -- you guessed it -- the
> registration problem.
>
> manifestly a dead end, and we really, seriously, need to stop burning
> any more of our precious cycles on it.
>
> -MSK
>
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 May 2015 10:04:52 -0400

Murray, a clarification about DSAP.

Of late, I've been using the term DSAP as a general methodology for a 
complete DKIM Signature Authorization Protocol.  DSAP, TPA, ATPS are 
all the basic ideas.  We need a generic term since there are many with 
all the same basic functional principles, but in different syntax 
languages.

However, for the record, there was a 2006 DSAP I-D proposal

    https://tools.ietf.org/html/draft-santos-dkim-dsap-00

that I believe you referred to.  I want to make a clarification above it.

In general, DSAP covered the same policy ideas as with SSP using a 
different language.  SSP covered these polices:

    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

DSAP was more about the protocol methodology covering all the possible 
signature boundary conditions in the Protocol State Machine for two 
signatures; combinations of 1st party with a 3rd party, including the 
lack of the signatures. It described this using two tags:

    4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

    From the viewpoint of the verifier, when a message is received, there
    are two basic pieces of signature information to be of interest when
    analyzing the transaction:

    o  Original Party Signatures (OP)

       *  never expected
       *  always expected
       *  optional

    o  3rd Party Signatures (3P)

       *  never expected
       *  always expected
       *  optional

    When the two signature types are combined, the possible policies are
    listed in this following table:

     +=================================================================+
     | op=         | 3p=        | Domain Policy Semantics              |
     |=================================================================|
     | empty       | empty      | No mail expected                     |
     |-----------------------------------------------------------------|
     | never       | never      | No signing expected                  |
     | never       | always     | Only 3P signing expected             |
     | never       | optional   | Only 3P signing optional             |
     |-----------------------------------------------------------------|
     | always      | never      | OP signature expected                |
     | always      | always     | Both parties expected                |
     | always      | optional   | OP expected, 3P may sign             |
     |-----------------------------------------------------------------|
     | optional    | never      | Only OP signing expected             |
     | optional    | always     | OP expected, 3P expected             |
     | optional    | optional   | Both parties may sign.               |
     +-----------------------------------------------------------------+

                   Figure 4: DSAP Message Signing Policies

But for 3rd party authorization, without a complete satisfactory DNS 
way to do this and a desire to not do another DNS call, a minimal 
smaller scale method was proposed using a "3pl=" record tag:

    4.3.  DSAP Tag; 3pl=<dom-list>;

    The 3pl= is an optional tag that defines a list of 3rd party domains
    who are allowed to DKIM sign the message as a 3rd party signer.  This
    tag is ignored unless 3rd party signing policy is expected or
    optional (3p=always or 3p=optional).

    <dom-list> is a comma delimited list of domain names.

    Example:

    3pl=isp.com,outsource.com,mailinglist.com;

When Doug introduced the TPA hashing idea, it fit the need for larger 
scale needs but it was written too complex.  When you improved the TPA 
idea with ATPS using simple TRUE/FALSE (record exist) semantics and 
also using the same TPA hashing ideas, I implemented ATPS instead.  It 
was just simpler and easier to code, test and explore.

So my implementation of the DKIM policy experiment and exploration was 
with the small scale "3pl" tag now called "asl" for Allowed Signer 
List and the ATPS support for the larger scale DNS lookup:

     [atps=y;] [asl=resigner-domains;]

That was made off ADSP and now off the DMARC record.

It works. DMARC extensions are supported at implementations from a 
parsing standpoint. They won't abort. And for ASL, ATPS supported 
receivers, it works.  As long as you can manage your DNS records, it 
works fine.

I think perhaps what we need to do is step back and think about what 
DMARC should be doing as far as DMARC extension tags to make this all 
optional and available.

I like the SAM idea ("Signer Authorization Method"), Doug called it 
Specific Advisory Method, so a tag that defines the method a signer 
may wish to authorize and I think we have two basic ideas:

    sam=atps      dns lookup (default)
    sam=dsfs      dual signature

I say atps should be default because its the simplest to implement 
without changing dkim engines.

I don't think you should push for Dual Sign method only.

--
HLS

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 May 2015 11:56:44 -0700

> I continue to find this repeated claim specious at best.
Unlike TPA-Label that required NO third-party authentication
method change, ATPS imposed two significant changes onto
third-parties:

1) A need for a new DKIM signature unique for _every_ Author
domain seen by the mediator.

2) A need to determine an _unspecified_ hash unique for each
Author domain seen by the mediator.

Both of these unnecessary and difficult impositions do not
align with those benefiting (the DMARC domain).

This type of misaligned and overly difficult responsibility
greatly impedes adoption where no conclusions can be derived
from a lack of adoption.

Calling these claims specious suggests:

1) Making onerous impositions on third-parties was not the
cause ATPS not being adopted.

How in the heck does one prove that?

> goose-egg-shaped amounts of adoption. 
The TPA label effort was dropped when it looked like ADSP
was not going anywhere.  You picked up the idea and that was
fine, but I warned about a variable hash causing
unreasonable complexity.

The basic concept of TPA-Label remains sound and still
offers a simple way to establish informal federations.

Once someone attempts to offer any sort of delegation based
on DKIM signatures will quickly discover a need to retract
errant authorizations which DKIM can not accommodate.

TPA-Label can operate from a DNS server independent of other
services used by a domain.

TPA-Label places the burden on the DMARC domain (or their
proxy) to indicate to their recipients which of the various
third-party message sources do not abuse their domain. 
After all, only the DMARC domain receives feedback and can
compare it against outbound logs.  Only they represent a
reliable authority.
>  DSAP was around even before that,
That is why there is an offer on the table to allow us to
establish this type of feedback for any large ESP.  It can
be done effectively without becoming onerous.  Really.

Does any large ESP wish to defend public exchanges within
their domain?  Anything that defends open exchange is worth
a few cycles.  If not, DMARC should then offer a policy
profile that includes Sender header field.   Otherwise DMARC
remains non-compatible and is disruptive of desired
interchange as a result.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 12 May 2015 11:17:08 +0900

Scott Kitterman writes:

 > Actually, the idea behind MARID was to come up with a single
 > solution

Is there something we can learn from MARID?  I don't see it in the
context of the current discussion, as MARID had little to say about
third parties (it treated them as first parties, and handled third
party issues by suggesting "certification registries"), and explicitly
disclaimed authentication of authorship claims.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 May 2015 22:33:40 -0400

> disclaimed authentication of authorship claims.

I think the situation is different enough in many respects that there's not 
much to learn from it today.  I mostly responded because I think that if 
people do discuss history, they ought to be accurate about it.

If there's a lesson to be learned it's that the complete lack of existence of 
those certification registries ought to perhaps give pause to those arguing for 
similar things now.  For SPF there was a service for some time called trusted-
forwarder.org, but it never really got much traction.

The reasons MARID was terminated with no output (none of the SPF and Sender-ID 
RFCs were working group products, they were done independently after the 
working group was closed and both were different in important respects than 
what MARID was working towards) were, IMO, entirely non-technical.  I'm 
willing to discuss them if someone wants to chat about history, but not here, 
I think it's off topic.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 00:16:19 -0400

> disclaimed authentication of authorship claims.

MARID main trust was with SPF and CEP (Micrsoft's XML version of SPF 
renamed to SenderID when it was changed to a SPF syntax), but the 
MARID group was open to other proposals to compete with the SPF 
solution.  Those other proposals included:

     - Domainkeys that included a simple always/sometimes sign policy,
     - DKIM, a better Domainkeys with extended third party policies,
     - CSV/DNA, an SMTP EHLO level Reputation Method.

These were the first introductions of the idea for Signature TRUST 
MODEL and the chain of trust which eventually became the main focus in 
the DKIM-WG working group.

But the main focus in MARID was with the SPF idea and there was 
outputs from MARID -- a direction to complete the four RFCs and to 
treat them as experiments:

     RFC4405   SUBMITTER SMTP Service Extension
     RFC4406   Sender ID: Authenticating E-Mail
     RFC4407   Purported Responsible Address (PRA)
     RFC4408   Sender Policy Framework (SPF)

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 00:40:23 -0400

> people do discuss history, they ought to be accurate about it.

You should be careful of accusing me of being inaccurate.  I said 
nothing inaccurate about MARID and the history of SPF.

My point is very simple and its a fact.  You should be very lucky that 
many folks like myself and others argued for SPF even though there 
were much DNS concerns and that included concerns how the larger mail 
providers can resolve IP transition problems and their inability to 
use strong policies that can offer a big payoff in results.  Still to 
this day, most, if not all of the ESP domains, can not use a -ALL policy.

> forwarder.org, but it never really got much traction.

Most people didn't want centralization (yet)-- this was one of the 
outcomes from MARID.

For the record, I am not advocating a centralized lookup.

> what MARID was working towards) were, IMO, entirely non-technical.

There were plenty of outcomes from MARID and the direction to complete 
the RFCs were among them.   SUBMITTER was the first to be completed 
with the first RFC#, the 4405 to 4408 series of MARID generated RFC 
results.

For the public record,  I was pointing SPF did indeed and still does 
have a registration problem the big domains still have.  None of them 
can use a -ALL and if they did, we can expect they will begin to get 
many false positives.   SPF has a higher overhead than DMARC+ATPS 
would have.  SPF has INCLUDE statements which is functionally 
equivalent to a registration concept when it uses this as a means to 
include authorized mail senders.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2015 01:18:15 -0400

>      RFC4408   Sender Policy Framework (SPF)

Don't take my word for it.  Here's the list of active/published documents for 
MARID:

https://datatracker.ietf.org/wg/marid/documents/

[Note to save everyone time, none are listed]

As indicated when the working group closed [1] none of the follow-on 
experimental documents were products of the working group, in fact, deviations 
from what the working group had agreed on were the source of one appeal.

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html

Going back and trying to justify things in this working group based on a 
revisionist history of a decade old failed working group isn't going to get us 
anywhere.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 01:28:54 -0400

> domain seen by the mediator.

It should be off the DMARC record now.

> Author domain seen by the mediator.

Do we really need a hash?  I agree. This required new tools (Hash 
calculators, wizard, command line tools, DNS tools, etc) for DNS admin 
and sysops to be programmed.  Makes it harder to explore.

+1.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 01:44:06 -0400

> revisionist history of a decade old failed working group isn't going to get us

I wasn't revising anything. I lived it, I produced products from it. 
Did you?

Its called Engineering Synergism. Maybe RFC4408 didn't change much 
from the original draft, but RFC4405/6/7 were produced because of all 
of the related discussions in MARID.  How do you think CEP morphed to 
SenderID, PRA and Submitter?

You also had the sparks of getting other ideas moving along like DKIM. 
  The time was not totally a waste and we learned from it. Synergism. 
  There was a direction.

Finally, you seem to forget the IESG Note that was added to all four 
documents.  Skip the link, here it is:

    IESG Note

    The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
    are published simultaneously as Experimental RFCs, although there is
    no general technical consensus and efforts to reconcile the two
    approaches have failed.  As such these documents have not received
    full IETF review and are published "AS-IS" to document the different
    approaches as they were considered in the MARID working group.

    The IESG takes no position about which approach is to be preferred
    and cautions the reader that there are serious open issues for each
    approach and concerns about using them in tandem.  The IESG believes
    that documenting the different approaches does less harm than not
    documenting them.

    The community is invited to observe the success or failure of the two
    approaches during the two years following publication, in order that
    a community consensus can be reached in the future.

The work wasn't so independent and a coincidence that these four docs 
inserted the IESG note.

Thanks

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 May 2015 17:42:35 -0700

> It should be off the DMARC record now.
Dear Hector,

Yes. DMARC uses SMTP outbound registration confirmation to
mitigate DKIM failure.  Sender header fields indicate the
domain responsible for issuing a message when present. 
DMARC failed to accommodate the Sender header field for
those domains handling normal email exchange.  Ignoring the
Sender header field is appropriate only when just direct or
transactional messages are issued by a domain asserting
restrictive DMARC policy.  In these cases, there would be
little chance either DKIM or outbound registration would be
negatively affected.

DMARC being unable to assert the domain handles normal email
exchanges likely to affect both DKIM and SMTP outbound
registration makes its resulting policy requests unreliable
and incompatible with RFC5322.  Restrictive DMARC policy
necessitate special handling of third-party services to
retain defined roles of From header fields per RFC5322. 

Rather than assisting other domains mitigate misapplied
policy, domains abusing DMARC are causing munged From header
fields and misapplied policy having a dangerous outcome of
legitimate messages being misplaced into Spam folders.  As
such, DMARC should signal when specific authorizations can
be obtained by using a uniform reference to either a
specific or a default domain or that the Sender header field
may offer an optional alignment when likely visible to the
recipient.
> Do we really need a hash?  I agree. This required new
> tools (Hash calculators, wizard, command line tools, DNS
> tools, etc) for DNS admin and sysops to be programmed. 
> Makes it harder to explore.
Third-party authorizations should be uniform, small, and
hard to explore.  Even to the point of publishing a wildcard
mitigating the generation of a large number of RRsets as
seen with DNS-SD that even expects this type exploring
behavior causing a real DDoS concern.
>> align with those benefiting (the DMARC domain).
Many have not realized double signing is wide open to abuse
and will need similar DNS publishing techniques to adhere to
a broken window theory. 
http://en.wikipedia.org/wiki/Broken_windows_theory

Few things are more reprehensible than using DMARC to abuse
legitimate uses of email just to continue ignoring
compromised accounts.

TPA-Label did not presume DKIM use, but
draft-levine-dkim-conditional would allow a simpler
TPA-Label listing scheme signaled using DMARC.  Ignore all
additional constraints in TPA-Label, since a combined
strategy should safely handle a wider range of messages. 

It seems some have had some difficulty understanding the
rate of message handling involved by larger ESPs which makes
conditional handling fairly difficult to instrument.  Here
again, TPA-Label helps.  Unlike SPF's high overhead of
complex chained resource records,
draft-levine-dkim-conditional together with TPA-Label would
allow simple single resource record listings.  Their
retraction allows a quick abuse response.  Restoration can
be just as quick once abusive accounts have been disabled or
disinfected.

This represents a simple lightweight scheme that should
significantly reduce the rate of abuse by keeping the
Sending domains fully in the loop and easily instrumented.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 13 May 2015 10:58:43 +0900

Douglas Otis writes:

 > DMARC being unable to assert the domain

I'm not sure what you mean by "assert the domain".  AFAICS no new
protocol is needed to validate Sender -- SPF and DKIM allow that
already, and it's not obvious to me where the big threat is from a
misaligned or spoofed Sender.  (A BCP might say that Sender should be
aligned with the SPF domain if available, and otherwise with a valid
DKIM signer otherwise).  I suppose some receivers already use this
information in their reputational models.

 > Many have not realized double signing is wide open to abuse

Please present your threat analysis.  As far as I can see, double
signing is no more vulnerable than the current practice for mailing
lists when relaying mail from p=none sites.  It would increase the
attack surface for the kind of abuse that caused some major sites to
publish p=reject last April, but it's something that can be turned on
incrementally as a matter of local policy (just as DMARC itself was),
and it can be turned off as fast as you can propagate the config
change to your SMTP server farm (unlike p=reject itself, which suffers
from DNS caching lag).

I wouldn't call that "wide open".

Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 May 2015 10:05:47 -0700

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 May 2015 14:38:20 -0700

> information in their reputational models.
Dear Stephen,

Perhaps my intent was obscured by thoughts of what's next.
Of course, nothing prevents DKIM/SPF alignment with the
Sender header field.  Restating:

Ignoring the Sender header field is appropriate ONLY when
just direct or transactional messages are issued by a
domain.  Only then are conflicts with RFC5322 avoided when
asserting restrictive DMARC policy.  Restrictive conflicts
are due to the fact that DMARC lacks a means to assert the
domain handles NORMAL email exchanges.  In effect NORMAL
messages will affect both DKIM and SMTP outbound
registration alignment fields.  Handling NORMAL email
exchanges WILL cause policy requests based ONLY on From
alignment to be UNRELIABLE and INCOMPATIBLE with RFC5322. 

Currently ALL DMARC policy assertions ignore the role of the
Sender header field.  DMARC wrongly assumed the domain would
limit its email to only direct or transactional messages. 
When the Sender and the From header field differ, ONLY the
Sender header field can be expected to establish domain
alignments with SMTP outbound registration.  UNTIL DMARC
provides a provision to assert the handling of NORMAL email
to permit conditional alignment with the Sender header
field, no BCP can offer a solution.

Conditional alignment might include the identifier likely
being visible in the message or accompanied with an explicit
DMARC authorization.  A receiver can never reliably resolve
a policy conflict caused by NORMAL email exchanges without
input from the DMARC domain.  Either SMTP needs to redefine
roles for Sender and From header fields OR DMARC must
include provisions to properly include the role of Sender.
> I wouldn't call that "wide open".
Even assuming a new scheme might extend DKIM expiry carried
within the DKIM signature to an authorized signature, this
would be problematic since mailing-lists expect
conversations to extend over fairly long periods. 
Authorized DKIM signatures via double signing sidesteps
restrictive DMARC policy where a resulting message can be
replayed to any number of recipients well beyond the control
of the DMARC domain.  This is a general feature of DKIM so
no special analysis is necessary.  The authorization is wide
open since DKIM does not facilitate a means to squelch any
resulting phishing campaign.

How is double signing better than simply including the
Sender header field?  Acceptance can also be based on the
Sender header field with an expectation greater effort is
made to ensure the Sender identity:
 
 1) is included in the message.
 2) can be validated.

Our practice was to ensure a response to abuse within 15
minutes using 5 minute TTLs.  Consider the broken window
theory.  Being unable to respond in a timely and effective
manner makes authorizations wide open.  This lack of control
will encourage higher levels of abuse.  However, use of the
Sender header field would ensure the sending entity is held
accountable.

Regards,
Douglas Otis

P.S. Sorry about the empty response I think was caused by a
trackpad bump.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 14 May 2015 13:05:51 +0900

> Sender header field.  Restating:

If it's signed by upstream and altered as RFC 5322 suggests it should
be for mail which is received and reinjected, it will break the
original signature if Sender was signed upstream.

So what you're proposing, AFAICS, is already available and widely
practiced: Mediators resign, and receiver ignore the broken upstream
signature if the Mediator has a good reputation.  Too bad for
"policy", but the only people who actually *want* policy are the
banks.  Yahoo! and AOL at least have made it quite plain that they're
happy to see mailing lists and other third parties working around
p=reject.

The only addition that TPA etc provides from the point of view of the
user is a protocol for consulting the Author Domain for information
about Mediators, but experience shows that Author Domains are not
interested in providing such information.  For example, when MLM
admins ask them why mail isn't getting to subscribers, they refuse to
answer in any specifics.  They simply point to their AUP and third
party acceptance policies, if any.  Some domains even try to hide
policy rejections completely by using a generic "permanent failure"
status code.

 > domain.

If Dave Crocker had his way, we'd ignore From, too (I'm exaggerating
here a bit).  I can't agree with that extreme position (which I
believe Dave doesn't actually espouse): even if we have no published
proof that phishing via contact lists is substantially more effective
than use of sibling domains etc, the theoretical risk is too clear to
ignore.  In any case we do have public proof that spammers think it
works, and graphs that show that DMARC p=reject can prevent spikes as
high as 6-10 times the background level of spam.

 > Only then are conflicts with RFC5322 avoided when asserting
 > restrictive DMARC policy.  Restrictive conflicts are due to the
 > fact that DMARC lacks a means to assert the domain handles NORMAL
 > email exchanges.

That's right, and AFAICS it's very difficult to improve the protocol
because no Author Domain would want to grant carte blanche to 3rd
party *domains*, unless it's known that they run as tight a ship as
the Author Domain itself does.

By "tight ship" I mean something like a domain that effectively
represent a single trusted user with a relationship to the Author
Domain.  But the domains that are abusing p=reject have relationships
with millions of domains, few of which are single-user and very few of
which are trusted not to abuse "on behalf of" signing privileges.  The
mailing lists I care about don't qualify.  Many of the innovative
3rd-party services (greeting cards, send-an-interesting-article, etc)
are not going to qualify either, especially the startups.  Many of
these services look an awful lot like spam, too, even though
recipients will tell you that they aren't.

 > In effect NORMAL messages will affect both DKIM and SMTP outbound
 > registration alignment fields.  Handling NORMAL email exchanges
 > WILL cause policy requests based ONLY on From alignment to be
 > UNRELIABLE and INCOMPATIBLE with RFC5322.

Yes, we know that.  It was predicted well in advance of the empirical
proof, as people involved in the early development of DMARC came to
Mailman at least a year before the April Debacle with patches designed
to break RFC 5322 conformance on behalf of posters at p=reject domains.

 > Sender header field.

Which seems theoretically correct to me, as (unlike From) Sender is
not arguably a field reserved to Author Domains.  Of course a Mediator
can make an assertion about Sender by DKIM signing it, but it seems
rather unlikely to me that Author Domains would want to make
assertions about Sender along the lines of "if Sender is signed,
consider the message to be authentic".

At this point, of course you and Hector will bring up TPA and POLICY
and claim it would be cheap and effective.  But as a mailing list
advocate with extensive experience of trying to get on the registries
of the p=reject domains, of just trying to get information about why
my mailing list seems to be banned, or even just getting confirmation
that it *is* banned, TPA/POLICY strikes me as miscalculated
chemotherapy -- you kill the patient before the cancer.

 > DMARC wrongly assumed the domain would limit its email to only
 > direct or transactional messages. When the Sender and the From
 > header field differ, ONLY the Sender header field can be expected
 > to establish domain alignments with SMTP outbound registration.

That assumes that anybody actually wants to establish domain
alignments, other than their own.  I don't think that they do.  I
think they really want something much more flexible than that, able to
assert that individual senders have their trust.  If they really want
to assert trust in anybody else at all.  I see no convincing evidence
that the p=reject domains would want to participate in these
protocols, except to make arrangements with commercial partners (think
Intuit's invoicing service) more standard and perhaps less costly.
Mailing lists, they'd love to help us as long as it costs nothing to
them.

 > input from the DMARC domain.

Of course they can.  If Google Groups includes an A-R that shows that
a message from a Yahoo! user was From-aligned, and signs that as well
as the rest of the message, I'm sure that Gmail at least will consider
that a reliable resolution, and ignore the lack of From alignment of
the message as distributed by Groups.  I would myself (if I ever
subscribed to a Google Group :-).  Thus we already have a mechanism by
which Receivers can make their own decisions based on their own chains
of trust, but DMARC purports to take that decision out of their hands.
It fails to do so, of course, and IMHO that failure is a good thing.

 > Either SMTP needs to redefine roles for Sender and From header
 > fields OR DMARC must include provisions to properly include the
 > role of Sender.

I disagree.  AFAICS the Sender field has no interesting role here.
The From field is singled out entirely because of its potential role
in phishing attacks and recommender spam, that is, because of its role
in identifying authors to end users.  What matters to authentication
of the sender is simply the security of IP addresses (in the case of
SPF) and the security of signatures and the DNS (for both SPF and
DKIM).  By the nature of the protocols using the DNS, they also serve
to identify the sending domain.

 > > Please present your threat analysis.

 > conversations to extend over fairly long periods. 

That's irrelevant.  The whole point of the double-signing schemes is
that they are per-message.  The relevant period of conversation is the
chain of SMTP transactions and Mediation from the boundary MX of the
Author Domain to the boundary MX of the subscriber's domain.

 > restrictive DMARC policy

It's not a sidestep.  It's a deliberate modification of the policy,
applied to a single message.

 > where a resulting message can be replayed to any number of
 > recipients well beyond the control of the DMARC domain.  This is a
 > general feature of DKIM so no special analysis is necessary.  The
 > authorization is wide open since DKIM does not facilitate a means
 > to squelch any resulting phishing campaign.

The time limit on delegation automatically squelches the phishing
campaign within a few minutes, and once the decision to shut off
delegation is taken, it would be effective in seconds, I suppose.

I do not intend to downplay the bad consequences were such a campaign
to actually occur, simply to point out that unlike the use of p=reject
which requires action on the part of the Author Domain's administrator
to squelch a malmail campaign (and requires some minutes to do so),
the squelching that occurs with the delegation proposals is an
inherent part of the protocol.

Of course a new opportunity arises with each message sent by the duped
author, but even here those messages can be shut down instantly (ie,
delegation signatures are not added to any outgoing messages) at the
administrator's decision.  Messages already in the pipeline will
continue to provide an attack vector, but they expire as quickly (or
perhaps more so) than the TTL on DNS records.

 > How is double signing better than simply including the Sender
 > header field?

Author Domains can make assertions about specific Mediators on a per
message basis.  While delegation may be too costly in practice to
attract use, it's designed that way.

This is better than any protocol based on Sender and a registry,
because registry upkeep is clearly prohibitively costly when making
per message distinctions or differentiating between different
Mediators sharing a domain.

 > Acceptance can also be based on the Sender header field with an
 > expectation greater effort is made to ensure the Sender identity:
 >  

(1) is already done because the sender's signature identifies it.
(2) is extremely controversial because it requires solving the
registration problem.  I don't think it can be done in real time, and
mailing lists already have enough problems getting the big providers
to recognize their existence as anything except undesirable bulk
mailers.

 > Our practice was to ensure a response to abuse within 15 minutes
 > using 5 minute TTLs.  Consider the broken window theory.  Being
 > unable to respond in a timely and effective manner

"Unable"?  I don't think you understand the proposed protocol.

 > makes authorizations wide open.  This lack of control will
 > encourage higher levels of abuse.  However, use of the Sender
 > header field would ensure the sending entity is held accountable.

That's wishful thinking.  Senders are already held accountable by RBLs
and the like.  The problem is that spammers have as many new senders
as they need, while Mediators tend to have fixed identities, so that
while such "accountability" raises costs for spammers, it kills
mailing lists (or at the very least puts them on the disabled list
until reputation can be repaired).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 May 2015 22:42:52 -0700

> consider the message to be authentic".

+1 here, and to pretty much all of this message.

Moreover, current use of Sender by both producing agents and consuming
agents is inconsistent.  Suddenly relying upon it in addition to or instead
of From for much of anything creates the need for a lot of people to change
how they do things, and that seems unlikely in anything but a long time
frame.

So, too, is it unlikely that anything registering a
No-Really-THIS-Is-The-Really-Real-Sender header field will gain widespread
adoption.

What gets added from here forward really needs to be as innocuous as
possible.  I believe we're in a position where things like SPF and DKIM are
still young enough that their implementations are malleable, but trying to
get every MLM, MTA, MUA, and MSA out there to suddenly use Sender
universally and in a common way seems far less likely to be successful.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 14 May 2015 16:51:44 +0900

Murray S. Kucherawy writes:

 > What gets added from here forward really needs to be as innocuous
 > as possible.  I believe we're in a position where things like SPF
 > and DKIM are still young enough that their implementations are
 > malleable,

I'm not sure what you mean.  Now that I actually know what those
protocols do (and DMARC itself, for that matter), I don't really see
how they can be much improved.  Do you mean the policy engines that
make decisions based on the output of SPF and DKIM implementations?

Going way out on a limb here, it's not even clear to me that getting
the simple delegation protocols[1] implemented would be of that much
incremental benefit to mailing lists and other forwarding Mediators
given that everybody and their brother seems to be taking a Monty-
Pythonic "wink, wink, nudge, nudge, say no more, eh?!" approach to
p=reject as receivers.

What would be ideal from my point of view (as a mailing list advocate,
though I don't claim to represent all MLM developers in this) would be

(1) The DMARC standard itself to achnowledge that "p=reject" really
    means "we are very worried about the security implications of our
    domain in the From field" (with different spin depending on
    whether you're a bank or a large mailbox provider that has leaked
    a lot of personal information to spammers, but basically the same
    semantics for the mail system), and therefore

    Receiving systems SHOULD treat a message that fails the From
    alignment test with great care, including such measures as
    quarantining the message in a special folder, deactivating links
    and attachments in the displayed message, or displaying a warning
    message that the message is likely to be inauthentic.  Receiving
    systems MAY reject such messages outright.  Receiving systems MAY
    treat as authentic a message that would otherwise be quarantined
    or rejected under this protocol in the presence of strong evidence
    of authenticity such as a valid signature of important header
    fields and body by a well-trusted Mediator (see Security
    Considerations for discussion).

    I think this has almost no chance of actually happening, but it's
    what I'd consider ideal.

(2) Some kind of Authentication-Results protocol, which would be one
    of the "important header fields" mentioned in point (1).  There
    would need to be provision for multiple fields of this type, so it
    would need to include the identity of the authenticating agent.
    It occurs to me that this field might need a weak signature of its
    own to establish authenticity in the presence of a chain of
    Mediators.

    This doesn't depend on (1) to be useful in the de facto presence
    of people acting as in (1).

(3) I would really like to see some provision for reporting to mailbox
    users when their mail is being discarded due to publication of
    p=reject by their mailbox providers, especially in cases where a
    Mediator is willing to put its reputation on the line by signing
    the forwarded message.

    Note that this would only be a burden to abusers of p=reject, as
    in the case of transactional mail the responsible author is the
    corporate entity, not the employee.  So no further report would be
    appropriate in that case, as the organization is already receiving
    the DMARC reports.

 > but trying to get every MLM, MTA, MUA, and MSA out there to
 > suddenly use Sender universally and in a common way seems far less
 > likely to be successful.

We can't even get the (displayed) From used in a common way, viz the
"From <sender> on behalf of <author>" usage.  Technically, I
understand the point they're making, but real people think of
on-behalf-of as the kind of thing lawyers do: "Dear Miscreant: I am
writing on behalf of Mr. Offended Easley as his attorney.  Cease and
desist.  Sincerely, Beagle Leagle, JD" (and of course the actual RFC
5322 Sender is Ms. Para Leagle).  Some real people do find that
confusing.

Footnotes: 
[1]  I'm of two minds regarding your (Murray's) more complex part-by-
part signing scheme.  On the one hand, it's way cool, and should be
implemented for that reason alone.  On the other, it looks expensive
and fragile and I suspect it won't get a lot of uptake for that
reason.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 May 2015 04:54:04 -0700

> make decisions based on the output of SPF and DKIM implementations?

I'm saying that incremental changes to DKIM, SPF, and DMARC are far more
likely to succeed than anything along the lines of "Everyone start using
and paying attention to Sender", "Let's register yet another Sender-type
field", or "Registration scheme X".  The operational changes required for
those three families of solutions are too enormous and involve too many
wildcards for me to believe they stand a chance of success.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Thu, 14 May 2015 16:06:20 -0700

Dear Murray,

The Sender header field when present has been defined for
decades to represent the sending agent!

DMARC improved delivery registration accuracy for
TRANSACTIONAL messages based on the SMTP MailFrom parameter
(bounce address) or DKIM (unrelated to any field) where
either is allowed to fail.  For TRANSACTIONAL email,
combining these two marginal authorization schemes easily
adjusted to relate with the From header field offered a low
percentage authorization failure to better ensure compliance
with a restrictive policy.  The expediency this allowed did
not justify disrupting valid and legitimate exchanges not
limited to transactional or direct messaging configurations.

Neither DKIM nor SPF authenticate an actual message source,
but simple authorization offers reasonable control over
messaging resources.  DMARC is fine when messages are
limited to direct exchange, but fail badly when exchanges
make use of the Sender header field that may signify use of
mediators or other resources.  At one time DMARC even
recommended against issuing non-transactional messages, but
acknowledgement of DMARC's potential disruption of normal
email interchange was dropped.

Commercially available products for years have been able to
clearly indicate the entity trusted at providing a message. 
It seems DMARC assumes recipients are too easily misled and
can't be trusted to deal with S/MIME, OpenPGP, or MUAs that
verify and display the Sender header field and think
everyone is better able to deal with munged From header fields.

The TPA-Label is able to thwart wildcards simply by
publishing a negative wildcarded label.  A practice that
won't work with DNS-SD.  A sender must have reasonable
control over the resources they authorize.  Any double
signing scheme relaying authorization to a third-party via
DKIM can not control the authorized resources since the
entire message body may change and DKIM can be replayed to
any destination by design.  Without adequate control,
authorization protections fail simply because neither SPF or
DKIM are able to authenticate the source, nor can DKIM offer
an expedient authorization retraction in say a 5 to 15
minute range.

While I commend efforts made at fleshing out your version of
the ATPS protocol, due to the inherent hurdles introduced
for third-parties it was unlikely this scheme would be
adopted.  The lesson is DKIM offers a poor method to signal
changes beyond those already expected.

There was no reason to change how a third-party is verified
since they too can use DKIM and SPF or even DANE or the HELO
parameter for that matter.  The correct place to signal such
change is at the DMARC assertion.

See Third-Party Authorization example of:

"sam=tpa; and tpa=third-party-authority.example.com;"

https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4

This scheme involves a simple DNS server operating an
isolated zone separated from other domain services and can
even be published by a different domain.

This approach allows the _tpa zone to be maintained as a
community effort or as a specialty service to ensure the
sender has reasonable and nearly immediate control over the
resources they authorize.

By being able to include policy for the Sender header field,
DMARC can become compatible with RFC5322.

While some might describe this a complex authorization
scheme, it can be combined with
<https://tools.ietf.org/html/draft-levine-dkim-conditional-01>
draft-levine-dkim-conditional to offer a resource record
where only the base portion of the domain might be included
to guard against domain hash collisions.

TPA-Label that had the goal of reducing collateral damage
caused by compromised accounts or resources, can be combined
with draft-levine-dkim-conditional to signal when this
limited signature should be included and which domain needs
to be authorized.  Because this uses very simple resource
records, is should scale far better than SPF and yet permit
a means to establish an informal federation scheme to better
protect email infrastructure with low latency abuse responses.

TPA-Label does not make handling third-party messages
harder.  Instead, TPA-Label offers a simple way to signal
which domains require exceptional handling.  Without such a
feature, DMARC can not be seen as being compatible with
RFC5322. 

Again, we will happily help any large ESP configure and
maintain their services to make use of this scheme and even
offer the needed resources.

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Fri, 15 May 2015 06:27:05 +0000

> decades to represent the sending agent!

Maybe, maybe not. Outlook desktop client shows the Sender: header as "<sender> on behalf of <5322.from>", but neither Hotmail/outlook.com nor Gmail do. They just show the 5322.From address regardless of whether or not there is a Sender: header. This Sender: DMARC fix requires a change in the way these clients render email. Given the marginal additional benefit to  receiving mailing list traffic that won't implement any of the published workarounds (not modifying content, fiddling around with Reply-To and From addresses, changing the From: domain to be the mailing list domain), I can't see why Gmail or Hotmail would want to make a change like that. I agree with Murray that it isn't worth pursuing, the cost/benefit ratio isn't there.

> offer the needed resources.

Doug, who is this "we" you keep referring to who will happily maintain someone else's DNS zone? Your employer? Are you volunteering them on their behalf? Is this a free service of theirs? If not, why would anyone agree to a solution that is hard to manage at scale but, lucky for you, just so happens to benefit your employer?

The TPA authorization DNS zone publishing has been pushed by yourself and another board participant and has received universally negative feedback, or at best neutral feedback. The people here are smart and have as much experience as anyone else and they understand what you are saying. But they still don't agree, including me. I think it's time to make like the movie Frozen and let it go.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Thursday, May 14, 2015 4:06 PM
To: [email-masked]
Subject: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

Dear Murray,

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 May 2015 01:33:27 -0700

On Thu, May 14, 2015 at 11:27 PM, Terry Zink <[email-masked]>
wrote:

> Maybe, maybe not. Outlook desktop client shows the Sender: header as
> "<sender> on behalf of <5322.from>", but neither Hotmail/outlook.com nor
> Gmail do. They just show the 5322.From address regardless of whether or not
> there is a Sender: header. This Sender: DMARC fix requires a change in the
> way these clients render email. Given the marginal additional benefit to
> receiving mailing list traffic that won't implement any of the published
> workarounds (not modifying content, fiddling around with Reply-To and From
> addresses, changing the From: domain to be the mailing list domain), I
> can't see why Gmail or Hotmail would want to make a change like that. I
> agree with Murray that it isn't worth pursuing, the cost/benefit ratio
> isn't there.
>

The definition of Sender isn't even what I'm talking about.  Its use, not
its definition, are what's historically been inconsistent.  In particular,
as I understand it, it has not historically been the case that all message
generating agents that should add Sender, to identify the "actual
submittor" (RFC822), have done so.

People advocating for keying DMARC on Sender in addition to or instead of
>From must then necessarily imply that we should start relying on the
greater Internet to begin doing correctly something that has not been done
reliably for a long time.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 09:09:14 -0400

On 5/15/2015 2:27 AM, Terry Zink wrote:
> Maybe, maybe not.

Sender is a RFC822 header (since the 80s). Its been around for a long 
time.  Our MLS added it along with the "Error-To" for MLM operations. 
  No option to disable that.  I believe we stole the idea from the 
original listserv or rather we just wanted a way to give the BOUNCE 
guy or your own SERVER a way distinguish the type of mail you were 
seeing.  Error-To mean it was for the list.

> The TPA authorization DNS zone publishing has been pushed by yourself and another board participant and has received universally negative feedback, or at best neutral feedback. The people here are…

Terry,

Once about the time, SPF was put down (not supported) by the same 
"smart" folks leading or participating in the DKIM project and related 
projects.

SSP/ADSP was also put down only for the "Super ADSP" DMARC version to 
be resurrected by the "smart" folks.  Same ideas, same problems, but 
with a different language.

The "smart" folks also said:

1) No one will use POLICY protocols, and even if they did,
2) No one will published restrictive policies, and even if they did,
3) No receiver will honor them anyway, so whats the point?

The "smart" folks were wrong on these DKIM Policy Framework counts.

In other words, if by smart you mean, "consensus," then in all 
honesty, the consensus doesn't have a good track record in leading the 
DKIM project.

So please excuse me, and I don't mean any disrespect, if I am not too 
confident or excited with the direction you would like to take this 
DKIM project. The odds are very high, based on history, based on the 
leadership of this DKIM project, we are heading down another failed 
path with more patch work, more kludges, more "spaghetti code" and 
quite frankly, inadequate integrated work.

We are all tired of this, I suppose. I've been at it since 2003. The 
DNS Lookup query is the *ideal* IETF protocol solution and that should 
be one of the working documents completed and released as an 
Experimental Protocol.

Whether the private or public domain can or can not, is not the issue 
because that is always going to be the case.   Many will say its 
really not for the hotmail.coms, its too spam polluted.  That was what 
was meant when many didn't believe domains will not publish records. 
So it was surprising Yahoo.com created a hard policy, its also spam 
polluted.

But policy advocates can also understand why it was done.  You can 
instantly begin to clean up a domain by using tight SMTP policies. 
The small nimbler guys were able to do it and prove it for a long time 
and we also serve ISPs, ESPs and MLMs operations with our wares!

If you want an IETF solution, the DNS Lookup query is the easiest. 
Bottom line.  The registration thing is a side track and maybe 
"smarter" people than us can figure that out -- and I predict someone 
will.  So I highly recommend the IETF get ready for it, we prepare the 
DNS I/O protocol model for this, in the same way we did with DKIM STD 
for the Trust as a function of the SDID.

    Policy = DKIM_POLICY(ADID, SDID=NULL)
    Trust  = DKIM_TRUST(SDID, AUID=NULL)

    Note the ADID and AUID are different.

These were the conceptual DKIM POLICY+TRUST modelings we been fussing 
with for a long time.

Lets not make it so complicated, get back to basic and get it done 
already -- independent of registration part.  I am sure we will have 
plenty to say about this component and for the most part, MOST people 
can handle it.  Maybe the hotmails can't and thats normal.  It can't 
handle SPF either anyway.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 15 May 2015 15:07:09 +0000

> Sent: Friday, May 15, 2015 9:09 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over
> messaging resources
> 
> >> The Sender header field when present has been defined for decades to
> >> represent the sending agent!
> >
> > Maybe, maybe not.
> 
> Sender is a RFC822 header (since the 80s). Its been around for a long time.
> Our MLS added it along with the "Error-To" for MLM operations.
>   No option to disable that.  I believe we stole the idea from the original
> listserv or rather we just wanted a way to give the BOUNCE guy or your own
> SERVER a way distinguish the type of mail you were seeing.  Error-To mean it
> was for the list.
> 

We need to be careful when we assert meanings to terms in older RFCs. If you look at RFC822 Appendix A, none of the examples for the Sender field use a fully qualified hostname where the sender is in a different domain than From. This implies that the original intent of the Sender field was not to authorize unrelated 3rd parties to be the Sender on behalf of the From (party). 

> > The TPA authorization DNS zone publishing has been pushed by yourself
> and another board participant and has received universally negative
> feedback, or at best neutral feedback. The people here are smart and have
> as much experience as anyone else and they understand what you are
> saying. But they still don't agree, including me. I think it's time to make like
> the movie Frozen and let it go.
> >
> > -- Terry
> 
> Terry,
> 
> be resurrected by the "smart" folks.  Same ideas, same problems, but with a
> different language.
> 

I disagree with this assertion Hector. I was one of the folks arguing in favor of policy over reputation.  ADSP was moved forward but in the end was fundamentally broken. DMARC is not "Super ADSP", there are some fundamental differences. I declined to participate in the predecessor project to DMARC because I felt it to had issues (and in hindsight I guess I was right - it was stillborn). 

> In other words, if by smart you mean, "consensus," then in all honesty, the
> consensus doesn't have a good track record in leading the DKIM project.
> 

Sometimes consensus works - sometimes it doesn't. Sometimes not attempting consensus works - sometimes it doesn't (MARID working group).

> confident or excited with the direction you would like to take this DKIM
> project. The odds are very high, based on history, based on the leadership of
> this DKIM project, we are heading down another failed path with more patch
> work, more kludges, more "spaghetti code" and quite frankly, inadequate
> integrated work.
> 

This is one of the reasons I have held back from participating in the discussions/attempts to come up with authorizations for unrelated 3rd parties. Even recognizing the resistance from various quarters, 3rd parties and intermediaries (which modify messages) taking responsibility for messages they emit is ultimately the cleanest and most workable approach. Yes it requires change on the part of some (I'm waiting for shouts of "GET OFF MY VIRTUAL LAWN").

> We are all tired of this, I suppose. I've been at it since 2003. The DNS Lookup
> query is the *ideal* IETF protocol solution and that should be one of the
> working documents completed and released as an Experimental Protocol.
> 
> really not for the hotmail.coms, its too spam polluted.  That was what was
> meant when many didn't believe domains will not publish records.
> So it was surprising Yahoo.com created a hard policy, its also spam polluted.
> 

It isn't about whether a domain is spam polluted (as you call it), it is whether a domain can be abused by mail claiming to be from it but which emanates from somewhere else. These are two different issues. It is also about whether a domain owner/administrator has the right/authority to determine how it's domain is used.

> But policy advocates can also understand why it was done.  You can instantly
> begin to clean up a domain by using tight SMTP policies.
> The small nimbler guys were able to do it and prove it for a long time and we
> also serve ISPs, ESPs and MLMs operations with our wares!
> 
> Bottom line.  The registration thing is a side track and maybe "smarter"
> people than us can figure that out -- and I predict someone will.  So I highly
> recommend the IETF get ready for it, we prepare the DNS I/O protocol model
> for this, in the same way we did with DKIM STD for the Trust as a function of
> the SDID.
> 
> Lets not make it so complicated, get back to basic and get it done already --
> independent of registration part.  I am sure we will have plenty to say about
> this component and for the most part, MOST people can handle it.  Maybe
> the hotmails can't and thats normal.  It can't handle SPF either anyway.
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 May 2015 08:52:03 -0700

On 5/14/2015 11:27 PM, Terry Zink wrote:
>> The Sender header field when present has been defined for decades
>> to represent the sending agent!
> 
> Maybe, maybe not. 

Sorry, but there isn't much maybe about it.

The definition in the spec has been clear since the construct was
invented, in 1977.

/Usage/ has varied quite a bit, as with so much of email, with
implementations re-purposing the field in various ways, thereby
effectively defeating useful interoperability.

And 'display' of the field is an entirely separate issue. Commentary
about DMARC usually does cite 'display' as the essential requirement,
which drives selection of the From field.

IMO it continues to be a significantly misleading point, since end-user
viewing of the From field is largely irrelevant to any real-world
efficacy. This appears to be an indelicate point to raise, since it's
being consistently ignored as discussions about DMARC continue
(everywhere, not just here.)

On the other hand, the rfc5322.From field is the only field with a
content-related identifier that is /always/ present.

Hence, a receiving filtering engine has a place that it always can
always look, for a claim of authorship.  By its nature, a mechanism like
DMARC must begin with an identifier selected by the receiving filtering
engine.  Hence, there must (always) be an identifier reliably associated
with the message.  Its semantics must pertain to something semantically
interesting.  DMARC chose "content authorship", which is pretty
obviously reasonable.

With that claimed content responsibility, the engine can proceed with an
analysis that relates the identifier to a reputation.  One aspect of
reputation is "is the identifier authorized for use?"  DMARC answers
that question.

One could imagine a "handling responsibility" as being a reasonable
alternative choice, too, but it's much weaker.  Worse, it invites a
problematic disconnect between content responsibility and handling
responsibility, which thereby invites gaming the system.

Choosing content responsibility is therefore much more appealing, albeit
simplistic in a way that causes problems with the entirely legitimate
scenarios that the community has been seeing.  In particular, DMARC
requires very tight coupling between content and handling
responsibility, which differs from many, long-standing, legitimate
scenarios.

Choosing a properly-available Sender: field creates a much better
semantic, in terms of pointing to the responsible operational agent.

But it is not an operationally practical choice.  The problem is that
when that identifier is different from the content identifier, we have
the task of figuring out whether the identity in the Sender: field is
'authorized' to operate on behalf of the identity in the From: field.[*]

d/

[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not.  If this isn't clear to
anyone, I encourage re-reading Section 3.4.2 of RFC 5322.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 13:30:40 -0400

> We need to be careful when we assert meanings to terms in older RFCs. If you look at RFC822 Appendix A, none of the examples for the Sender field use a fully qualified hostname where the sender is…

I don't recall being interested in payload authorization when Sender: 
and Error-To: were added.  It was more about providing all the help in 
delivering the "bounce" back to the sender to help in some MLM related 
process before List-* headers days.  There were still SLIP/UUCP 
transports which didn't use the Return-Path, instead used a top "From 
" meta-header.

> I disagree with this assertion Hector. I was one of the folks arguing in favor of policy over reputation.  ADSP was moved forward but in the end was fundamentally broken. DMARC is not "Super ADSP",…

Then DMARC should perhaps remove its reference as "Super ADSP."

ADSP and DMARC have the same overall ideas of using an Author policy 
concept.  Same problem exist. Same basic issues.  Broken for all the 
same basic reasons.   We just didn't have the urgency back then to 
address the problem because of the reputation/trust focus as a 
solution. I don't think many took DMARC serious because it was a 
"Reporting" tool.  I just saw it proving using redundant reports what 
we already knew without reports.  Its not rocket science. ADSP DISCARD 
worked for filtering spoofs and it needed a 3rd party hook to it to 
protect the MLM resigner market.   We all agreed that a resign needed 
to be done in order to resolve the integrity issue.

> It isn't about whether a domain is spam polluted (as you call it), it is whether a domain can be abused by mail claiming to be from it but which emanates from somewhere else. These are two differen…

Its about many things. Laid out all the possible policy boundary 
conditions that can be expected when it comes to 1st party signers and 
resigners.  Thats fundamental in all this because we need to take the 
author domain at its word at some point.

    Does the author domain have an exclusive signing policy?
    Does the author domain allow resigners?
    Does the domain only allow authorized resigners, if so, how?

and so on.  we only got stuck on that last one.  We been able to 
separate the issue into a "BIG DATA" registration concern and not a 
big issue for a smaller network of potential resigners.

You have to be able to describe this policy via the DMARC lookup. 
Then the receivers will have a better want to handle it.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 14:03:39 -0400

On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote:

> This is one of the reasons I have held back from participating in the discussions/attempts to come up with authorizations for unrelated 3rd parties. Even recognizing the resistance from various qua…

I noticed that with your ag.com, you only have an SPF -ALL record.  No 
ADSP, no DMARC.  I also notice that you didn't sign your mail.  So I 
don't know if you have a DKIM public key.

So basically, you decided not to have any assertions made on your 
ag.com from a DKIM, Trust and Reputation, Policy standpoint.  The odds 
are high that if you are going to get spoofed, it will have to be sent 
from a different an unauthorized IP address.

With a SPF -ALL, it lowers the need for DMARC, ADSP.  Thats another 
reason why there is less urgency.

DMARC is really a helper for SPF softfail (~ALL) or neutral (?ALL) 
policies.

During the DKIM-WG,  Microsoft did talk about using ADSP DISCARD with 
a SPF SOFTFAIL.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 15 May 2015 18:30:43 +0000

> From: Hector Santos [mailto:[email-masked]]
> Sent: Friday, May 15, 2015 2:04 PM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]
> > This is one of the reasons I have held back from participating in the
> discussions/attempts to come up with authorizations for unrelated 3rd
> parties. Even recognizing the resistance from various quarters, 3rd parties
> and intermediaries (which modify messages) taking responsibility for
> messages they emit is ultimately the cleanest and most workable approach.
> Yes it requires change on the part of some (I'm waiting for shouts of "GET
> OFF MY VIRTUAL LAWN").
> >
> 
> I noticed that with your ag.com, you only have an SPF -ALL record.  No ADSP,
> no DMARC.  I also notice that you didn't sign your mail.  So I don't know if you
> have a DKIM public key.
> 

Ag.com is not a domain I control - it is controlled by my corporate parent (enterprise) and used for enterprise mail.

The website domains I'm responsible for have been publishing an SPF -all, DKIM sign all mail and publish a DMARC p=none. The SPF, DKIM and the equivalent of DMARC p=none through private channels (yes, I helped create DMARC) have been in place since 2007 and working quite nicely thank you. If you go back to the dkim-ops list archive you will find an email from me asserting that anyone should feel free to throw away email that failed to validate our (domains) DKIM signature or aligned SPF. The only thing I had to do when the DMARC spec was completed was publish a p=none record.

> So basically, you decided not to have any assertions made on your ag.com
> from a DKIM, Trust and Reputation, Policy standpoint.  The odds are high that
> if you are going to get spoofed, it will have to be sent from a different an
> unauthorized IP address.
> 

I can't decide policy for a domain I don't control. In this case I'm a user like any other. I have, of course, expressed my opinion. This is no different than if I subscribed to the list from Gmail or some other service provider.

> With a SPF -ALL, it lowers the need for DMARC, ADSP.  Thats another reason
> why there is less urgency.
> 

Most mailbox providers I'm aware of do not reject mail solely on the basis of an SPF -all failure. There are far too many incorrectly published/problematical records out there that they wish to take that risk. This is one of the reasons that DMARC was developed.

> DMARC is really a helper for SPF softfail (~ALL) or neutral (?ALL) policies.

You place too much emphasis on SPF. There is a reason that DMARC policy is only considered if both (aligned) SPF AND DKIM fail to validate.

> 
> During the DKIM-WG,  Microsoft did talk about using ADSP DISCARD with a
> SPF SOFTFAIL.
> 

Lots of things were talked about in the DKIM working group. That might be one reason it took so long for the group to get things done.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 May 2015 12:35:54 -0700

> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.

Did you mean 3.6.2?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 May 2015 13:13:50 -0700

On 5/15/2015 12:35 PM, Murray S. Kucherawy wrote:
> On Fri, May 15, 2015 at 8:52 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

wtf.

I read 3.6.2.  I thought 3.6.2.  I proofread 3.6.2.

How the heck did 3.4.2 show up?

grrr.

d/

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 May 2015 16:37:20 -0400

> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.

There are defaults and overrides.  RFC4407 "Purported Responsible 
Address (PRA)" has done some project research work in this area:

    https://tools.ietf.org/html/rfc4407

    Abstract

    This document defines an algorithm by which, given an e-mail message,
    one can extract the identity of the party that appears to have most
    proximately caused that message to be delivered.  This identity is
    called the Purported Responsible Address (PRA).

and the steps to get the PRA is outlined:

    https://tools.ietf.org/html/rfc4407#section-2

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 May 2015 17:20:37 -0700

> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.
Dear Dave,

Also notice the attention to the Sender header field by
section 7.1 of RFC5321 in the following statement:
,--
Efforts to make it more difficult for users to set envelope
return path and header "From" fields to point to valid
addresses other than their own are largely misguided: they
frustrate legitimate applications in which mail is sent by
one user on behalf of another, in which error (or normal)
replies should be directed to a special address, or in which
a single message is sent to multiple recipients on different
hosts.  (Systems that provide convenient ways for users to
alter these header fields on a per-message basis should
attempt to establish a primary and permanent mailbox address
for the user so that Sender header fields within the message
data can be generated sensibly.)
'--

Operational practicality varies dramatically by domain based
on the type of email handled. For transactional email, with
some exceptions, policy based solely on the From can be
operationally convenient. When handling a normal range of
email configurations as typified for most ordinary users,
restrictive policy based solely on the From header field
domain will be highly disruptive of otherwise legitimate and
properly formed messages often supporting important
functions relied upon by a very large number of communities.

Unfortunately, DMARC removed admonishments on limiting the
types of email to be used by the domain asserting
restrictive policies and simply notes in Section 10.5
incompatibilities when mediators such as mailing-lists are
used.  This appears to indicate DMARC proponents have
entrenched into a view DMARC can force From header field
munging and abandonment of RFC5322 defined roles and the
functions defined by RFC5321, and submission practices
defined by RFC4409.  Rather than striking up the theme for
Frozen, the theme for Jaws seems more appropriate as basic
email specifications are crossed out in red.

Without question, abuse monitoring represents a level of
effort. Feedback provided by DMARC permits rapid and
automatic identification of essential exceptions otherwise
hidden without DMARC domain distribution of this
information.  Defending even simple url feed services that
attract children as followers as well as various Ad feeds
represent extremely difficult and serious challenges.  A
challenge greatly assisted by maintaining a type of informal
federation.  Larger providers are certainly less concerned
about becoming blocked and may choose to ignore difficult
aspects of their message distribution.  Placing this effort
onto recipients who lack necessary tools to rapidly identify
abuse will cause a general erosion of security.  It seems
unimaginable recipients will disregard offers by the DMARC
domain of authoritative threat related information.

The authorization of those maintaining trusted resources
provides an authoritative source of abuse related
information approaching the level of a binary yes/no
result.  The DMARC domain remains the sole arbiter of
reputation.

Attempts to distribute this information within DKIM siglets
by initial messages entails a similar data set but that
can't be easily updated.  Why not expand DMARC to include
assertions of an offering of domain relationships within a
single cache-able DNS transaction?  Nothing else offers less
overhead.  Such a change can prevent the munging of From
header fields or placement of otherwise valid and legitimate
messages into spam folders.

Of course, dmarc-wg can decide everyone wanting to use email
must now use a new From header field designated specifically
for that purpose to avoid the previously defined header
field now laden with restrictive DMARC policies.
https://tools.ietf.org/html/draft-otis-dmarc-escape-02
defines one such possibility.

im-from = "IM-From:" (mailbox-list / address-list) CRLF

address = mailbox / group

group = display-name ":" [group-list] ";" [CFWS]

mailbox = name-addr / addr-spec

addr-spec = local-part "@" domain ["/" resourcepart]

The resourcepart could be used to be compatible with XMPP. 
This element could be ignored when determining designated
MTAs, but can isolate message sources to better identify the
agent involved to better deal with any possible abuse.

Regards,
Douglas Otis

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 18:00:22 -0500 (CDT)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> To: "Murray S. Kucherawy" <[email-masked]>
> Cc: [email-masked], "Douglas Otis" <[email-masked]>
> Sent: Thursday, May 14, 2015 12:51:44 AM
).
>     appropriate in that case, as the organization is already receiving

The email is bounced, not discarded. The mailbox user knows about it. Unfortunately, bounces are so ugly that few people can successfully read them.

---

From: "John Levine" <[email-masked]>
Date: 22 May 2015 23:17:33 -0000

>>     the forwarded message. ...

>The email is bounced, not discarded. The mailbox user knows about it.
>Unfortunately, bounces are so ugly that few people can successfully read them.

Good point.  I would like to see some provision for reporting to mailbox
users when their mail is effectively discarded due to p=quarantine.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 18:47:00 -0500 (CDT)

----- Original Message -----
> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Friday, May 22, 2015 4:17:33 PM
With p=quarantine commonly either the message is marked as [SPAM] in the subject or is delivered to the spam folder. The message is not discarded either, so the mailbox users knows about it because people tend to write back: "why your message was marked as spam?"

This is of course if the message is not spammy or contain a virus, or nasty stuff like that, where the anti-spam filter may discard the message.

At no point in the spec DMARC tells to "discard the message".

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2015 20:08:03 -0400

> This is of course if the message is not spammy or contain a virus, or nasty stuff like that, where the anti-spam filter may discard the message.

Except of course for all of the people who don't look at all the crud in 
their spam folder.  They're not likely to write about messages they don't 
see.  If it's in the spam folder, for a whole lot of people it might as 
well be discarded.

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

---

From: Franck Martin <[email-masked]>
Date: Fri, 22 May 2015 19:20:40 -0500 (CDT)

----- Original Message -----
> From: "John R Levine" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, May 22, 2015 5:08:03 PM
> > This is of course if the message is not spammy or contain a virus, or nasty
> > stuff like that, where the anti-spam filter may discard the message.
> 
If a tree falls in the forest and your don't hear it, does it matter?

---

From: "John R Levine" <[email-masked]>
Date: 22 May 2015 21:14:17 -0400

> If a tree falls in the forest and your don't hear it, does it matter?

Um, what?  The topic at hand is a desire for senders to know when their 
mail isn't going where they want it to.

Regards,

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 23 May 2015 12:44:41 +0900

> >     users when their mail is being discarded

 > The email is bounced, not discarded.

Not necessarily.  Discard is one of the standard interpretations of
"reject" in RFC 7489, per section 10.3.  That is the case I'm
referring to.

---

From: Hector Santos <[email-masked]>
Date: Sat, 23 May 2015 10:43:18 -0400

> "reject" in RFC 7489, per section 10.3.  That is the case I'm

Feedback can already be done with an EOD (End of DATA) 250 server mail 
acceptance response:

   250 [2.5.7] Mail was accepted but will be discarded due to policy

That could be written in the spec as:

   The DMARC processor MAY issue a 250 reply code with an extended
   textual response indicating an accept/discard action is going to
   take place.

Keep in mind, that one of the key points of the [silent] 
accept/discard action is to not provide any feedback, notifications, 
bounces, backscattering mail noise, etc.

-- 
HLS