Re: [dmarc-ietf] auth-res vs. dmarc

[Hector Santos <[e-mail]>]

On 12/28/2020 8:17 AM, Todd Herr wrote:
> On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     I installed this handy dandy t-bird dkim verifier extension which
>     also
>     allows you to just use the upstream auth-res.  After fixing a bug
>     in it,
>     I could see that it lists DMARC as a fail when DKIM failed, but SPF
>     passed. The _dmarc record has p=none, so it seems really odd to call
>     that a DMARC failure. Shouldn't it just be using the appropriate
>     p= tag
>     instead of "fail"? Is this left over from when Auth-res was mainly
>     for dkim?
>
>
> A DMARC pass verdict requires not only that SPF or DKIM pass, but also
> that the SPF or DKIM domain in question align with the DMARC
> (RFC5322.From) domain. A message such as the following:
>
>   * Return-Path: <[e-mail] <mailto:[e-mail]>>
>   * DKIM domain: b.org <http://b.org>
>   * From: [e-mail] <mailto:[e-mail]>
>
> Can get an SPF pass for a.net <http://a.net> and have its DKIM
> signature validate, but still fail DMARC for c.com <http://c.com>
> because neither a.net <http://a.net> nor b.org <http://b.org> align
> with c.com <http://c.com>.
>
> Can you share the example auth-res header(s) in question along with
> the DMARC policy record(s) for the message(s)?
> --

FWIW....

For your message, the wcSMTP MDA verified and produced the follow AR 
for you:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  dmarc=fail policy=none author.d=dmarc.ietf.org signer.d=ietf.org 
(unauthorized signer);
  dkim=fail (DKIM_SIGNATURE_BAD) header.d=ietf.org header.s=ietf1 
header.i=ietf.org;
  dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=ietf.org (unauthorized signer);
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=valimail.com 
header.s=google2048 header.i=valimail.com;
  dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=valimail.com (unauthorized signer);

bottom up read,

By the time your message (my list copy) was echoed to me, as expected 
with the ietf.org MLM, your original body integrity was lost, hence a 
body-mismatch will be detected with all downlink DKIM verifiers.

The original DKIM idea for MLM correction (or middle-ware in general) 
was to perform a resigning by the MLM as a 3rd party signer. But we 
never corrected the authorization protocol for the 3rd party signers 
like is done with SPF allowing for 3rd party mailers to exist within 
it output mail sender framework.

Here is the problem with rewriting which the AR recorded illustrates 
-- who is the POLICY holder here?  You or the IETF (ietf.org or 
dmarc.ietf.org)?

Valmail.com does not have a policy, like ATPS, that will authorized 
ietf.org or dmarc.ietf.org as a resigner.   If you had this zone record:

;
; DMARC/ATPS Zone Records for author-domain: valimail.com
; Generated by wcMakeDMARC v4.00 (c) copyright 2020 Santronics 
Software, Inc.
; See https://secure.winserver.com/public/wcdmarc
;

_dmarc TXT ("v=dmarc1; p=reject; atps=y; asl=ietf.org,dmarc.ietf.org;")

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
xxv4fo4ieaguvlupvusha3j2x7ici4za._atps  TXT ("v=atps01; 
d=dmarc.ietf.org;")

Then our wcDMARC verifier would validate your message and stamp the AR 
with an authorized resigner data bit.  However, this is true when 
rewriting is not applied.

In practice, we have a "contract" as a list member to accept what the 
IETF MLM does, to a degree, to receive its output. But I don't expect 
any original protection to be lost.  Valimail.com was protected on 
input.  On output, it was no longer protected once it passes through 
the IETF MLM.

Consider a rewrite is not correct when it used two different domains. 
My understanding for the intent of this unfortunate introduction into 
the mail world, the whole point was make it a 1st party signature so 
that the author and signer identities matched:

ADID  Author Identity: dmarc.ietf.org
SDID  Signer Identity: ietf.org   <--- SHOULD BE signed by dmarc.ietf.org

Even if it was signed by dmarc.ietf.org, its DMARC policy is p=none, 
so who cares what is done with valimail.com messages?  Product 
engineering common sense is to not destroy the original policy 
protection Valimail.com had. If the rewrite logic is going to be 
applied only when an incoming domain has a DMARC p=reject|quarantine 
policy, then the rewrite MUST have a matching level of protection when 
it changes the author identity To me, this is the only possible way 
for a rewrite mlm logic to minimize the damage created by destroying 
the original intent and protection of a DMARC-based restricted domain.

This failure is feeding any anticipated growth for "Deep AI Mail 
engines"  that indicate valimail.com has a significant failure rate, 
100% of the time coming out of the IETF.

If I was valimail.com, as a product developer, you should support the 
easy ATPS protocol. Just add the domains you want to authorized as a 
resigner and hopefully with ATPS endorsement by ValiMail, adding it to 
your product line will give you and customers protection, immediately, 
in the eyes of my wcDMARC receivers and verifiers.

BTW, these are my authorized 3rd party resigners for my personal 
sandbox domain: isdg.net

kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos