Subject: [dmarc-ietf] Third Party Sender DMARC Adaptations

From: Scott Kitterman <[email-masked]>
Date: Mon, 30 Mar 2015 14:35:01 -0400

I just ran across this one today in a third party non-spam email:

Return-Path: <[email-masked]>
...
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 
        d=email.mindbodyonline.com; 
        h=from:to:reply-to:subject:mime-version:content-type; s=smtpapi;
...
Received: from o2.email.mindbodyonline.com (o2.email.mindbodyonline.com 
[74.63.194.59])
...
From: "$CUSTOMER_FRIENDLY_NAME" <[email-masked]>
To: $DELIVERY_ADDRESS
Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS>

I know we've discussed this kind of thing before, but it's  the first time I've 
noticed it in the wild (not that I've been looking really hard).  They don't 
have a DMARC record published, so this may be in response to some other 
driver, but it works for DMARC:

SPF passes and aligns
DKIM passes and aligns.

Since they are using their own 5322.From, there's no issue with third party 
DMARC records.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Mon, 30 Mar 2015 12:01:07 -0700

> Received: from o2.email.mindbodyonline.com (o2.email.mindbodyonline.com 

It's the standard sendgrid setup.

It's not particularly difficult to make DKIM and SPF work if you have full
control over the domain name you're sending from (and some control
over the delivery path).

Cheers,
  Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 31 Mar 2015 05:00:43 +0900

> Reply-To: "$CUSTOMER_FRIENDLY_NAME" <$CUSTOMER_ADDRESS>

This won't work for a lot of mailing lists, though, because Reply-To
is munged to point to the list, and it is frequently a requirement of
such lists that $CUSTOMER_ADDRESS *not* be in Reply-To.

And although it gets the mail past DMARC, ISTR that in many cases (eg,
invoicing services) the client (ie, the billing firm) wants its
address in From, so it flunks the user requirements here, too.

I suspect that if this becomes common, it will play havoc with
recipient contact lists, too.

 > but it works for DMARC:

Sure, but that's the tail wagging the dog.  The point of DMARC is so
that people can put their addresses in From and be believed, not that
there are kludges to get your content past DMARC.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 30 Mar 2015 16:50:24 -0400

> there are kludges to get your content past DMARC.

I know this isn't any kind of solution for mailing lists.  It is something in 
use that works (FSVO works) for third party origination.

Presentation differs among MUAs, so it's hard to draw generalizations about how 
well that set of identities are presented to end users.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 31 Mar 2015 13:16:06 +0900

> Presentation differs among MUAs, so it's hard to draw
 > generalizations about how well that set of identities are presented
 > to end users.

I am not concerned here with presentation.  This is about requirements
by the *originator*.  Some originators think having their domain name
in From: matters, and life will be a lot easier for sysadmins if we
can find a way to let them put it there and still get the benefits of
DMARC.

(Or maybe I'm just sensitized to unreasonable user requirements having
just spent a couple messages trying to get Dr. Stallman to Learn to Stop
Worrying and Love Git.)

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Mar 2015 07:49:53 -0400

Don't quite get it, Scott.  There is no DMARC record so the 
transaction would be "DMARC indeterminate" -- no DKIM signing policy.

If it did have a DMARC record, in order for this transaction to DMARC 
pass, it would require relaxed alignments for SPF and DKIM:

    adkim=r
    aspf=r

Correct?

subdomains has more inherent "trust" than having completely different 
main domains.   The problem of course, DMARC excludes this legitimate 
3rd party signer possibility in its protocol.

-- 
HLS

On 3/30/2015 2:35 PM, Scott Kitterman wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 31 Mar 2015 12:45:29 -0400

>transaction would be "DMARC indeterminate" -- no DKIM signing policy.

I think it's called none, but the point is that as a third party sender, their setup can't get entangled with customer first party sender setup which might have DMARC. 

>pass, it would require relaxed alignments for SPF and DKIM:

Which is the default. 

>3rd party signer possibility in its protocol.

I've yet to see a proposal to include it which is both executable and doesn't defeat the purpose of DMARC. I agree it's a problem, but one that so far doesn't have an appropriate technical solution. 

Scott K

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 31 Mar 2015 19:40:20 +0200

On Tuesday, March 31, 2015 6:45 PM [GMT+1=CET], Scott Kitterman wrote:

> I've yet to see a proposal to include it which is both executable and
> doesn't defeat the purpose of DMARC. I agree it's a problem, but one
> that so far doesn't have an appropriate technical solution. 

What we don't have is a "socially appropriate" technical solution. But a "technically appropriate" technical solution yes there is: "Every resender[*] who invalidates the original Author's DKIM signature must take ownership of the Header-From and re-sign the message". Simple. Easy. But socially unacceptable (for now, at least) because of the expectations of several legacy mail usages.

[*] Given that said resenders are mostly non-human, but computer systems, they can be trivially programmed to behave in such a DMARC compatible way.

Regards,
J.Gomez

---

From: Google MtView <[email-masked]>
Date: Tue, 31 Mar 2015 15:56:26 -0700

> On Mar 30, 2015, at 9:16 PM, Stephen J. Turnbull <[email-masked]> wrote:
> 
> Scott Kitterman writes:

Dear Stephen,

A few providers at the IETF conference offered suggestions which might 
gain traction for reasons beyond those created by DMARC, such as XMPP
gateways.  Although having experience in reporting policy at scale, it 
seems providers creating issues for millions of users are equally 
unwilling to enhance policy feedback to mitigate DMARC's disruption of 
legitimate third-party services. An enhancement that was even offered 
on their behalf. 

Refusals along with a demand for hard data creates a barrier similar to 
doubt used to oppose global warming or tobacco controls.  By impacting 
such a large number of users, DMARC prevents retaining From Header field 
as the role of Author.  Only the Sender header field is able to offer 
DMARC's desired alignment requirements.  There is already support in MUAs 
to intelligently combine Sender and From based on domain alignments, 
which would be adequate for mailing-lists limited to subscribed users.

In the next few days, I'll post an I-D to expand on the basic idea about 
retaining and expanding discussion forums.

Regards,
Douglas Otis