Opened 8 years ago

Last modified 22 months ago

#2 infoneeded defect

Flow of operations text in dmarc-base

Reported by: superuser@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #3 (changes to DMARC base spec + DMARC Usage Guide
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

To: dmarc@…
From: Anne Bennett <anne@…>
Date: Fri, 16 Jan 2015 19:26:41 -0500
Subject: [dmarc-ietf] Flow of operations text in -12

In draft 12, Section "4.3 Flow Diagram", we have text which
I think is somewhat contradicted by text in the later and
more detailed "6.6. Mail Receiver Actions", in particular
with respect to parallelizing some of the checks, and there's
another small problem with the text as well. Quoting 4.3:

  1. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain's DNS data (when identifiers are aligned; see below).

... but the "Author Domain" (based on RFC5322.From) is not
necessarily the domain that will be queried by SPF and DKIM
checks, and we won't know if identifiers are aligned until we
look at the results of:

  1. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)

"6.6.2" shows clearly that the SPF check (with its DNS queries),
the DKIM checks (with its DNS queries), and the DMARC policy
determination (with its DNS queries) can be done in parallel, and
their results combined when all have arrived, and I imagine that
will turn out to be the best way to do it.

So 4.2 could perhaps be modified:

  1. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to DNS data. The results of these checks are passed back to the DMARC module.
  1. Meanwhile, the DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)

Change History (10)

comment:1 Changed 5 years ago by kboth+ietf@…

  • Component set to dmarc-future-notes

comment:2 Changed 3 years ago by seth@…

  • Component changed from dmarc-future-notes to dmarc-bis

comment:3 Changed 2 years ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from new to accepted

comment:4 Changed 2 years ago by todd.herr@…

There's a whole lot wrong with the existing Flow Diagram ascii-art that, in my opinion, it might be worth considering throwing it out all together.

Here's the existing diagram:

~~~ ascii-art
 +---------------+
 | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
 +---------------+                        .           .         .
     |                                    .           .         .
     V                                    V           V         .
 +-----------+     +--------+       +----------+ +----------+   .
 |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
 |  Service  |     | Signer |       | Verifier | | Verifier |   .
 +-----------+     +--------+       +----------+ +----------+   .
     |                                    ^            ^        .
     |                                    **************        .
     V                                                 *        .
  +------+        (~~~~~~~~~~~~)      +------+         *        .
  | sMTA |------->( other MTAs )----->| rMTA |         *        .
  +------+        (~~~~~~~~~~~~)      +------+         *        .
                                         |             * ........
                                         |             * .
                                         V             * .
                                  +-----------+        V V
                    +---------+   |    MDA    |     +----------+
                    |  User   |<--| Filtering |<***>|  DMARC   |
                    | Mailbox |   |  Engine   |     | Verifier |
                    +---------+   +-----------+     +----------+


  MSA = Mail Submission Agent
  MDA = Mail Delivery Agent
~~~

The above diagram shows a simple flow of messages through a DMARC-
aware system. Solid lines denote the actual message flow, dotted
lines involve DNS queries used to retrieve message policy related to
the supported message authentication schemes, and asterisk lines
indicate data exchange between message-handling modules and message
authentication modules. "sMTA" is the sending MTA, and "rMTA" is the
receiving MTA.

Several things wrong:

  1. SPF Verifier DNS query doesn't necessarily go to the author domain
  2. DKIM Verifier DNS query(s) won't necessarily all go to the author domain
  3. SPF, DKIM, and DMARC Verifier checks just as likely to be done by rMTA as by MDA Filtering Engine, as it's much easier to enforce SPF "-all" and DMARC p=reject there

Perhaps tossing the ASCII Art entirely and just documenting the flow is the right approach?

comment:5 Changed 2 years ago by todd.herr@…

As for documenting the flow, right now there are ten steps listed after the ASCII art:

  1. Domain Owner constructs an SPF policy and publishes it in its

DNS database as per [@RFC7208]. Domain Owner also configures its
system for DKIM signing as described in [@RFC6376]. Finally, Domain
Owner publishes via the DNS a DMARC message-handling policy.

  1. Author generates a message and hands the message to Domain

Owner's designated mail submission service.

  1. Submission service passes relevant details to the DKIM signing

module in order to generate a DKIM signature to be applied to
the message.

  1. Submission service relays the now-signed message to its

designated transport service for routing to its intended
recipient(s).

  1. Message may pass through other relays but eventually arrives at

a recipient's transport service.

  1. Recipient delivery service conducts SPF and DKIM authentication

checks by passing the necessary data to their respective
modules, each of which requires queries to the Author Domain's
DNS data (when identifiers are aligned; see below).

  1. The results of these are passed to the DMARC module along with

the Author's domain. The DMARC module attempts to retrieve a
policy from the DNS for that domain. If none is found, the
DMARC module determines the Organizational Domain and repeats
the attempt to retrieve a policy from the DNS. (This is
described in further detail in (#policy-discovery).)

  1. If a policy is found, it is combined with the Author's domain

and the SPF and DKIM results to produce a DMARC policy result (a
"pass" or "fail") and can optionally cause one of two kinds of
reports to be generated (not shown).

  1. Recipient transport service either delivers the message to the

recipient inbox or takes other local policy action based on the
DMARC result (not shown).

  1. When requested, Recipient transport service collects data from

the message delivery session to be used in providing feedback
(see (#dmarc-feedback)).

I'm wondering if parts of steps 1-4 could be used to beef up the existing Domain Owner Actions section and the rest of the steps could just be tossed, since Mail Receiver Actions does a better job (IMHO) of capturing them.

comment:6 Changed 22 months ago by johnl@…

This looks like the right direction. I agree the chart needs to be simpler, and in practice DMARC is usually handled in the rMTA, not the MDA. I don't see how you could do p=reject in the MDA without a lot of spam blowback.

comment:7 Changed 22 months ago by todd.herr@…

  • Status changed from accepted to started

comment:8 Changed 22 months ago by todd.herr@…

  • Status changed from started to infoneeded

Proposed updated ASCII art for mail flow.
Proposed stripped down description of ASCII art.
Proposed new text for Domain Owner actions.

comment:9 Changed 22 months ago by todd.herr@…

  • Status changed from infoneeded to assigned

Pushed to github and merged to main branch

comment:10 Changed 22 months ago by todd.herr@…

  • Status changed from assigned to infoneeded
Note: See TracTickets for help on using tickets.