Before I start, I'll say I've read most (90%) of the archives ;).  The
following is a proposal to create a second identifier within DMARC, it
is not an attempt to become a FUSSP.   It's only a way for an ADMD to
have more granular control over email messages.

The purpose is to allow consistent administrative control over
authorized messages that have partial alignment.

Given that:

  * Whitelisting mailing lists is really the only way to get DMARC to
work with messages forwarded by lists.

  * The presence of the DMARC record (and is anything other than
p=monitor), overrides ADSP and SPF-all

  * The sender who is interested in this proposal likely knows all
their sending MTAs (therefore is SPF [hyphen] -all candidate), but at
the same time that user doesn’t know all the IPs for mailing lists
users send to (therefore a SPF [tilde] ~all candidate)

  * The DMARC "p" parameter, as currently defined, requires alignment
of *BOTH* SPF and DKIM.  Therefore any policy defined is really only
suitable to transactional emails


Recent discussion on this mailing list has focused on three types of
messages that relate to DMARC:

   1) Full Alignment: Transactional email, that is handled by the
current version of the draft.

   2) Partial Alignment: SPF pass DKIM Pass where SPF might fail if a
mailing list is used.

   3) No Alignment: Unix .forwards and mailing lists that don't add
DKIM signing. (Notably this is not represented by the software John
Levine uses)

This proposal is to address the problem where the domain owner wants
to apply policy through the widely publicized DMARC mechanism instead
of ADSP.

We all know that the "p=" parameter applies policy when either the SPF
check or DKIM signature fails.  I'm suggesting that a "p2=' parameter
be created to match a DKIM alignment and a SPF fail.  It is
conceivable that a "p1=" parameter be created for occasions when the
SPF aligns and DKIM fails.

Considering that ADMDs with end users (Read: non-transactional) will
likely only ever deploy "p=monitor" DMARC records, this proposal will
will maintain compatibility with existing DMARC deployments.  Since
I'm asking for new parameters to be adoped and defined, I'd suggest
that  "p1=" and "p2=" parameters can appear in any order and will take
precedent over a "p=" parameter.  A DKIM DNS record would then look
something like this

     % dig +short TXT _dmarc.example.com.
     "v=DMARC1\; p=monitor\;p2=quarantine\;
rua=mailto:[email protected]";

It would appear this way in a zone file:

  ; DMARC record for the domain example.com
     _dmarc  IN TXT ( "v=DMARC1; p=monitor; p2=quarantine;"
                      "rua=mailto:[email protected]"; )

This change will require DKIM administrators to think about which
policy they want applied, and will allow for a more flexible
deployment overall.

Lastly, I know that DMARC is not intended to be tied to SPF and DKIM
directly, and suggest that "p1" be a validation of the envelope, and
"p2" be validation of the body.  This would then allow "p=" to be
defined as a combination of "p1" and "p2", or perhaps a forward
looking "p*=" that would include a "p3=" if such a concept were to be
created or exist.

One idea for a "p3=" would be messages that are determined to come
from a whitelisted mailing list.  Considering that each installation
maintains their own lists of mailing list outbound IP (google groups,
etc) it may be beneficial for an ADMD to tell the receiving MTA how to
treat that message outside of standard handling.

Thank you in advance for your constructive feedback.


Chris
PS - I'm in Cancun so I don't have reliable Internet access and may
not be able to reply again for some time.

_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Reply via email to