Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

From: "John R Levine" <[email-masked]>
Date: 14 Nov 2016 22:00:45 +0900

[ resent with a reasonably correct date header ]

I can write this up as a draft if people think it's interesting.

Murray's draft puts the envelope recipients into the DKIM hash, which
means that the message sent to multiple MTAs be signed separately for
each target MTA.

My version puts the recipient addresses into the DKIM-Signature header
in an r= tag, separated by colons, using the usual quoted printable
to quote colons, semicolons or any other inconvenient characters, e.g.,

DKIM-Signature: v=1; ... r=[email-masked]:[email-masked]; ...

The signature is valid if all of the envelope recipient addresses are
present in the list of r= addresses.  It's OK if the r= list has
addresses not in the envelope, which fixes the signature per MTA problem.

To prevent data leakages, only addresses that appear in To:, Cc:,
Resent-To:, Resent-Cc: should appear in the r= header.  If you are
worried about replay of mail sent to Bcc: addresses, this approach is
not for you, but see below.

The reason I copy the addresses into the DKIM header rather than just
having a tag that means the recipients have to be in a To/Cc header is
that it avoids having to add the full glory of a 5322 header parser
into a DKIM verifier.  (Murray pointed out this problem.)

The reasonable way to make recipients pay attention to the r= tag is
to bump the DKIM version number to 2, and perhaps use the mandatory
tag indicator trick I suggested ages ago.  But since some people
insist that a version bump would cause horrible problems* we use the
same trick Murray did, and add the string "recipients\r\n" to the end
of the text included in the header hash if the signature contains a r=
tag.

Bonus hack for BCC users: instead of putting the recipients into the
r= tag, put in colon separated hex or base32 MD5 hashes of the
recipients.  To avoid rainbow table attacks, the new rs= tag includes
a variable length random salt string that is prefixed to each address
before hashing.  So to verify the signature, salt and hash the actual
recipients and see if all the hashes are in the r= list.  This leaks
the number of recipients but not their addresses.

R's,
John

* - They are wrong, but there's not much we can do about it.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Nov 2016 22:11:09 +0900

> My version puts the recipient addresses into the DKIM-Signature header

Privacy violation.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 14 Nov 2016 22:13:59 +0900

>> My version puts the recipient addresses into the DKIM-Signature header

You might want to read the rest of the message before responding.

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

---

From: Paul Rock <[email-masked]>
Date: Mon, 14 Nov 2016 09:11:26 -0500

I like it at first glance, but some qq-

I think you're going to have some major problems with internationalized
addresses an/or bad guys generally screwing with you if you try to use the
raw addresses in this header. Rather than having to deal with potentially
RFC2047 encoded strings or silly quoted string email addresses in this
field, why not just go full salt/hash? I assume you're trying to avoid
processing overhead? Also, what about cases where the number of recipients
make this header insanely long?

On Mon, Nov 14, 2016 at 8:13 AM, John R Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 
PAUL ROCK
Principal Software Engineer | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305

---

From: [email-masked]
Date: Mon, 14 Nov 2016 05:36:33 -0800 (PST)

Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:

(1) Whether or not to

    (a) Enumerate the recipients, or some representation of them, outside the
        DKIM hash, and sign that, or

    (b) Include the recipients, or some representation of them, under the
        DKIM hash only and don't expose them otherwise.

(2) Whether we enumerate recipients as:

    (a) Cleartext
    (b) Hashes
    (c) Encrypted form
    (d) Some combination of forms

    Note that (2)(b)-(d) are still choices even in the case of (1)(b).

