Re: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization

[Дилян Палаузов <[e-mail]>]

Hello Seth,

> - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5

The original email is https://mailarchive.ietf.org/arch/msg/dmarc/fRogXZnH2H9IEQyf_UXPx1_KLvE, which references section
5.3 of https://tools.ietf.org/html/draft-kucherawy-dmarc-base-09#section-5.3, which today 
https://tools.ietf.org/html/rfc7489#section-6.3 (Section 6.3 of RFC 7487).

This might be also related to https://trac.ietf.org/trac/dmarc/ticket/22 , but it does not contain the word “testing” as
purpose.

My concerns:

For the purpose of running a test system, one wants to receive all reports, individual or aggregate, whenever a problem
appears.  "p=quarantine; pct=1" would send a report whenever a problem appears, but has as side effect, that some bad
emails (1%) will be quaratined.

This test system is supposed to do MLM rewritings, just as normal NON-test system will do, in order to test the whole
delivery chain.

The combination to have a system, that just sends (individual or aggregate) reports on failures, which does not impact
anyhow mail delivery, is “p=quarantine; pct=0;”.  Currently it is not defined, what that last policy shall mean and
there is not policy that just sends reports, but otherwise 100% delivers the emails properly.  So "p=reject; pct=0;"
just fits.  Now, I do not recall if "p=none;", with or without pct does sends reports…

-----

RFC 6651 defines r=y to send a report whenever a DKIM-Signature fails.  When a MLM rewrites a mail, and changes From:,
DMARC for the new email does validate, however the untouched DKIM-Signature fails.  The current recommendation is to
generate a report for the failed signature.  This report is useless and distracts from useful reports. The report is
useless, because the MLM intentionally broko the DKIM signature and there is nothing the sender of the email can do and
also there is no way how this report can be tackled.

So for DMARC to function fluently, there shall be no distracting DKIM reports.  Whether this is DKIM or DMARC domain
does not matter.  The topic was discussed at [e-mail] (https://mailarchive.ietf.org/arch/browse/ietf-dkim/) in
Augist - October 2018.

Regards
  Дилян





On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote:
> With the group officially in Phase III of the DMARC WG charter, our work is now to explicitly review and refine the DMARC specification, with the goal of generating a standards track document.
> 
> The draft-ietf-dmarc-psd experiment is part of this process, as is the conversation about defining proper ARC reporting XML for DMARC reports.
> 
> This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which you believe should be officially discussed as part of the DMARCbis process. Please start a separate thread for each item you have. I'll make sure all are properly in the issue tracker and get addressed.
> 
> Please send in your items no later than *Friday, May 24th*. After this point, we'll be focusing on progressing the DMARCbis process, not gathering new issues.
> 
> Below are a list of nits already in the datatracker. I'll be kicking off threads for several other issues I'm aware of shortly.
> 
> Thanks everyone!
> 
> Seth, as Secretary
> 
> Active issues for DMARCbis in the data tracker:
> - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1
> - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2
> - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2
> - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4
> - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5
> - Fuzzy normative language around filenames: https://trac.ietf.org/trac/dmarc/ticket/6
> - ABNF for dmarc-record is slightly wrong: https://trac.ietf.org/trac/dmarc/ticket/7
> - Perverse incentives to use p!=none & pct=0: https://trac.ietf.org/trac/dmarc/ticket/22
> - objection to maintaining registry for all participating public suffixes: https://trac.ietf.org/trac/dmarc/ticket/24
> - Link to "URI" reference broken in several sections: https://trac.ietf.org/trac/dmarc/ticket/25
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc