Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers

From: Vlatko Salaj <[email-masked]>
Date: Mon, 21 Apr 2014 11:54:16 -0700 (PDT)

On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote:

> This would be a simple first step consideration -- A new ATPS tag

this may fix DKIM 3rd party support, but does little to support
3rd party SPF. i think it's important to have a fix for all
underlying mechanisms, not just some of them.

considering DMARC may include additional underlying mechanism in
the future, a fix for 3rd party needs to be DMARC-based, not
based on whatever underlying mechanisms are included in DMARC
instead, imo. if we start fixing underlying mechanisms just to
have them DMARC-imposed alignment requirement compatible,
we are introducing new griefs to be dealt with in the future,
and adding bunch of incompatibilities with legacy support for
those protocols. so, whoever supports DMARC will have to add
support for all those new extensions and additional protocols
which may be more than what they are willing to do, opting for
just ignoring DMARC completely.

also, such path simply creates more resource usage, especially on
DNS, cause all those extensions have their DNS checks, and
sometimes more than one. also, more protocols, more libraries
running on server, fighting for resources...

why should we go that line, when it's easier to build a DMARC-based
support for 3rd party and fix the problem at the source?

> atps=0  default, extension disabled allowed backward compatibility.
> atps=1  Valid alignment allows a valid 3rd party signature (no checks).

this is similar to specifying adkim=n, the way Tomki Camp already
suggested, which i like better instead, since it's DMARC-based.

> atps=2  Valid alignment allows a valid 3rd party signature with ATPS
> (Authorized 3rd Party Signer) checking, RFC6541.

a receiver wishing to support ATPS can account for it during processing
DMARC, without any change in DMARC itself.

however, i'm quite sure everybody would be much more happy with a
single working protocol, instead of bunch of extensions.

> atps=3  Valid alignment allows a valid 3rd party signature using
> the May-Resign header method.

which is what exactly? i guess something similar to adkim=s:yahoo.com,
which i proposed already, but if u would like to continue lobbying for
this idea, please elaborate and provide examples.

in any case, i would like to see what benefits these solutions have
over other suggested proposals, like those suggested by
Joseph Humphreys, Tomski Camp and me, all of which tend to fix
DMARC, and not introduce requirements for additional extensions to
underlying protocols.

i can see many cons with ATPS-path while comparing the two principally
different ideas.

DMARC was created as a solution for a problem a bunch of other
extensions tried covering before already. all about failing.

we could skip that broken-path with DMARC today, since it's still in
development, and simply add 3rd party support to its base. i see
no issue with the idea of authorised alignment. it's natural to the
way email works. with some thinking, i'm sure we can make it work
for mailing lists too.

this is how i read J. Trent Adams' last post.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Apr 2014 17:31:45 -0400

> underlying mechanisms, not just some of them.

How do you define a 3rd party SPF condition that isn't already defined 
and authorized by the 1st party?  IOW, by virtue of the 1st party 
adding the 3rd party information into a SPF record, it is inherently 
ready for 3rd party operations. No?   This would be different that the 
DKIM + Author Domain Policy security model.

The problem with all the author domain policy protocols is that anyone 
can SIGN.  The original SSP (Sender Signer Practices) had 3rd party 
semantic and controls.  ADSP pruned and reduced SSP to 1st party 
semantics. The pruning left holes and ADSP was left unsolved. DMARC 
followed up with its own more explicit 1st party only semantics.

The main difference SSP, ADSP and DMARC is that finally someone has 
taken the rejection handling semantics seriously and began to apply 
it.  That also means that any domain with ADSP dkim=discardable can 
expect to see rejection/discard to be finally enabled.  See PAYPAL.COM 
ADSP and DMARC records.

Also, consider that DMARC "may" have violated RFC5016 "Requirements 
for DKIM Signing Practices Protocol" section 5.3, provision #10:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

If DMARC is about conforming to DKIM operations, then it SHOULD of 
provided the option for 3rd party signers to exist.  DKIM is about 3rd 
party TRUST support.  Even the policy advocated accepted that model, 
but we also felt POLICY was a fundamental part too.

> just ignoring DMARC completely.

I am not sure what that all means, but DMARC is notT conforming to the 
DKIM specification that by design allows for 3rd party operations.  So 
whatever the above means, DMARC does need to be fixed or not endorsed 
by the IETF.  DKIM is a STD level specification now.  DMARC must FIT 
with DKIM, not the other way around.

> running on server, fighting for resources...

