On 12/28/2020 8:17 AM, Todd Herr wrote:
On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas <[email protected]
<mailto:[email protected]>> 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: <[email protected] <mailto:[email protected]>>
* DKIM domain: b.org <http://b.org>
* From: [email protected] <mailto:[email protected]>
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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