(3) Whether or not the recipient check is an (a) mandatory or (b) optional part
    of the validation operation. (If you change what's signed in some way it's
    effectively mandatory, if you add a header containing either the hash of the
    recipients or a representation of the recipients and include it in
    the DKIM signature in the normal way it's optional.)

Now, in regards (1), I have to say I regard (1)(b) as a complete nonstarter,
for all the reasons previously given. The complete lack of control the sender
has over how recipient lists get split along the way has the potential to cause
all sorts of subtle failures. And given past behavior I don't trust senders
using this feature to use mitigations like single recipient messages when
necessary. In fact I skeptical most senders will even understand the issues in
play well enough to do the right thing.

I also categorically reject arguments along the lines of "this problem only
happens outside the intended use cases for this capability so we don't need to
worry about it". Given the way DMARC has deployed it would be utter folly to
base our design decisions on limited use case claims.

This is especially true since this mechanism can be employed, albeit in a crude
way, to try and prevent people from forwarding messages the message sender
doesn't want them to forward. And I absolutely can see people noticing this
capability and trying to use it.

In fact given the history here it's going to be seriously tempting to view
(1)(b) as yet another attack on existing email infrastructure, with all that
implies.

I'll also note that the implicit claim that the (1)(b)/(2)(a) combination
avoids exposing recipient information is in fact false. A simple
counterexample would be a message to a single Bcc: recipient in addition to the
whoever is listed in the various headers. If I receive such a message I can
simply perform the DKIM operation on the recipients listed in the headers, and
if it doesn't match I know there's a Bcc:. I then try inserting possible Bcc:
recipients into the list until I get a match. And in many cases I'll have a
pretty good idea what addresses to try, so in those cases this attack will be
many, many, many orders of magnitude more effective than brute force.

I believe this last point makes (2)(a) a nonstarter regardless of how (1) is
answered. 

As for whether or not (2)(b) or (2)(c) makes the most sense, the fact that in
many cases a recipient can come up with a list of likely addresses to try as
noted above is a really serious problem for any hash-based scheme. I'm not
exactly wild about the idea of all the public key operations (2)(c) calls for,
but I'm even less enthusiastic about adding to the reicpient leakage problem in
any way.

As for (2)(d), I see little point in using it in conjuction with (2)(b) - it's
much simpler to hash them all and be done with it. The combination of (2)(c)
and (2)(d), however, has the potential of eliminating some/most of the
public key overhead. (Another variation would be to use (2)(c) when
a public key is available and (2)(b) when it isn't.)

And that brings us to (3). It's important to note that making recipient checks
a mandatory part of validation doesn't make enforcement mandatory - a reciever
can simply detect and ignore DKIM signatures that require recipient checks.

The capability optional recipient validation provides is that a receiver has
the option of using the signature in the usual way. (That, and backwards
compatibility.)

Finally, I note that there is in fact a (0):

(0) This scheme can be applied to

    (a) Any message
    (b) Single recipient.

Requiring separate copies for each recipient in order to cover the recipient
with a signature renders (1) and (2) moot. In fact this scheme is so simple
that it merits serious consideration.

The big problem I see with (0)(b) is the overhead it imposes downstream. But as
I noted previously, so many messages are already sent separately to different
recipients it's unclear to what extent this is a factor.

				Ned

---

From: Vladimir Dubrovin <[email-masked]>
Date: Mon, 14 Nov 2016 18:45:40 +0300

> the number of recipients but not their addresses.

It doesn't protect against BCC discovery. If Alice [email-masked]
wants to check Bob bob@example is a recipients of Bcc, she can directly
get a hash of Bob's address with salt without the need to use any
rainbow tables. Asymmetric cryptography is requires with both sender's
and recipient's key to avoid this possibility.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Nov 2016 07:32:17 +0900

> You might want to read the rest of the message before responding.

No, I didn't want to.  But I did anyhow.

The proposal creates redundant information and an especially awkward 
usage restriction.

Invoking the privacy concern is meant to move the focus back to the 
reason the full, original rfc5321 envelope is not (necessarily) the same 
as the (aggregate) rfc5322 address header field contents.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 15 Nov 2016 07:37:06 +0900

> The proposal creates redundant information and an especially awkward usage 
> restriction.

I entirely agree.  Along with Ned's analysis of the various options, I 
hope this is enough to persuade people that the correct solution to the 
problem of signing spam for people to resend is Scott's: Don't Do That.

Regards,

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 14 Nov 2016 23:41:16 +0100

> DKIM-Signature: v=1; ... r=[email-masked]:[email-masked]; ...

At the time SenderID was proposed, back in 2004 or something, the act of 
propagating header information into the transport stream was seen by 
many as a layering violation. The proposal of Murray and Johns suggested 
kludge alternative do the reverse: propagating envelope information to 
the header. In my view this is, again, a layering violation. The 
downside of crossing layer borders is that transport and header 
information are (too) tightly coupled, which makes that the flexibility 
of the original mail design (RFC821/RFC822)  is lost.

Another aspect, in addition to (3) in Ned's answer, is that changing the 
way DKIM works brings a huge risk with it, now that DMARC is widely 
deployed and DMARC heavily relies on DKIM. So any change that is 
proposed for DKIM must have zero impact on the DKIM verification that is 
used by DMARC implementations currently in use.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 07:51:01 +0900

Hi Rolf,

On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld <
[email-masked]> wrote:

> propagating header information into the transport stream was seen by many
> as a layering violation. The proposal of Murray and Johns suggested kludge
> alternative do the reverse: propagating envelope information to the header.
> In my view this is, again, a layering violation. The downside of crossing
> layer borders is that transport and header information are (too) tightly
> coupled, which makes that the flexibility of the original mail design
> (RFC821/RFC822)  is lost.
>

There's obviously some truth to this, but there's also truth to the fact
that humans, the ones this community seeks to serve, routinely cross layers
in both directions whether or not we do so in protocols.  End user
education has never been a viable answer to protocol limitations as far as
I'm aware, much as we all wish it were so.

I'm willing to hold my nose -- a little -- at a reach across a layer
boundary if there's potentially a large win.  Whether this proposal or some
variant of it qualifies is why I brought the question to this group.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 08:07:38 +0900

On Mon, Nov 14, 2016 at 10:36 PM, <[email-masked]> wrote:

> [...]

That's a pretty excellent summary.  A couple of points:

I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being
the ideal choices.  Is that correct?  If so, we would just need to
determine the algorithm for generating the signed content that would be
included in the augmented signature.  If we do something like the random
salt suggestion, is this sufficient?

- pick a random string S of length L using only printable ASCII characters
(I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and
express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an
"rs" (recipient salt) tag

This is not reversible so nothing is leaked, but as we've all conceded by
now it's not hard to attack this to recover the hashed address especially
since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because
anybody can decrypt it with the public key.

What am I missing?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 15 Nov 2016 08:40:50 +0900

> "rs" (recipient salt) tag

I'd use base32 so it's not case sensitive but that's a very small nit.

> What am I missing?

Nothing I can see.  This seems to be the least bad implementation of this 
fundamentally bad idea.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Nov 2016 10:00:25 +0900

Annyeong haseyo,

While this thread is relevant to dmarc, it doesn't cover dmarc work.

So can we please stop copying the dmarc mailing list and just send to 
the dkim mailing list, where it belongs?

Thanks.

d/
-- 

   Dave Crocker

---

From: Vladimir Dubrovin <[email-masked]>
Date: Tue, 15 Nov 2016 12:01:09 +0300

15.11.2016 2:07, Murray S. Kucherawy пишет:
> On Mon, Nov 14, 2016 at 10:36 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b)
> being the ideal choices.  Is that correct?  If so, we would just need
> to determine the algorithm for generating the signed content that
> would be included in the augmented signature.  If we do something like
> the random salt suggestion, is this sufficient?
>
> - pick a random string S of length L using only printable ASCII
> characters (I like 8 for L but that's arbitrary)
> - SHA the string produced by prepending S to the recipient address,
> and express the result in base64 string R
> - include R in a new "er" (envelope recipient) tag and the salt S in
> an "rs" (recipient salt) tag
>
> This is not reversible so nothing is leaked, but as we've all conceded
> by now it's not hard to attack this to recover the hashed address
> especially since one might have good guesses as to what that address
> would be.
>
> I can't see the point of actually encrypting the hashed content,
> because anybody can decrypt it with the public key.
>
> What am I missing?
>

There is no need to reverse if you know e-mail address. Alice can check
Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail
and check if he is in 'er'.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Nov 2016 22:31:13 +0900

On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <[email-masked]>
wrote:

> Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and
> check if he is in 'er'.
>

Yes.  I wasn't identifying "not reversible" as a shortcoming, but rather as
a benefit.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 10:45:52 +0900

There's been a lot of great feedback here.  I just cranked out an update
based on the discussion so far:

https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01

I forgot to update the title of Section 3, but other than that I think I
captured what's been discussed.  Please let me know what I've missed.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Wed, 16 Nov 2016 01:50:56 +0000

This may be a dumb question, but if a DKIM-signature includes the original recipient, then wouldn’t that break the DKIM signature if the original MTA forwards it to another receiver even if they don’t modify any parts of the message?

How would people forward their email?

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, November 15, 2016 5:46 PM
To: Ned Freed <[email-masked]>
Cc: [email-masked]; John R Levine <[email-masked]>; [email-masked]
Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

There's been a lot of great feedback here.  I just cranked out an update based on the discussion so far:

https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-kucherawy-dkim-rcpts-01&data=02%7C01%7Ctzink%40exchange.microsoft.com%7C081d5799c8994a63eafd08d40dc2503e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636148575602454849&sdata=Lrh2%2FTjoVMD4V6xtlL%2Fq2v3nax%2FLStE2WYQjkWbOwLI%3D&reserved=0>
I forgot to update the title of Section 3, but other than that I think I captured what's been discussed.  Please let me know what I've missed.
-MSK

On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Nov 14, 2016 at 10:36 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:
[...]

That's a pretty excellent summary.  A couple of points:
I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices.  Is that correct?  If so, we would just need to determine the algorithm for generating the signed content that would be included in the augmented signature.  If we do something like the random salt suggestion, is this sufficient?
- pick a random string S of length L using only printable ASCII characters (I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an "rs" (recipient salt) tag
This is not reversible so nothing is leaked, but as we've all conceded by now it's not hard to attack this to recover the hashed address especially since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because anybody can decrypt it with the public key.
What am I missing?
-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Nov 2016 10:52:35 +0900

On 11/16/2016 10:50 AM, Terry Zink wrote:
> This may be a dumb question, but if a DKIM-signature includes the
> original recipient, then wouldn’t that break the DKIM signature if the
> original MTA forwards it to another receiver even if they don’t modify
> any parts of the message?

the proposal is to add the envelope rcpt-to to the signature.  change 
the rcpt-to and yes the signature will break.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 16 Nov 2016 10:56:57 +0900

> captured what's been discussed.  Please let me know what I've missed.

How come rh= has one hash instead of several?  You can put all the 
addresses in the To: and Cc: headers in one header without leaking, then 
do separate single hash if there are bcc's.

Regards,

---

From: Terry Zink <[email-masked]>
Date: Wed, 16 Nov 2016 01:59:15 +0000

Thanks, that's what I thought.

Large email receivers forward tons of email. This proposal causes email from DMARC-passing messages to be incapable of forwarding. As a large email receiver who gets tons of complaints about breakage of DKIM signatures on forwarded messages which causes DMARC failures [1], this proposal is not all that appealing.

:-\

-- Terry

[1] We are working on a fix for this.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2016 5:53 PM
To: Terry Zink <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

On 11/16/2016 10:50 AM, Terry Zink wrote:
> original recipient, then wouldn't that break the DKIM signature if the 
> original MTA forwards it to another receiver even if they don't modify 

the proposal is to add the envelope rcpt-to to the signature.  change the rcpt-to and yes the signature will break.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Nov 2016 11:28:08 +0900

On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink <[email-masked]>
wrote:

> Large email receivers forward tons of email. This proposal causes email
> from DMARC-passing messages to be incapable of forwarding. As a large email
> receiver who gets tons of complaints about breakage of DKIM signatures on
> forwarded messages which causes DMARC failures [1], this proposal is not
> all that appealing.
>

Version 01 is purely incremental, meaning you can just ignore the new tags
if you're more worried about breakage of forwarding than the attack it's
trying to address.

-MSK

---

From: Michael Storz <[email-masked]>
Date: Wed, 16 Nov 2016 13:51:42 +0100

Am 2016-11-16 03:28, schrieb Murray S. Kucherawy:
> On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink
> <[email-masked]> wrote:
> 
>> Large email receivers forward tons of email. This proposal causes
>> email from DMARC-passing messages to be incapable of forwarding. As
>> a large email receiver who gets tons of complaints about breakage of
>> DKIM signatures on forwarded messages which causes DMARC failures
>> [1], this proposal is not all that appealing.
> 
> Version 01 is purely incremental, meaning you can just ignore the new
> tags if you're more worried about breakage of forwarding than the
> attack it's trying to address.
> 
> -MSK

Optional for the sender, yes, but not for the receiving MTA. If the 
sender decides to use the new Anti-Replay-DKIM-Signature and has 
published a DMARC policy with reject or quarantine, then this policy is 
implicitly extended with

"ooh, and btw reject/quarantine ALL indirect emails, even if a normal 
DKIM signature could be verified"

This means ARC will be needed not only for mailing lists which modify 
the header or body of an email, but for EVERY mailing list and EVERY 
forwarded email or EVERYTIME the recipient has been modified and the 
email leaves the ADMD boundary. From a DMARC point of view DKIM will not 
be needed anymore because it has now the same function as SPF - 
verifiying the origin of direct emails - and SPF is easier to implement 
for most administrators.

Michael

---

From: Terry Zink <[email-masked]>
Date: Wed, 16 Nov 2016 18:09:03 +0000

> This means ARC will be needed not only for mailing lists which modify the header or
> body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME 
> the recipient has been modified and the email leaves the ADMD boundary. From a 
> DMARC point of view DKIM will not be needed anymore because it has now the same 
> function as SPF - verifiying the origin of direct emails - and SPF is easier to implement 
> for most administrators.

+1.

It basically (almost) turns DKIM into SPF. That's not that appealing a solution.

--Terry

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Nov 2016 09:30:13 -0500

> It basically (almost) turns DKIM into SPF. That's not that appealing a solution.

For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC 
or ARC for that matter since the receiver (at least ours) will never 
accept the payload anyway, i.e. it never gets to the SMTP "DATA" 
state.  SPF does not require you to accept the mail for the hard 
reject policy (-ALL).

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 17 Nov 2016 14:34:26 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Thursday, November 17, 2016 9:30 AM
> To: [email-masked]; Ietf Dkim
> >> email leaves the ADMD boundary. From a DMARC point of view DKIM will
> >> not be needed anymore because it has now the same function as SPF -
> >> verifiying the origin of direct emails - and SPF is easier to implement for
> most administrators.
> >
> > +1.
> >
> For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC
> for that matter since the receiver (at least ours) will never accept the payload
> anyway, i.e. it never gets to the SMTP "DATA"
> state.  SPF does not require you to accept the mail for the hard reject policy
> (-ALL).
> 

Hector, the reality is that most mailbox providers do not reject on SPF -all because so many senders don't understand what they are "saying" with -all and the mailbox providers are the ones who get the complaints about mail not getting delivered. THAT is reality.

Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Nov 2016 18:05:00 -0500

> Hector, the reality is that most mailbox providers do not reject on SPF -all because so many senders don't understand what they are "saying" with -all and the mailbox providers are the ones who get…

Is "MOST" 100%, 90%, 80%, 70%, 51%?  The fact is there are receivers 
that do reject on -ALL. Its doesn't matter if its 1%.  The specs has 
always allowed to be done and it is done.  That's the reality. All 
systems need to be ready to handle that situation.  The payload isn't 
even transferred. In the 13 years implementing it, I can't even recall 
one false positive. Another point is that many domains have switched 
their early SoftFail or Neutral setup to Hardfail for the primary 
purpose of rejection despite how a receiver will actually do 
rejection.  A good majority of high value domains are Hard Fails and 
have been for a number of years.  I just don't buy that the notion 
that senders don't know what they are doing.

In any case, my main point is that if you use SPF -ALL, you can bypass 
lots of unnecessary overhead processing in DKIM/DMARC or any related 
payload technology.

-- 
HLS

---

From: Vladimir Dubrovin <[email-masked]>
Date: Mon, 21 Nov 2016 12:48:06 +0300

> state.  SPF does not require you to accept the mail for the hard

SPF "-all" doesn't protect against spoofing attack, SPF only protects
SMTP envelope which is normally not visible to user. DMARC does.

P.S. Murray, may be it's better to add an option to DKIM-Signature or to
_dmarc DNS record to indicate some mechanism (DKIM or SPF) should not be
used for DMARC verification? It will work in absolutely same way.
draft-kucherawy-dmarc-rcpts  is an equivalent to DMARC with disabled
DKIM authentication.

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Nov 2016 08:10:23 -0500

> draft-kucherawy-dmarc-rcpts  is an equivalent to DMARC with disabled

Or, if you don't want people to use DKIM for DMARC, don't sign the message.

Scott K