Yes, ATPS does add more DNS records, but that seems to be an more 
acceptable in application design today, i.e. just like XML.  High 
overhead processing which today machines and communication speeds can 
handle making it feasible to consider.

> support for 3rd party and fix the problem at the source?

Agree, but if there is going to be resistance by the "gate keepers" of 
the specification and they won't do the "right thing" then the IETF 
needs to make the corrections, and the best current way to do this is 
with extensions which DMARC section 3.1.4.3 allows.  I agree, it 
should be part of the base spec.

>> atps=0� default, extension disabled allowed backward compatibility.
>> atps=1� Valid alignment allows a valid 3rd party signature (no checks).
>

If adkim=n(one) was proposed then that would do the trick to satisfy 
this particular "MUST BE SIGNED, BY ANYONE" practice, it would match:

  SSP  o=-       signature required, 3rd party allowed policy
  ADSP dkim=all  signature required, 3rd party allowed policy?

The problem was ADSP proposed standard was that it was unclear whether 
dkim=all also allowed 3rd party signatures.

You should review the 9+ years of R&D done with DKIM + POLICY layer, 
starting with SSP and ADSP to see how DMARC evolved and what fell thru 
the cracks with it.   My thinking was that DMARC was never really 
meant to be a policy handling protocol but a reporting protocol.

>> atps=2� Valid alignment allows a valid 3rd party signature with ATPS

Sure, but you also have to be prepared for extensions too.

>> atps=3� Valid alignment allows a valid 3rd party signature using

Mr. Resnick can provide more details, but in general, the point was to 
show flexibility with a new tag that allows for additional alignment 
processing.

> DMARC, and not introduce requirements for additional extensions to

Again, there is 9+ years of R&D.  Overall, the #1 issue was not that 
it wasn't a good idea, but how to SCALE it and how do manage it.  It 
adds complexity.  But the #1 resistance was the mailing list folks who 
didn't want to have any restrictions on (re)signing mail. See above 
about section 5.3, item 10 in RFC5016.

But there was proof of concepts and operations did already yse ADSP 
plus ATPS.  There is an even a ADSP + ATPS wizard zone creator and 
simulator at:

   http://www.winserver.com/public/wcadsp

> extensions tried covering before already. all about failing.

There is only one difference -- rejection was finally switched on.

ADSP did have support too by many of the high value domains.  But I 
don't think we were quite ready to do the rejection/discarding 
enforcement. We were just processing and logging the results to 
hopefully gather data with the AUTH-RES header. Reporting was always 
suggested but it was also viewed as something to limit potential abuse 
and it was never formalized. That is what DMARC did and what YAHOO did 
was finally turned on the rejection switch.  Thats really the main and 
only true event shocker here, IMO. Not DMARC as a "language" itself 
because we did have SSP and ADSP but we had too many IETF opponents 
against POLICY regarding middle ware issues -- hence this issue with 
YAHOO now.  DMARC was produced outside the IETF as it was envisioned 
to be the only way to get something moving.  Unfortunately, they 
really didn't do a good job in satisfying all the possible boundary 
conditions of the DKIM+POLICY+TRUST model.   In other words, they 
didn't really learn, did they? DMARC is very limited and that is what 
the IETF has to address.

> way email works. with some thinking, i'm sure we can make it work

Agree.

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Mon, 21 Apr 2014 15:08:55 -0700 (PDT)

On Monday, April 21, 2014 11:32 PM, Hector Santos <[email-masked]> wrote:

> ready for 3rd party operations. No?

no. 3rd party SPF support in DMARC's alignment context means support
for 3rd party SMTP MAIL FROM, or 3rd party HELO/EHLO. by SPF specs,
there are no provisions for 3rd party SPF support in this sense.

what SPF specs do allow is adding 3rd party servers to the IP pool of
senders, but that's not full 3rd party support actually, in DMARC
alignment terms.

> provided the option for 3rd party signers to exist.

i agree on this fully. it's only the question of how... and i would
rather see it inside DMARC, instead of outside of it.

> My thinking was that DMARC was never really meant to be a policy
> handling protocol but a reporting protocol.

this does make sense, especially how badly alignment requirement
was imagined. however, since it's more than a reporting protocol now,
and it's a promising one, we should fix it to include 3rd party
properly, as it should have been done in the 1st place.

> Unfortunately, they really didn't do a good job in satisfying
> all the possible boundary conditions of the DKIM+POLICY+TRUST model.
> In other words, they didn't really learn, did they? DMARC is very
> limited and that is what the IETF has to address.

+1!

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Apr 2014 19:18:17 -0400

>> and authorized by the 1st party?� IOW, by virtue of the 1st party

You mean Multi-hop, relays where there is a nodal IP transition point 
which fails the LMAP IP::DOMAIN assertion. (SPF is an LMAP protocol).

     The Association of the Sender IP and SMTP Envelope Domains:
                 LMAP Validation and Trust Analysis
    http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm

> senders, but that's not full 3rd party support actually, in DMARC

Right.

I think the DKIM 3rd party resigner issue is the more important issue 
at this point.

If this is not resolved, mail system developers like myself will be 
forced to provide undesirable "mail tampering" kludges and 
considerations to customers. :(

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Tue, 22 Apr 2014 00:20:54 -0700 (PDT)

> I think the DKIM 3rd party resigner issue is the more important issue

i hold both are important.

SPF's 3rd party support was basically fixed with Sender-ID. but Microsoft
never played well that open standards game... if it did, i'm sure we would
be having Sender-ID in DMARC now, in place of SPF, and this problem would
have been solved instantly.

however, since both SPF and DKIM 3rd party alignment support is similar
in nature, i'm sure DMARC can be flexibly expanded enough to fix both
issues, and any future mechanism it introduces, in the same way.

let's face it: all these scenarios are somewhat special in nature, and
while quite used and needed, they are not the default setting. so, even
if it places scaling problems on DMARC, it's not like everybody will
be using them on large scale.

"p=reject; rua=mailto:[email-masked]; ruf=mailto:[email-masked];
adkim=n,s:yahoo.com; aspf=yahoo.com" DMARC entry for example.com
domain solution is fool-proof, flexible, trivial and easily maintained.

it reads as:
1. request none alignment for example.com domain
[DKIM will never align with owner's domain, cause their domain doesn't
sign when it uses its own infrastructure, and 3rd party DKIM signatures
will never align with it either, cause they are 3rd party]
2. request strict alignment for yahoo.com domain
[1st party email fails here, but 3rd party signed email will align]
3. request relaxed alignment for example.com domain
[default relaxed setting for owner's domain doesn't need to be specified,
and it will align when any email is sent through domain's infrastructure,
and fail when it's sent through 3rd party]
4. request relaxed alignment for yahoo.com domain
[default relaxed setting doesn't need to be specified,
and it will align when any email is sent through 3rd party, fail on 1st]
5. reject anything that doesn't pass these scenarios, and report
accordingly
6. 1st party example: sends DKIM-unsigned email - DMARC passes, based on
SPF alignment policy
7. 3rd party example: sends DKIM-signed email - DMARC passes, with both
DKIM and SPF alignment passing.

consideration for abuse:
1. most ESPs verify email address ownership before it can be used
in their system, so nobody but ppl owning such addresses would be able
to post messages on behalf of a domain publishing some ESPs as 3rd party
for their mail subsystem. this is recommended and historical practice
already.
2. ESPs need to handle malicious accounts quite well already. so,
3rd party DMARC would not introduce anything that's already not there,
or put additional pressure on ESPs.

i can't see any exploit holes in this suggestion, at least not one
already covered by existing practices.

i repeat: all this 3rd party solution usage case is special in its
very nature. it would be applied where needed, and not a default
DMARC deployment.

i really see no reason why DMARC can't be flexible enough to include it.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Apr 2014 14:20:26 -0400

On 4/22/2014 3:20 AM, Vlatko Salaj wrote:
> ...

Hi Vlatko,

Take a look at the 2006 DSAP I-D proposed author domain policy 
protocol which provided tags to covered the complete 1st vs 3rd party 
boundary conditions for DKIM signing practices:

Original Party Signature (OP tag):

    Not Expected (op-)
   Expected (op+)
    Optional (op~)

3rd Party Signature (3P tag):

    No Expected (3p-)
    Expected (3p+)
   Optional (3p~)

See page 15/16 in http://www.winserver.com/public/ssp/DSAP-00.pdf

So the strongest would be the signing policy (sp=):

      sp=op+,3p-

You can also make it so that a domain only signs with a 3rd party 
trust vendor, with

      sp=op-,3p+

DMARC needs to offer similar semantical and tag flexibility to cover 
all possible 1st and 3rd signature conditions.

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Thu, 24 Apr 2014 23:16:14 -0700 (PDT)

> boundary conditions for DKIM signing practices:

seems reasonable.

but, believe me, there's no need to persuade me that we need 3rd party
alignment support in DMARC. i don't rly care about how it's done...
if it works fine and serves a purpose, great.

however, it seems we will have a terrible time persuading some
people here. they seems content with breaking email for the sake of
"providing security".

i always wanted to use this somewhere. seems like a perfect time and place:
They who would give up an essential liberty for a temporary security
deserve neither liberty nor security.

ps. i do love how these big ESPs think that today's 90% of their email
stream passing DMARC, comprising of mostly fb notifications ppl don't really
care about or read, is enough of a reason to break rest of email stream,
ppl actually care about, read and expect delivered without an issue.

pps. i also love egotrips. it's almost unbelievable how big some egos here
are... but, nothing new there.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

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

> if it works fine and serves a purpose, great.

Same here.

> people here. they seems content with breaking email for the sake of

Its a different view to consider it that way. Others will suggest, as 
myself, that is a by-design feature.  But the problem is that we 
failed to provide the flexible options to be backward compatible in 
some way.  Yahoo could of easily solved this b:

   1) First use p=quarantine

   2) Then use a user UI option to "confirm" with the user if the 
signer is ok,
      thus "learn" from its user base what should be "whitelisted."

Its not like they lack the Mail Business data Intelligence (MBI). 
They always had the info from previous imported list messages that the 
domain and list-id was acceptable by the user and not marked as spam. 
   In fact, we have this feature in our ANTI-SPAM system:

     If the user writes to a person, that person now becomes 
auto-whitelisted.

Trust me, this was a MAJOR SUPPORT g-dsend!  Resolved all sorts of 
first time blocking issues with customer support over a phone call, 
"hey, let me send you a permission list. Use this address to reply back."

But from a purity standpoint, the policy needs to be honored first, 
otherwise, all we have done is create even more loopholes to be exploited.

> ppl actually care about, read and expect delivered without an issue.

Its all hype. They don't represent or have a clue for the MBI going on 
with all the million of email domain private mail operations combined 
-- WORLD WIDE.   Its all marketing bull.

But what is a fact is that if you are an aged domain, most likely, it 
is very spam polluted. So I agree with their strategy to finally begin 
to clean it the domain and enhance its security value. No doubt, in my 
mind, this is a major plus for all aged, spam polluted domains, 
including our own.

The highest benefit in the SPF or DKIM author domain protocols comes 
form SELF-REGULATING your own domains, in other words, when main comes 
into your own SMTP system purporting to be coming from your own 
network of domains, you have the #1 highest spoof protection possible.

After first protecting your own domains (which is what Yahoo is 
doing),  you can decide if you also want to protect other REMOTE 
DOMAINS coming into your systems.

Do you do it as a favor? Or do you do it to protect your system and/or 
your users?

It was the latter consideration that became a major overhead and 
redundancy in attempting to check all domains coming in.  It was 
considered to be a short term concern. Over the long term, the hope 
was the efficacy/efficiency/payoff would be improved as more and more 
domains published policies.  I have to check where we are with this, 
i.e. how much of your incoming clients transaction have SPF and/or 
DKIM records, but no doubt, it has become significant.  See your 11 
years of ANTI-SPAM rejection history and statistics that shows how SPF 
was a near 0% and now is about mere 1.8% (as of april, 2014).  But I 
remember it took quite a few years to get event that high:

           http://www.winserver.com/SpamStats

I stopped at DMARC because I got sick of the IETF baloney with ADSP, 
but I explored all the ideas:

Even if 100% of the domain published policies, it was always my 
concern that it would be a major waste if most policies were relaxed, 
i.e. policy does not say to reject/discard.

So in my opinion, any SPF policy with a relaxed neutral was a BIG 
WASTE OF LOOKUP and processing time.  Same with DKIM relaxed signing 
practices.

So how do you handle this huge waste?

Again, you have to accept the hard failures with the soft and relaxed 
failures, and with the hard, you honor it otherwise you just made it 
worst as a relaxed result.

This was where the heuristic designs can play a role where it uses a 
combine set of non-deterministic, in between false and true, "fuzzy" 
logics or even combine it with user input to get some payoff from it. 
  But to constantly process a RELAXED SPF, ADSP or even now DMARC 
policy is a huge waste and major overhead.  That said, I think we did 
accept these higher overhead modes of operations. I guess people like 
what DMARC offers with REPORTING, but eventually even reporting 
becomes a redundant and wasteful operation.

-- 
HLS