Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

[Seth Blank <[e-mail]>]

You’re not hearing me— this is something that comes up frequently for
organizations working to implement DMARC. Others have confirmed on list.
This is not an academic concern, it’s an operational one as elevated by the
charter.

Your other examples you cited do not come up in practice as issues for
domain owners looking to do DMARC.

Yes, let’s get back to N.

S

Seth Blank | Chief Technology Officer
Email: [e-mail]


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.



On Sat, Apr 6, 2024 at 13:44 Scott Kitterman <[e-mail]> wrote:

> The same thing can be said for every step of email processing that comes
> before DMARC.  If I reject your mail due to your IP being on a block list,
> you
> also don't get DMARC feedback about it.
>
> It was long enough ago that I don't remember if it was RFC 7489 or early
> in
> this working group, but we did have extensive discussions about this
> before
> and that's how we got where we are.  I don't think there's a lot of value
> in
> redoing that discussion.
>
> I think your N=5 versus N=8 topic is more important and much more on topic.
>
> Scott K
>
> On Saturday, April 6, 2024 1:27:18 PM EDT Seth Blank wrote:
> > Scott, I disagree.
> >
> > SPF hardfail in a DMARC context is an operational issue that comes up
> with
> > some frequency for domain owners.
> >
> > We should have some minimal amount of clarifying text.
> >
> > S, individually
> >
> > Seth Blank | Chief Technology Officer
> > Email: [e-mail]
> >
> >
> > 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.
> >
> > On Sat, Apr 6, 2024 at 13:01 Scott Kitterman <[e-mail]>
> wrote:
> > > On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote:
> > > > Greetings.
> > > >
> > > > Issue 141 has been opened to collect ideas around the discussion
> about
> > >
> > > what
> > >
> > > > to say in DMARCbis (if anything) about honoring SPF records that end
> in
> > > > -all when SPF fails.
> > > >
> > > >
> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/141
> > >
> > > I don't really understand the need for this.  What to do when SPF
> produces
> > > a
> > > fail result is an SPF question.  Not a DMARC question.  Additionally,
> we
> > > have
> > > discussed this before.  Note that not even RFC 7208 tells receivers
> what
> > > to do
> > > with SPF fail.  It seems far, far out of scope to do so here.
> > >
> > > On the theory that the invocation not to relitigate things we've
> already
> > > gone
> > > through won't be honored entirely in the breach, can we not do this?
> > >
> > > Scott K
> > >
> > >
> > >
> > > _______________________________________________
> > > dmarc mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dmarc
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>