Subject: [dmarc-ietf] DMARC failure scenarios

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 18 Aug 2020 01:56:12 GMT

Does this scenario correctly characterize how organizations may be unable to move past p=none with breaking things?

Before DMARC
--------------------

a) A vendor application detects an event, looks up in a database for sender name (client contact) and recipient list.

b) The application connects to a mail server via IMAP, and sends the message using something like application@vendordomain for the SMTP from and cllentcontact@clientdomain as the Message from.    The client domain becomes especially important if the recipients are in a different domain than the client.   An example might be an HVAC system operated by a vendor, on behalf of the building manager, which needs to communicate with the building tenants.   The message passes SPF based on the SMTP From address in the vendor domain.   The client domain is not enforced.

All of this can be implemented with generic off-the-shelf technology.

Then the client wants to implement DMARC
----------------------------------------------------------

d) The client develops a list of all of its third-party mailers and tells the third parties to begin applying the client's DKIM signature to their messages.   This adds a boatload of complexity to the vendor's application, since he needs a different applied signature for each client.   It requires either major changes to the application, a more sophisticated mail server, or a special box simply to sit in front of the mail server to detect and apply the correct signature.  None of these seem like generic off-the-shelf solutions.   I would not know where to buy that capability if I needed it today.

e) If the client attempts to comply, it may take a long time and add a lot of cost.   If the client cannot comply, switching vendors is also complex and time consuming.

So in the end, a hypothetical U.S. government agency may end up telling Homeland Security that it cannot meet the DMARC deadline because of an application that runs in Peoria Illinois which cannot implement DKIM delegation signing.   Of course, if that does not fly, the p=reject goes into effect anyway and the folks in Peoria hope that the intended recipients will implement an exception in their incoming gateway.

In sum, DMARC participation is not fully in the control of the organization that wants to implement it.    We need to make DMARC participation a process where the participating organization has control over its own success and carries the costs of becoming compliant.   DKIM scope delegation does not get us there.

DF

---

From: "John Levine" <[email-masked]>
Date: 17 Aug 2020 22:12:01 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

As far as I can made sense of it, no.

>b) The application connects to a mail server via IMAP, and sends the message using something like application@vendordomain
>for the SMTP from and cllentcontact@clientdomain as the Message from.    The client domain becomes especially important if
>the recipients are in a different domain than the client.   An example might be an HVAC system operated by a vendor, on
>behalf of the building manager, which needs to communicate with the building tenants. ...

Again, no. You're confusing submission with SMTP. I have a printer
that sends me e-mail when it's out of paper, which it does by sending
mail to my submission server, not directly to me.  If I were checking DMARC
on the messages, they would easily pass since the submission server adds
DKIM signatures.

>d) The client develops a list of all of its third-party mailers and tells the third parties to begin applying the client's
>DKIM signature to their messages.   This adds a boatload of complexity to the vendor's application, since he needs a
>different applied signature for each client.   It requires either major changes to the application, a more sophisticated
>mail server, or a special box simply to sit in front of the mail server to detect and apply the correct signature.  None of
>these seem like generic off-the-shelf solutions.   I would not know where to buy that capability if I needed it today.

Again, no. I believe that devices that send mail do what they've
always done, send it to a submission server for further delivery. The
"special box" has been there all along.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 Aug 2020 11:29:37 +0200

On Tue 18/Aug/2020 03:56:12 +0200 Douglas E. Foster wrote:

> d) The client develops a list of all of its third-party mailers and 
> tells the third parties to begin applying the client's DKIM signature 
> to their messages.   This adds a boatload of complexity to the 
> vendor's application, since he needs a different applied signature for 
> each client.   It requires either major changes to the application, a 
> more sophisticated mail server, or a special box simply to sit in 
> front of the mail server to detect and apply the correct signature. 
>   None of these seem like generic off-the-shelf solutions.   I would 
> not know where to buy that capability if I needed it today.
> 

It doesn't have to add much complexity.  My DKIM filter[*] looks up 
the signing domain in a configured folder where it can find the 
selector and the private key —actually a symbolic link.  The signing 
domain can be configured to be the domain of the From: field.

The app just has to use the client's domain for both the envelop and 
the header, which is actually simpler than the pre-DMARC case.

The client must publish the public key supplied by the vendor and 
include the vendor's SPF stuff in its record.  That's not automated, 
AFAIK, although dynamic DNS and suitable scripts could do.

Best
Ale
-- 

[*] http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#signing

---

From: "Douglas E. Foster" <[email-masked]>
Date: Tue, 18 Aug 2020 10:48:57 GMT

You cannot make sense of it, John.   I understand the difference between submssion and SMTP. 

The asserted increase in complexity is not from adding a single signature, it is the requirement to apply a different signature to every message depending on the generated From domain.    
Are applications like the one the Alessandro mentioned readily available and easily implemented, so that conditional signatures are no hindrance to DMARC compliance?   If so, is third-party cooperation easily achieved and no obstacle to DMARC implementation?    
These are questions for the consultants who have done a lot of this work.

DF

----------------------------------------
From: "John Levine" <[email-masked]>
Sent: 8/17/20 10:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] DMARC failure scenarios

R's,
John

---

From: Dotzero <[email-masked]>
Date: Tue, 18 Aug 2020 09:08:15 -0400

On Tue, Aug 18, 2020 at 6:49 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> The asserted increase in complexity is not from adding a single signature,
> it is the requirement to apply a different signature to every message
> depending on the generated From domain.
>
>    - Are applications like the one the Alessandro mentioned readily
>    available and easily implemented, so that conditional signatures are no
>    hindrance to DMARC compliance?
>    - If so, is third-party cooperation easily achieved and no obstacle to
>    DMARC implementation?
>

Not as a 3rd party, but we were  doing ad-hoc signing for a large number of
domains (hundreds) at our outbound border MTAs at scale -10s of millions of
messages an hour, with the ability to scale much much larger for holiday
peaks. This was done with both Ironport and MessgeSystems implementations.
It's literally a very little bit of logic and code. As long as you have the
private keys it's as simple as choosing the path to the correct signing key
based on having the From domain. This was at various points done in Python
and Lua.

Michael Hammer