Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Seth Blank <[e-mail]>]

As an individual, +1000 to Scott.

As Chair, this thread is unproductive, and two months passed due date to
resolve. Consensus seems clear that there isn't an issue here. If there's a
clear use case that hasn't been communicated, share it now or move on.

Seth

On Fri, Feb 12, 2021 at 10:02 AM Scott Kitterman <[e-mail]>
wrote:

> I didn't miss it.  I don't think it's meaningful.
>
> In the real world, outside the IETF one of three things happens:
>
> 1.  Everything works fine.
>
> 2.  Someone depends on HELO evaluation of SPF and discovers from
> evaluating
> the feedback reports that's it's a problem and then doesn't to that
> anymore.
>
> 3.  Someone depends on HELO evaluation of SPF and doesn't discover it's a
> problem because they don't look at their feedback reports.
>
> For case 1 and 2, there's no issue.
>
> Case 3 doesn't care if their mail gets delivered, so its fine.
>
> This excessive focus on irrelevant minutia is harmful to the IETF.  It
> makes
> participation less interesting for technically capable contributors and
> reduces the overall value of the discourse.
>
> Many people have suggested we move on.  My prediction is you won't, but
> this
> is my last email on the topic.
>
> Scott K
>
> On Thursday, February 11, 2021 11:24:16 PM EST Douglas Foster wrote:
> > You missed my main point.   I will restate it, and then address your
> threat
> > question.
> >
> > If there are N ways to establish authentication, then a recipient only
> > needs to choose one of them, but a sender who wants to be validated by
> all
> > recipients must implement all of them.   One purpose of the specification
> > is to constrain that complexity.
> >
> > So the convenient solution would be to say that SPF HELO must be ignored,
> > except for null sender, because doing so reduces the number of variables
> > that must be considered by senders.   It is also probably consistent with
> > the logic of many current implementations.   I just do not believe that
> it
> > is justified to tell recipients that they MUST NOT evaluate SPF HELO when
> > MAILFROM is present.
> >
> > An alternative would be to say that SPF HELO and SPF MAILFROM should both
> > be evaluated.   In the long run, this is arguably the best theoretical
> > solution, but the fear of short-term pain from false positives probably
> > makes this unattractive.
> >
> > So, I am back to the only solution that seems justifiable:    Senders
> > SHOULD comply with both MAILFROM and HELO policies because SOME
> recipients
> > may evaluate both criteria, but many will only evaluate MAILFROM because
> > the incremental theoretical benefit seems less than the incremental cost.
> >
> > - - -
> >
> > To your point about threat vectors:  DMARC alignment is based on nested
> > layers of trust, and the trust is broken if you skip layers.  The server
> > operator provides a mail server environment to a mail domain, and the
> mail
> > domain provides delivery services for an author.
> >
> > SPF proves that the mail domain (indicated by the MAILFROM address)
> really
> > uses the services of the server domain, and therefore the server
> (indicated
> > by IP address, HELO, and possibly ReverseDNS) is authorized to send
> > messages on behalf of the mail domain.
> >
> > DMARC proves that the source server for the message was authorized to
> speak
> > on behalf of the author (indicated by the From address).
> >
> > You suggest that if SPF HELO passes, and aligns with FROM, then we have
> > established that the server is authorized to speak for the author.   This
> > is true, but it does not establish that the mail domain in the MAILFROM
> > address has that right.
> >
> > When the MAILFROM domain is different from the HELO domain, this implies
> > that that MAILFROM domain is a client of the server domain.   The server
> > domain has the right to emit messages for the client, but the client
> domain
> > does not have the right to email messages claiming to be from the server
> > domain.
> >
> > - - -
> >
> > It can be asserted that the server domain should be able to use its
> > firewall to prevent unauthorized servers from emitting mail, and should
> be
> > able to use its outbound gateway to prevent client domains from emitting
> > messages from the server domain, other clients, or any unrelated domain.
> > These commonly implemented measures could eliminate the need for checking
> > SPF HELO.   Why should others check what the sender should be able to do
> > for themselves?
> > Are we prepared to make this argument?   If so, then the existing wording
> > stands, but needs a solid justification.
> >
> > DF
> >
> > On Thu, Feb 11, 2021 at 8:50 AM Scott Kitterman <[e-mail]>
> >
> > wrote:
> > > What problem are you purporting to solve?
> > >
> > > By problem, I mean a case were a bad actor can get a DMARC pass result
> if
> > > SPF
> > > HELO results are allowed to be used that they couldn't already get
> with a
> > > mail
> > > from result.
> > >
> > > I don't think such a case exists which is why I think this entire line
> of
> > > argument is a waste of time.
> > >
> > > Scott K
> > >
> > > On Thursday, February 11, 2021 6:35:49 AM EST Douglas Foster wrote:
> > > > Applying SPF to DMARC could become out of scope, if we choose to
> remove
> > >
> > > SPF
> > >
> > > > from DMARC and make it dependent only on DKIM.   Until then, we need
> to
> > > > have a shared understanding of how SPF is applied.  This question
> asks
> > > > whether that shared understanding exists.
> > > >
> > > > SPF involves two tests, which can be used together.   This WG can
> insist
> > > >
> > > > that for DMARC purposes, only one can be used:
> > > >     "When the sender is not null, DMARC-evaluation only considers the
> > > >     SPF
> > > >
> > > > evaluation of the MAILFROM Address.   SPF evaluation of HELO MUST
> NOT be
> > > > considered for DMARC purposes."
> > > >
> > > > This wording seems implied by the current language, and by those who
> > > > want
> > > > to leave it untouched.  Implication is different from specification,
> so
> > >
> > > our
> > >
> > > > document should make this explicit.   Unfortunately, an explicit MUST
> > > > NOT
> > > > requirement is hard to justify.   When two domains are involved, and
> > > > both
> > > > domains have published policy information, what justification exists
> for
> > > > ignoring some of the available security-related information?
> > > >
> > > > If we back away from MUST NOT, then we have to consider that some
> > > > recipients MAY evaluate SPF HELO and SPF MAILFROM together, just as
> the
> > >
> > > SPF
> > >
> > > > RFC expected them to be used, and as outlined in one of my examples.
> > >
> > > If
> > >
> > > > some recipients MAY evaluate HELO, then senders SHOULD take care to
> > >
> > > ensure
> > >
> > > > that HELO will generate a PASS.   Our language becomes something like
> > >
> > > this:
> > > >     "When the sender is not null, DMARC-evaluation always uses the
> SPF
> > > >
> > > > evaluation of the MAILFROM Address.   Some recipients may evaluate
> SPF
> > >
> > > HELO
> > >
> > > > as well.   To maximize recipient trust, senders SHOULD publish an SPF
> > > > policy which ensures that both MAILFROM and HELO will produce SPF
> PASS
> > > > results."
> > > >
> > > > DF
> > > >
> > > > On Wed, Feb 10, 2021 at 6:29 PM Dave Crocker <[e-mail]>
> wrote:
> > > > > On 2/10/2021 3:24 PM, Douglas Foster wrote:
> > > > > > Huh?  Are you asserting that SPF MAILFROM and SPF HELO are
> > > > > > interchangeable?   They are not, but they can work together.
> > > > >
> > > > > Perhaps I misread, but I thought I saw that this really is out of
> > > > > scope
> > > > > for this working group.
> > > > >
> > > > >
> > > > > d/
> > > > >
> > > > > --
> > > > > Dave Crocker
> > > > > [e-mail]
> > > > > 408.329.0791
> > > > >
> > > > > Volunteer, Silicon Valley Chapter
> > > > > American Red Cross
> > > > > [e-mail]
> > >
> > > _______________________________________________
> > > dmarc mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dmarc
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [e-mail]
*p:* 415.273.8818

`

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.