For evaluators, the implementation discussion could be structured by the
degree of information shared with senders:

- No sharing
Recipient uses DMARC for its own disposition decisions only.   Scope
elements include:
 Ability to process a PSL on a recurring basis
 Ability to apply DMARC policy to a message to determine sender-recommended
disposition
 Ability to configure local policies to override sender disposition when
desired.

- Limited sharing:  Recipient returns SMTP extended status codes related to
sender authentication.

- Basic Feedback:   Recipient sends RUA reports.  Scope elements include
  Extended parsing of messages
  Database to collect message data
  Report generator to process message data
  Delivery system to post report data to email
  Tools to purge database of obsolete information

- Extended Feedback:  Recipient is also able to send RUF reports when these
are determined to be appropriate.


On Tue, Sep 7, 2021 at 3:16 PM Todd Herr <todd.herr=
[email protected]> wrote:

> Greetings.
>
> Previous discussion of this issue a couple of weeks ago seemed to land on
> the idea that the text in Section 8 of the current rev of the draft, titled
> "Minimum Implementations", was problematic in its content and there was a
> suggestion that perhaps the text could be softened and moved to a summary
> section.
>
> I'm writing today to seek guidance from the working group as to what such
> a summary section might be.
>
> At first blush, it might seem that the current Section 9, "Other Topics",
> might be a place for a summary discussion of "Minimum Implementations";
> however, the introductory text for Section 9 currently reads "This section
> discusses some topics regarding choices made in the development of DMARC,
> largely to commit the history to record." and so "Minimum Implementations"
> might not fit.
>
> Another choice might be to leave "Minimum Implementations" as a standalone
> section, but soften the language, particularly in regards to removing
> reporting as a MUST and addressing John and Ale's concerns about requiring
> the p= value to be other than none, along with other concerns raised.
>
> A third option might come from consensus from the group, rejecting either
> of the two options I've proposed above but instead landing on a new one.
>
> Thank you for your time, and I look forward to your input.
>
> --
>
> *Todd Herr* | Technical Director, Standards and Ecosystem
> *e:* [email protected]
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to