I, too, prefer MUST to SHOULD there, but it was clear to me that we
will not reach rough consensus on MUST, but that we can reach rough
consensus on SHOULD.

I do like your suggestion of silent discard rather than bounce, and I
would want to see that change made -- perhaps with a note that
aggregate reports will still include information about those discards.

Barry

On Fri, Jul 7, 2023 at 9:03 AM Baptiste Carvello
<devel2...@baptiste-carvello.net> wrote:
>
> Hi,
>
> I consider this a step backwards. The MUST requirement on the author
> domain finally made it clear, after a lost decade, *who* is responsible
> for solving the breakage of indirect mailflows. Problem solving starts
> with acknowledging one's responsibilities.
>
> This proposal goes back to a muddy shared responsibility between the
> author domain and the mail receiver. This is the best way to make sure
> nothing changes, as each waits for the other to act. Mailing lists can
> expect to suffer for more long years. No wonder the From-munging
> proponents are rejoicing!
>
> If this goes in, at least something has to be done to reduce bounces,
> such as:
>
> — Section 8.3 —
>
> ADD
> The Mail Receiver MUST reject with "silent discard" when rejecting
> messages with a List-Id header.
> END
>
> That way, each party's choices will mostly impact their own messages.
> Mailing list operators can then take a step back, undo any ugly
> workarounds, and let DMARC participants decide between themselves, on a
> case by case basis, how they solve *their* deliverability problems.
>
> Cheers,
> Baptiste
>
> Le 06/07/2023 à 16:55, Barry Leiba a écrit :
> > I had some off-list discussions with Seth, who was very much against
> > my original proposed text, and he suggested an alternative
> > organization that would be more palatable to him.  I've attempted to
> > set that out below.  The idea is to remove the normative requirements
> > about using p=reject from Sections 5.5.6 and 5.8, and instead put a
> > broader discussion of the issues, along with the normative
> > requirements, into a new "Interoperability Considerations" section.
> > This makes it explicitly clear that any MUST/SHOULD stuff with regard
> > to using and honoring p=reject is an issue of interoperating with
> > existing Internet email features.  I can accept that mechanism also,
> > and so, below is my attempt at writing that proposal up.
> >
> > Barry
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to