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

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>As an individual, +1000 to Scott.

I've closed this ticket.  One down, a zillion to go.

R's,
John

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

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

[Seth Blank]

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 
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 
> >
> > 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 

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

[Scott Kitterman]

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 
> 
> 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.   

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

[Douglas Foster]

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 
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

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

[Scott Kitterman]

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  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
> > dcroc...@gmail.com
> > 408.329.0791
> > 
> > Volunteer, Silicon Valley Chapter
> > American Red Cross
> > dave.crock...@redcross.org




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

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

[Douglas Foster]

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  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
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Thu 11/Feb/2021 00:29:02 +0100 Dave Crocker 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.



They are not but they could be.


Perhaps I misread, but I thought I saw that this really is out of scope for 
this working group.



 2. Reviewing and improving the base DMARC specification

The working group will not develop additional mail authentication
technologies, but may document desirable uses of existing authentication
technologies.


Best
Ale
--















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

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

[Dave Crocker]

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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

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

[Douglas Foster]

Huh?   Are you asserting that SPF MAILFROM and SPF HELO are
interchangeable?   They are not, but they can work together.

Some scenarios to illustrate:

clientdomain.tld uses servers from hostingservice.tld
the spf for hostingservice.tld allows only server "mail.hostingservice.tld"
the spf ro clientdomain allows ANY server from hostingservice.tld

Case 1
server= mail.hostingservice.tld
SMTP = u...@clientdomain.tld
FROM= u...@hostingservice.tld

SPF HELO = PASS aligns with FROM, but this is not a valid alignment for
DMARC PASS.
Only SPF MAILFROM produces a correct result (SPF PASS but DMARC FAIL),
because the client domain is not authorized to send messages for the
hostingservice domain.
Ergo:   SPF HELO does not produce equivalent results to SPF MAILFROM

Case 2
server = nonmail.hostingservice.tld
SMTP = u...@cllientdomain.tld
FROM = u...@clientdomain.tld

SPF MAILFROM = PASS and aligns with FROM, so it appears to be a DMARC PASS.
But SPF HELO is a FAIL, because the SPF for HostingService.tld says that
this server never sends mail.
Ergo:  SPF HELO can be used along with SPF MAILFROM to produce a more
granular allow list then SPF MAILFROM alone.

DF

On Wed, Feb 10, 2021 at 9:43 AM Scott Kitterman 
wrote:

> No.  Sigh.  Let's try it again.
>
> Yes, one might actually use a HELO result for DMARC.  It gives you the
> same
> result as if mail from is null.  So what?
>
> No one has given us a case where an attacker could get a aligned SPF
> result
> based on HELO that they couldn't also get with mail from, so it doesn't
> matter.
>
> By problem, I mean an actual problem.  There aren't any.
>
> Scott K
>
> On February 10, 2021 9:49:46 AM UTC, Alessandro Vesely 
> wrote:
> >Just to clarify:
> >
> >
> >On Wed 10/Feb/2021 05:19:38 +0100 Scott Kitterman wrote:
> >> No one has demonstrated that if someone has implemented SPF (RFC
> >7208) without
> >> worrying about DMARC that there are any associated problems for
> >DMARC.
> >
> >
> >I think I did.  OpenDMARC, for example, seems to read a single result,
> >either
> >Authentication-Results: or Received-SPF:, assuming that it contains the
> >mfrom
> >identity unless empty.  Note that it has an option to disable SPF
> >entirely,
> >presumably as a means to tackle non-DMARC oriented SPF filters.
> >
> >Google apparently works similarly.  Given a valid helo and a neutral
> >mfrom, the
> >spf= clause of its (ARC-)Authentication-Results: only reports the
> >latter.  That
> >is to say, you need a non-RFC7208 compliant SPF filter to instruct
> >DMARC.
>
>
>
> ___
> 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

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

[Kurt Andersen (b)]

On Wed, Feb 10, 2021 at 6:43 AM Scott Kitterman 
wrote:

> No.  Sigh.  Let's try it again.
>
> Yes, one might actually use a HELO result for DMARC.  It gives you the
> same
> result as if mail from is null.  So what?
>
> No one has given us a case where an attacker could get a aligned SPF
> result
> based on HELO that they couldn't also get with mail from, so it doesn't
> matter.
>
> By problem, I mean an actual problem.  There aren't any.
>
> Scott K
>

The other issue that people who are continuing this thread are ignoring is
that changing 7208 is out of scope for this WG.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

No.  Sigh.  Let's try it again.

Yes, one might actually use a HELO result for DMARC.  It gives you the same 
result as if mail from is null.  So what?

No one has given us a case where an attacker could get a aligned SPF result 
based on HELO that they couldn't also get with mail from, so it doesn't 
matter.

By problem, I mean an actual problem.  There aren't any.

Scott K

On February 10, 2021 9:49:46 AM UTC, Alessandro Vesely  wrote:
>Just to clarify:
>
>
>On Wed 10/Feb/2021 05:19:38 +0100 Scott Kitterman wrote:
>> No one has demonstrated that if someone has implemented SPF (RFC
>7208) without
>> worrying about DMARC that there are any associated problems for
>DMARC.
>
>
>I think I did.  OpenDMARC, for example, seems to read a single result,
>either 
>Authentication-Results: or Received-SPF:, assuming that it contains the
>mfrom 
>identity unless empty.  Note that it has an option to disable SPF
>entirely, 
>presumably as a means to tackle non-DMARC oriented SPF filters.
>
>Google apparently works similarly.  Given a valid helo and a neutral
>mfrom, the 
>spf= clause of its (ARC-)Authentication-Results: only reports the
>latter.  That 
>is to say, you need a non-RFC7208 compliant SPF filter to instruct
>DMARC.



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

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

[Alessandro Vesely]

Just to clarify:


On Wed 10/Feb/2021 05:19:38 +0100 Scott Kitterman wrote:

No one has demonstrated that if someone has implemented SPF (RFC 7208) without
worrying about DMARC that there are any associated problems for DMARC.



I think I did.  OpenDMARC, for example, seems to read a single result, either 
Authentication-Results: or Received-SPF:, assuming that it contains the mfrom 
identity unless empty.  Note that it has an option to disable SPF entirely, 
presumably as a means to tackle non-DMARC oriented SPF filters.


Google apparently works similarly.  Given a valid helo and a neutral mfrom, the 
spf= clause of its (ARC-)Authentication-Results: only reports the latter.  That 
is to say, you need a non-RFC7208 compliant SPF filter to instruct DMARC.




On Tuesday, February 9, 2021 10:13:37 PM EST Douglas Foster wrote:

[...]

My interest is interoperability:We want recipient requirements and
sender compliance measures to align.

RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM
together.  An argument can be made that this is not necessary:   SPF
MAILFROM shows that the server is authorized to send messages for the
specific domain in the MAILFROM, while SPF HELO says only that the server
is authorized to send message for the server domain and an unknowable set
of other domains.



What unknowable set of other domains?  If the server has an SPF record, it 
presumably authorizes just its IP address(es).




Todd's assertion is that SPF HELO will cause an excessive number of false
positives.



I'd let Todd speak for himself, but I never saw that assertion.  Todd said the 
set of messages that would get a different DMARC status in case we linearize 
the spec is immeasurable  —which I believe is true, and a valid basis to carry 
out the linearization without fear of disruption.




A second assumption is that no significant recipients are evaluating SPF
MAILFROM and SPF HELO together in a way that would be of interest to
senders. This may also be true, but I don't think this is something that
can be tested.



It makes no sense to require both values to pass simultaneously.

Linearization would be that *any* validated identifier, as long as it's 
aligned, produces a DMARC pass.



Best
Ale
--














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

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

[Scott Kitterman]

No one has demonstrated that if someone has implemented SPF (RFC 7208) without 
worrying about DMARC that there are any associated problems for DMARC.  
Anything else about SPF is out of scope for this working group.

Scott K

On Tuesday, February 9, 2021 10:13:37 PM EST Douglas Foster wrote:
> The chairs can introduce another topic whenever they want.   This does not
> seem like a pre-requisite to any of the other pending topics.
> 
> My interest is interoperability:We want recipient requirements and
> sender compliance measures to align.
> 
> RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM
> together.  An argument can be made that this is not necessary:   SPF
> MAILFROM shows that the server is authorized to send messages for the
> specific domain in the MAILFROM, while SPF HELO says only that the server
> is authorized to send message for the server domain and an unknowable set
> of other domains.  Therefore a PASS from SPF MAILFROM should make SPF HELO
> unnecessary and redundant.Does either the DMARC document or the SPF
> document say this anywhere?
> 
> RFC 7208 can be misunderstood to suggest that SPF MAILFROM and SPF HELO are
> equivalent and interchangeable, which they are not, for the reason just
> mentioned.   Shouldn't we also make this clear?
> 
> Senders are motivated to ensure that their mail is delivered, which makes
> them interested in all of the factors which can maximize delivery and
> minimize rejection.SPF HELO might be one of those reasons.   Do we
> mention this as an additional measure that senders might want to consider,
> or do we keep silent?
> 
> Todd's assertion is that SPF HELO will cause an excessive number of false
> positives.   I share Todd's expectation that this will be true, but I have
> no data on that point yet.  I am just beginning to collect that data,
> because it seems like an interesting question.
> 
> A second assumption is that no significant recipients are evaluating SPF
> MAILFROM and SPF HELO together in a way that would be of interest to
> senders. This may also be true, but I don't think this is something that
> can be tested.
> 
> A third assumption is that the current behavior related to SPF HELO will
> continue indefinitely.
> 
> To maximize interoperability:
> - Recipients can be encouraged to ignore SPF HELO as unnecessary and the
> likely source of false positives.
> - Senders can be encouraged to ensure SPF HELO compliance to prevent false
> positives.
> 
> That interoperability outcome seems worth some comment in our final
> document, since it created the confusion that led to ticket #1.
> 
> The original question and these comments are exclusively about the SPF side
> of the DMARC evaluation, which presumes that the DKIM signature is missing
> or invalid.   I was neither proposing a new block algorithm nor proposing a
> new allow algorithm.  But I do think that we need to anticipate how people
> are likely to use our documents, with the goal of minimizing incompatible
> interpretations.   Ale's question demonstrates that such interpretation
> problems are possible, even on a small and well-informed sample set.
> 
> DF
> 
> DF
> 
> On Mon, Feb 8, 2021 at 9:50 AM Todd Herr  
> 40valimail@dmarc.ietf.org> wrote:
> > On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
> > 
> > dougfoster.emailstanda...@gmail.com> wrote:
> >> "We have a lot of other topics" is the wrong reason to call for
> >> consensus.   The important question is "Ale, have we addressed your
> >> concerns?"
> >> 
> >> I agree with many that for DMARC, our primary interest is whether SPF
> >> validation of MAILFROM produces a PASS.
> > 
> > That's only partially correct. For DMARC, the SPF validation of MAILFROM
> > must produce a PASS and the identifier must align with the RFC5322.From
> > header domain. Absent both the PASS verdict and the alignment, the
> >  section of the aggregate report will show "fail" for
> > SPF, even if the  bit of the  section shows "pass"
> > in the  sub-section.
> > 
> >> However, I also see that a cautious recipient may choose to also require
> >> SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
> >> on these multiple criteria increases the confidence in the PASS result,
> >> but
> >> also increases the likelihood of ambiguous results and false rejects.
> >> 
> >> Therefore:
> >>  - Recipients need to be cautious about enforcing rules so strictly that
> >> 
> >> sender configuration errors produce unwanted disposition decisions.
> >> 
> >>  - Senders need to be careful to ensure that they configure their policy
> >> 
> >> to produce both SPF MAILFROM = PASS and SPF HELO=PASS.
> > 
> > The likelihood of a HELO identifier both passing an SPF check and aligning
> > with the RFC5322.From identifier is, I would venture, so small as to be
> > immeasurable for shared services such as ESPs, mailing list servers, and
> > the like. Perhaps they could eventually be convinced of a need to publish
> > SPF 

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

[Douglas Foster]

The chairs can introduce another topic whenever they want.   This does not
seem like a pre-requisite to any of the other pending topics.

My interest is interoperability:We want recipient requirements and
sender compliance measures to align.

RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM
together.  An argument can be made that this is not necessary:   SPF
MAILFROM shows that the server is authorized to send messages for the
specific domain in the MAILFROM, while SPF HELO says only that the server
is authorized to send message for the server domain and an unknowable set
of other domains.  Therefore a PASS from SPF MAILFROM should make SPF HELO
unnecessary and redundant.Does either the DMARC document or the SPF
document say this anywhere?

RFC 7208 can be misunderstood to suggest that SPF MAILFROM and SPF HELO are
equivalent and interchangeable, which they are not, for the reason just
mentioned.   Shouldn't we also make this clear?

Senders are motivated to ensure that their mail is delivered, which makes
them interested in all of the factors which can maximize delivery and
minimize rejection.SPF HELO might be one of those reasons.   Do we
mention this as an additional measure that senders might want to consider,
or do we keep silent?

Todd's assertion is that SPF HELO will cause an excessive number of false
positives.   I share Todd's expectation that this will be true, but I have
no data on that point yet.  I am just beginning to collect that data,
because it seems like an interesting question.

A second assumption is that no significant recipients are evaluating SPF
MAILFROM and SPF HELO together in a way that would be of interest to
senders. This may also be true, but I don't think this is something that
can be tested.

A third assumption is that the current behavior related to SPF HELO will
continue indefinitely.

To maximize interoperability:
- Recipients can be encouraged to ignore SPF HELO as unnecessary and the
likely source of false positives.
- Senders can be encouraged to ensure SPF HELO compliance to prevent false
positives.

That interoperability outcome seems worth some comment in our final
document, since it created the confusion that led to ticket #1.

The original question and these comments are exclusively about the SPF side
of the DMARC evaluation, which presumes that the DKIM signature is missing
or invalid.   I was neither proposing a new block algorithm nor proposing a
new allow algorithm.  But I do think that we need to anticipate how people
are likely to use our documents, with the goal of minimizing incompatible
interpretations.   Ale's question demonstrates that such interpretation
problems are possible, even on a small and well-informed sample set.

DF

DF

On Mon, Feb 8, 2021 at 9:50 AM Todd Herr  wrote:

> On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> "We have a lot of other topics" is the wrong reason to call for
>> consensus.   The important question is "Ale, have we addressed your
>> concerns?"
>>
>> I agree with many that for DMARC, our primary interest is whether SPF
>> validation of MAILFROM produces a PASS.
>>
>
> That's only partially correct. For DMARC, the SPF validation of MAILFROM
> must produce a PASS and the identifier must align with the RFC5322.From
> header domain. Absent both the PASS verdict and the alignment, the
>  section of the aggregate report will show "fail" for
> SPF, even if the  bit of the  section shows "pass"
> in the  sub-section.
>
>
>> However, I also see that a cautious recipient may choose to also require
>> SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
>> on these multiple criteria increases the confidence in the PASS result, but
>> also increases the likelihood of ambiguous results and false rejects.
>> Therefore:
>>  - Recipients need to be cautious about enforcing rules so strictly that
>> sender configuration errors produce unwanted disposition decisions.
>>  - Senders need to be careful to ensure that they configure their policy
>> to produce both SPF MAILFROM = PASS and SPF HELO=PASS.
>>
>
> The likelihood of a HELO identifier both passing an SPF check and aligning
> with the RFC5322.From identifier is, I would venture, so small as to be
> immeasurable for shared services such as ESPs, mailing list servers, and
> the like. Perhaps they could eventually be convinced of a need to publish
> SPF records, but that wouldn't do much of anything to change the
>  results for DMARC. Getting an SPF pass verdict alone for
> these identifiers isn't enough to alter the DMARC validation results; the
> identifiers must align, too. From a practical standpoint, I don't believe
> SPF MAILFROM=pass/SPF EHLO=fail would be useful information to mailbox
> providers for the significant volume of mail routing to their customers
> from shared services; I get quite a lot of such mail to my Gmail mailbox
> each day, wanted mail that is correctly 

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

[John Levine]

In article  
you write:
>
>The likelihood of a HELO identifier both passing an SPF check and aligning
>with the RFC5322.From identifier is, I would venture, so small as to be
>immeasurable for shared services such as ESPs, mailing list servers, and
>the like. ...

Agreed.  You can do it on your hobby linux box but not at any sort of scale.

Once again, there is nothing to fix here.  Can we close this now?

R's,
John

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

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

[Todd Herr]

On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> "We have a lot of other topics" is the wrong reason to call for
> consensus.   The important question is "Ale, have we addressed your
> concerns?"
>
> I agree with many that for DMARC, our primary interest is whether SPF
> validation of MAILFROM produces a PASS.
>

That's only partially correct. For DMARC, the SPF validation of MAILFROM
must produce a PASS and the identifier must align with the RFC5322.From
header domain. Absent both the PASS verdict and the alignment, the
 section of the aggregate report will show "fail" for
SPF, even if the  bit of the  section shows "pass"
in the  sub-section.


> However, I also see that a cautious recipient may choose to also require
> SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
> on these multiple criteria increases the confidence in the PASS result, but
> also increases the likelihood of ambiguous results and false rejects.
> Therefore:
>  - Recipients need to be cautious about enforcing rules so strictly that
> sender configuration errors produce unwanted disposition decisions.
>  - Senders need to be careful to ensure that they configure their policy
> to produce both SPF MAILFROM = PASS and SPF HELO=PASS.
>

The likelihood of a HELO identifier both passing an SPF check and aligning
with the RFC5322.From identifier is, I would venture, so small as to be
immeasurable for shared services such as ESPs, mailing list servers, and
the like. Perhaps they could eventually be convinced of a need to publish
SPF records, but that wouldn't do much of anything to change the
 results for DMARC. Getting an SPF pass verdict alone for
these identifiers isn't enough to alter the DMARC validation results; the
identifiers must align, too. From a practical standpoint, I don't believe
SPF MAILFROM=pass/SPF EHLO=fail would be useful information to mailbox
providers for the significant volume of mail routing to their customers
from shared services; I get quite a lot of such mail to my Gmail mailbox
each day, wanted mail that is correctly routed to my Inbox.

Beyond all that, though, SPF can fail for both the MAILFROM and the EHLO
identifier on any given message, but if the message is DKIM signed in a way
that aligns with the RFC5322.From domain and the DKIM validation check
passes, then the message will correctly be described as having gotten a
DMARC pass verdict. We've spent quite a lot of time on this list discussing
authentication checks that can, by themselves, result in a DMARC pass
verdict, but that cannot, by themselves, result in a DMARC fail verdict. A
message has to fail SPF validation/alignment checks and DKIM
validation/alignment checks in order to fail DMARC. I am not suggesting
that the DMARC spec be updated to require that both SPF and DKIM both pass
and align in order for DMARC to pass, because while I believe it to be best
practice for senders to align both SPF and DKIM identifiers, I believe it
would cause too much breakage in existing running code and sender
configurations to be worth it to mandate such things.


> Altogether, I think some wordsmithing is needed to communicate those
> points.   I do not have such wording at this moment, but will begin
> thinking about what I would propose.   Perhaps those who are anxious to
> move on will be able to produce text sooner.
>
> I have also raised a concern about the inadequacy of reporting these
> results, since "Recevied-SPF: pass" is currently a compliant header.   We
> can defer this issue to a later ticket, but we need to be thinking about
> the problem.   If this requires no change, I would like some discussion of
> why that might be the case.
>
>
>
What the message recipient does with all this authentication information is
left as a local policy decision, a decision that is likely to be made using
more data points than just the SPF, DKIM, and DMARC validation verdicts.
The DMARC spec does not mandate that a message passing DMARC checks be
accepted, nor does it mandate that a message failing DMARC checks be
rejected, even in the relevant policy published by the domain owner is
"p=reject", and I am absolutely not suggesting that the DMARC spec be
written in such a way as to mandate such behaviors. In my opinion, the text
that should appear in the DMARC spec to sum up these points is "A DMARC
pass verdict means only that the message can be reliably associated by the
recipient with the identity on which the DMARC validation check was
performed, and a DMARC fail verdict means that it cannot be so associated."

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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 

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

[Douglas Foster]

"We have a lot of other topics" is the wrong reason to call for consensus.
 The important question is "Ale, have we addressed your concerns?"

I agree with many that for DMARC, our primary interest is whether SPF
validation of MAILFROM produces a PASS.

However, I also see that a cautious recipient may choose to also require
SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
on these multiple criteria increases the confidence in the PASS result, but
also increases the likelihood of ambiguous results and false rejects.
Therefore:
 - Recipients need to be cautious about enforcing rules so strictly that
sender configuration errors produce unwanted disposition decisions.
 - Senders need to be careful to ensure that they configure their policy to
produce both SPF MAILFROM = PASS and SPF HELO=PASS.

Altogether, I think some wordsmithing is needed to communicate those
points.   I do not have such wording at this moment, but will begin
thinking about what I would propose.   Perhaps those who are anxious to
move on will be able to produce text sooner.

I have also raised a concern about the inadequacy of reporting these
results, since "Recevied-SPF: pass" is currently a compliant header.   We
can defer this issue to a later ticket, but we need to be thinking about
the problem.   If this requires no change, I would like some discussion of
why that might be the case.

DF


On Sat, Feb 6, 2021 at 8:16 PM Dave Crocker  wrote:

> On 2/6/2021 3:57 PM, Kurt Andersen (b) wrote:
> >
> > +1 - now, if only we had a real voting system :-P
>
> Yeah, 'cause this one is really close, and it's hard to tell what the
> decision is...
>
>
> d/
>
> ps.  +1
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org
>
> ___
> 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

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

[Dave Crocker]

On 2/6/2021 3:57 PM, Kurt Andersen (b) wrote:


+1 - now, if only we had a real voting system :-P


Yeah, 'cause this one is really close, and it's hard to tell what the 
decision is...



d/

ps.  +1

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

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

[Kurt Andersen (b)]

On Sat, Feb 6, 2021 at 11:53 AM Dotzero  wrote:

>
> On Thu, Feb 4, 2021 at 11:43 AM John R Levine  wrote:
>
>> I really do not see anything to change here, and we have a lot of other
>> tickets to work on.  Please, can we stop and close this one?
>>
>
> +1 Could we have a show of consensus on closing this.
>

+1 - now, if only we had a real voting system :-P

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Thu, Feb 4, 2021 at 11:43 AM John R Levine  wrote:

> I really do not see anything to change here, and we have a lot of other
> tickets to work on.  Please, can we stop and close this one?
>

+1 Could we have a show of consensus on closing this.

Mihael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Thursday, February 4, 2021 7:50:22 AM EST Alessandro Vesely wrote:
> On Wed 03/Feb/2021 19:12:26 +0100 John Levine wrote:
> > In article  you write:
> >>On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:
> >>> It's existing practice and I see no reason to change it.
> >>
> >>Software changes all the time.  If we change, ...
> >>
> > Urrgh. There are still MTAs that haven't been updated from RFC 821. If
> > you want a real standard, the closer you can make it to what the
> > running code does, the most likely it will work.
> 
> How about this:
> 
>  NOTE: Historically, SPF was focused on the mfrom identifier.  The helo
>  identifier was retrofitted later, in order to account for delivery
> status notifications.  Earlier DMARC specifications followed suit. 
> Subsequently, it turned out that SPF records for the helo identifier are
> actually sharper than those for mfrom, thereby making successful helo
> verifications very reliable.  However, in the vast majority of cases the
> mfrom identifier is aligned with the main DMARC identifier, while the helo
> identifier often does not have a corresponding SPF record.  Therefore, the
> common practice of using just the SPF result of mfrom unless empty is still
> a valid heuristic.
> 
> ?

I really think we should just stop.  Independently of if your note is a good 
idea (I really don't think it's needed), it's also inaccurate.  As written it 
implies that HELO checking was added to SPF after DMARC was developed.  HELO 
checking was added in 2004 or earlier.  When was DMARC defined?

Please just stop.

Scott K


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

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

[John R Levine]

I really do not see anything to change here, and we have a lot of other 
tickets to work on.  Please, can we stop and close this one?




On Wed 03/Feb/2021 19:12:26 +0100 John Levine wrote:

In article  you write:

On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:

It's existing practice and I see no reason to change it.


Software changes all the time.  If we change, ...


Urrgh. There are still MTAs that haven't been updated from RFC 821. If
you want a real standard, the closer you can make it to what the
running code does, the most likely it will work.



How about this:

   NOTE: Historically, SPF was focused on the mfrom identifier.  The helo
   identifier was retrofitted later, in order to account for delivery status
   notifications.  Earlier DMARC specifications followed suit. 
Subsequently,
   it turned out that SPF records for the helo identifier are actually 
sharper

   than those for mfrom, thereby making successful helo verifications very
   reliable.  However, in the vast majority of cases the mfrom identifier is
   aligned with the main DMARC identifier, while the helo identifier often
   does not have a corresponding SPF record.  Therefore, the common practice
   of using just the SPF result of mfrom unless empty is still a valid
   heuristic.

?


Best
Ale



Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Alessandro Vesely]

On Wed 03/Feb/2021 19:12:26 +0100 John Levine wrote:

In article  you write:

On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:

It's existing practice and I see no reason to change it.


Software changes all the time.  If we change, ...


Urrgh. There are still MTAs that haven't been updated from RFC 821. If
you want a real standard, the closer you can make it to what the
running code does, the most likely it will work.



How about this:

NOTE: Historically, SPF was focused on the mfrom identifier.  The helo
identifier was retrofitted later, in order to account for delivery status
notifications.  Earlier DMARC specifications followed suit.  Subsequently,
it turned out that SPF records for the helo identifier are actually sharper
than those for mfrom, thereby making successful helo verifications very
reliable.  However, in the vast majority of cases the mfrom identifier is
aligned with the main DMARC identifier, while the helo identifier often
does not have a corresponding SPF record.  Therefore, the common practice
of using just the SPF result of mfrom unless empty is still a valid
heuristic.

?


Best
Ale
--









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

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

[John Levine]

In article  you write:
>On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:
>> 
>> There is some commented out code to not pass a HELO result to DMARC, don't 
>> remember why I turned it off.
>
>Couldn't find the code you uncommented in.

I'm not surprised.  It's only in my MTA.

>Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and 
>calls opendmarc_policy_store_spf() to save
>the result it parsed.  That way, the last value found is the one that will be 
>used.
>
>It seems that relies on upstream SPF filters writing a single SPF result.  If 
>mfrom is given write its result,
>otherwise write helo's.  That behavior is presumably coded after DMARC's 
>idiosyncrasy.  It would choke if applied to an
>unskewed SPF filter's results.

Is that what its milter does?  Not surprised.

>> It's existing practice and I see no reason to change it.
>
>Software changes all the time.  If we change, ...

Urrgh. There are still MTAs that haven't been updated from RFC 821. If
you want a real standard, the closer you can make it to what the
running code does, the most likely it will work.

R's,
John

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

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

[Alessandro Vesely]

On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:


There is some commented out code to not pass a HELO result to DMARC, don't 
remember why I turned it off.



Couldn't find the code you uncommented in.

Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and 
calls opendmarc_policy_store_spf() to save the result it parsed.  That way, the 
last value found is the one that will be used.

It seems that relies on upstream SPF filters writing a single SPF result.  If 
mfrom is given write its result, otherwise write helo's.  That behavior is 
presumably coded after DMARC's idiosyncrasy.  It would choke if applied to an 
unskewed SPF filter's results.



Again, I believe this is typical of what DMARC validators do.



Yes.  Here's an example by Google.  You may note that the helo name reported in 
Received: must have resulted in an spf=pass, which is not reported:

ARC-Authentication-Results: i=1; mx.google.com;
   spf=neutral (google.com: 62.94.243.226 is neither permitted nor denied 
by best guess record for domain of u...@fragolina.it) 
smtp.mailfrom=u...@fragolina.it;
   dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tana.it
Return-Path: 
Received: from wmail.tana.it (wmail.tana.it. [62.94.243.226])
by mx.google.com with ESMTP id d18si1599313edu.101.2021.02.03.08.37.32
for ;
Wed, 03 Feb 2021 08:38:57 -0800 (PST)



It's existing practice and I see no reason to change it.



Software changes all the time.  If we change, this particular fix would 
probably be less noticeable than many other software bugs lurking amid the 
code.  Indeed, you have to craft a message on purpose in order to have mfrom 
fail while helo pass (as the example above).

We can even explicitly allow the existing behavior for historical reasons, if 
nobody recalls why the spec came out that way.

However, please, let's not write a quirky spec.

Best
Ale
--












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

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

[Douglas Foster]

I believe that most code is validating the MailFrom parameter if it is
supplied, and validating the HELO name only if MAILFROM is null.   This is
based mostly on the way SPF has been discussed over the last 15 years,
coupled with the observed behavior of a limited number of
product implementations..

If we are to argue that HELO and MAILFROM tests are interchangeable, we
have to deal with the situation where the domains are different and the
results are different.SPF has 7 possible results, so there are 49
possible combinations of these two tests, 42 of which are divergent.   (If
we factor in NXDOMAIN as a separate result, which even RFC 7208 says is
probably appropriate for HELO, the number of divergent results is even
greater.)

To merge the tests, we would need to define a winning result for all of the
divergent result pairs, and then demonstrate that our winning result can be
considered appropriate for all installations.   Such an undertaking has not
been attempted, and I cannot imagine it achieving consensus.

The result needed for DMARC is the result I believe is actually being
produced by most installations:   The result is evaluated based on MAILFROM
when it is not null, and evaluated using HELO domain when MAILFROM is
null.   Of course, using HELO as a proxy for MAILFROM only works for bounce
messages being returned from installations hosting a single mail domain on
a matching host domain.   For everyone else, DMARC will only verify
automatic messages that are signed with the From address domain.  The DMARC
specification should make this clear to the reader.

- - -

To correct an earlier comment of mine:

fcDNS on HELO and SPF HELO tests can be used together quite effectively.
 fcDNS validates that the server is reporting a valid host name, limits the
allowed results to a single DNS domain, and demonstrates that the domain
being used for SPF HELO is the correct one.  However, fcDNS does not
demonstrate that the server is authorized to send mail.   SPF defines the
servers which are allowed to send mail for the domain, but may include IP
addresses from other domains, either directly or through Include clauses.
 When the host name is verified with both fcDNS and SPF HELO, the evaluator
knows that the server is in the reported domain and authorized by that
domain to send mail.

Note that this is also different from fcDNS on the Reverse DNS name, as
reported with the "iprev" test result.  We really do not have a way to
report test results for the HELO name.  It would seem desireable to add
test result indicators for both fcDNS HELO and fcDNS SPF.

Doug Foster



.

On Tue, Feb 2, 2021 at 2:54 PM John R Levine  wrote:

> >> There is some commented out code to not pass a HELO result to DMARC,
> don't
> >> remember why I turned it off.
> >
> > I’m lost in a double negative here: did you turn off passing a HELO
> result to
> > DMARC, or did you turn off not passing a HELO result?
>
> The live code uses whichever result it has.  The commented out code only
> used a MAIL FROM result.
>
> >> Again, I believe this is typical of what DMARC validators do.  It's
> >> existing practice and I see no reason to change it.  Can we stop now?
> >
> > If you found that you needed to turn off something that’s part of the
> DMARC
> > spec, it would be good to understand why.
>
> I believe that what I am doing matches the spec.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> ___
> 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

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

[Douglas Foster]

Yes, it is true that the spec says

If a conclusive determination about the
message can be made based on a check of "HELO", then the use of DNS
resources to process the typically more complex "MAIL FROM" *can* be
avoided.

However, it carefully avoids defining "definitive", which means the
interpretation of "definitive" is site-specific.   To my interpretation,
"definitive" means a local policy to whitelist or blacklist based
exclusively on the HELO parameters.   Such as decision will certainly allow
other operations to be omitted.

This interpretation is supported by the previous paragraph:

   It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
   identity but also separately check the "HELO" identity by applying
   the check_host() function (Section 4
) to the "HELO"
identity as the
   .


and the subsequent paragraph:


 SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check

   either has not been performed or has not reached a definitive policy
   result by applying the check_host() function to the "MAIL FROM"
   identity as the .


We really have two different tests, which appear in the same document
because they exploit the same technology.


The limitations of Received-SPF become very conspicuous and problematic:

- The identifiers are only provided in comment text, which is optional
and has been omitted in the wild.

- Although comment text implementations appear to be standardized,
this is still less reliable than structured data.

- Even when the comment text can be parsed, only domain names are
provided, and the test type is not documented,

so there is no way to know whether the result is based on HELO or SMTP Address.

- Received-SPF needs to report two results for entities which perform
both tests, but multiple results simply create ambiguity..

- The Received-SPF cannot be linked to a specific Received entry.
The assumption is that it will only be used

 within a single ADMD, where the perimeter is known and all internal
MTAs are trusted.


We have integrated Received-SPF into A-R without improvement, and A-R
has been integrated into ARC without significant redesign.

Then we are hoping that a third-party organization will trust an ARC
which is based on this weak foundation.


DF


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

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

[John R Levine]

There is some commented out code to not pass a HELO result to DMARC, don't 
remember why I turned it off.


I’m lost in a double negative here: did you turn off passing a HELO result to 
DMARC, or did you turn off not passing a HELO result?


The live code uses whichever result it has.  The commented out code only 
used a MAIL FROM result.


Again, I believe this is typical of what DMARC validators do.  It's 
existing practice and I see no reason to change it.  Can we stop now?


If you found that you needed to turn off something that’s part of the DMARC 
spec, it would be good to understand why.


I believe that what I am doing matches the spec.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

On 2 Feb 2021, at 11:13, John R Levine wrote:

An SPF library implements the check_host() function.  It's up to the 
client to call it multiple times.  Is that client DMARC-aware?  As 
you may have guessed, my question is intended to understand how does 
a DMARC implementation actually ascertain whether an "spf=pass 
helo=smtp.example.com" is enough to validate "From: 
u...@example.com".


I use the opendmarc library and libspf2.  For the SPF check, I give it 
the IP address, the HELO, and the MAIL FROM, and it gives me a result. 
 I then pass that result to the DMARC library along with the DKIM 
results. Looking at the code, I see I tell it whether SPF checked HELO 
or MAIL FROM by simply checking whether MAIL FROM was null, but I 
don't know what the DMARC libary does with that.  Maybe Murray 
remembers.


There is some commented out code to not pass a HELO result to DMARC, 
don't remember why I turned it off.


I’m lost in a double negative here: did you turn off passing a HELO 
result to DMARC, or did you turn off not passing a HELO result?


Again, I believe this is typical of what DMARC validators do.  It's 
existing practice and I see no reason to change it.  Can we stop now?


If you found that you needed to turn off something that’s part of the 
DMARC spec, it would be good to understand why.


-Jim

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

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

[John R Levine]

An SPF library implements the check_host() function.  It's up to the client 
to call it multiple times.  Is that client DMARC-aware?  As you may have 
guessed, my question is intended to understand how does a DMARC 
implementation actually ascertain whether an "spf=pass helo=smtp.example.com" 
is enough to validate "From: u...@example.com".


I use the opendmarc library and libspf2.  For the SPF check, I give it the 
IP address, the HELO, and the MAIL FROM, and it gives me a result.  I then 
pass that result to the DMARC library along with the DKIM results. 
Looking at the code, I see I tell it whether SPF checked HELO or MAIL FROM 
by simply checking whether MAIL FROM was null, but I don't know what the 
DMARC libary does with that.  Maybe Murray remembers.


There is some commented out code to not pass a HELO result to DMARC, don't 
remember why I turned it off.


Again, I believe this is typical of what DMARC validators do.  It's 
existing practice and I see no reason to change it.  Can we stop now?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John Levine]

In article <2e39680f-ed2d-fa38-daaa-7e0627cf0...@tana.it> you write:
>> My MTA adds an SPF clause in the A-R header whether or not there's a null
>> bounce address.
>
>How can it report, say, fail for helo and pass for mfrom in just one clause?

It doesn't.  It reports whatever the SPF library returns.

I'm fairly sure that every DMARC implementation uses an SPF library and uses
whatever the SPF library returns, so I don't see the point of this argument.

>>> OTOH, properly implemented SPF verifiers could skip producing a Mail From 
>>> result if the helo identity was verified successfully.
>> 
>> No, they could not.  That's not what the SPF spec says.

Sorry, that's not what the DMARC spec says.

Once again, what problem are we solving here?  Can we stop now?

R's,
John

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

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

[Hector Santos]

This is real legit "feasible" proposal so let see where it goes 

On 1/30/2021 5:41 AM, Alessandro Vesely wrote:>


Anyway, I'll let consensus fall where it may.


The solution is to consider the PRA/SUBMITTER protocols which was part 
of the SenderID protocol and many MTA clients already supported:


SUBMITTER https://tools.ietf.org/html/rfc4405
PRA https://tools.ietf.org/html/rfc4407

When the ESMTP Extension SUBMITTER is enabled, the client add can a 
SUBMITTER= parameter to the MAIL FROM. Example of a complete session 
this morning:


C: EHLO oscar.ultrashed.buzz
S: 250-mail.winserver.com, Pleased to meet you.
S: 250-SIZE 1024
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=santronics@mail.ultrashed.buzz> 
BODY=8BITMIME SUBMITTER=easysh...@ultrashed.buzz
S: 250 
<27188-46690-410393-7123-hector.santos=santronics@mail.ultrashed.buzz>... 
Sender validation pending. Continue. (8BITMIME ok)

C: RCPT TO:
** WCX Process: wcsap ret: 550 (63 msecs) (Rejected by WCSAP RBL Host 
bl.spamcop.net)

S: 550 Return Path not verifiable.
C: QUIT
S: 221 closing connection
** Completed. Elapsed Time: 530 msecs


Our wcSMTP supports the SUBMITTER SMTP Service Extension (RFC4405). 
The keyword SUBMITTER is advertised.  The client uses RFC4407 
Purported Responsible Address (PRA) to extra the PRA which is usually 
the 5322.From address and issues the MAIL FROM:


C: MAIL 
FROM:<27188-46690-410393-7123-hector.santos=santronics@mail.ultrashed.buzz> 
BODY=8BITMIME SUBMITTER=easysh...@ultrashed.buzz


So here we can see the 5322.From is different from the 5321.MailFrom 
return path, a subdomain but different.


My proposal is for the SMTP server to use this opportunity to do a 
DMARC look up for ultratrashed.buzz domain. Lets do this now:


v=DMARC1; p=none; fo=1; rua=mailto:i...@ultrashed.buzz; 
ruf=mailto:i...@ultrashed.buzz;


And there is no DMARC record for the subdomain.

And note the EHLO subdomain, "oscar" vs "mail" for the return path.

But how does this help?


Well, the receiver now knows the there is a DMARC record and therefore:

1) The message MUST be signed but we won't know this until the payload 
is transferred,


2) SPF is expected. There is no SPF record any of three domains, and

3) The p=none means he doesn't really care if it alignment fails or 
they are not sure but its not reject|quarantine which means they don't 
expect alignment enforcement.


But considering there is DMARC record but no SPF record means there is 
a problem with this transaction. It can be refused probably on that 
basis. But as you can see, it was rejected but for RBL reasons. :-)


We SHOULD consider the two protocols (PRA/SUBMITTER) for DMARC/SPF 
integration. This extra bit of information help at SMTP before the 
potentially high overhead payload is transferred. That was the main 
MS-patented (frivolous) reason for this optimization -- to avoid the 
payload transfer overhead.


But the beauty of this proposal is that it is not new! There are 
clients out there that do support it and will extract the PRA and 
issue it at SMTP MAIL FROM state:


C: MAIL FROM: [SUBMITTER=pra]

At the point, the SMTP client has some awareness of the payload and 
DMARC expectations.



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



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

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

[Hector Santos]

On 2/1/2021 7:11 PM, Douglas Foster wrote:

I think I finally understand the complexities of this issue.   SPF is
two different validations, largely unrelated.

Test One:
A connection comes in and a server asserts a HELO name.   Before
proceeding, the recipient was to check if the HELO name is plausible
or fraudulent.One way to do this would be to forward-confirm the
HELO DNS name to the source IP.  An alternate method is to use SPF to
see if the SPF policy says that the HELO domain can send from the
Source IP.   I do not understand why the domain owner would be able to
configure the SPF policy but not the host name in DNS.


There is a history of Machine Host Name and IP misconfiguration -- 
EASILY possible by simply moving a machine or trying to use many 
machines correctly and generically with one configuration profile.  If 
rDNS is not available for the host, its all part of the unreliability. 
 Unless you write SMTP code for outbound mailing, its hard to see 
this. You can try to automate the smtp client design so that the EHLO 
is always correct with the IP, but there will be MANY times where it 
won't be right for ABC customer for their XYZ reasons.  Its possible 
but its not without optional fields to override an automated logic.



Test Two:
If the conversation proceeds past HELO to MAILFROM, then the second
validation is performed:   Is the Source IP is authorized to send on
behalf of the SMTP domain?   When the SMTP address is null, then
postmaster@HeloDomain serves as a proxy for performing this test.


That's one theory possible, but the main thing to remember that a 
BOUNCE is required in the name of mail delivery and notifications when 
delivery fails. You still have the unreliable nature of HELO checking 
and a bounce is too important to be making it dependent on an 
unreliable HELO SPF check.


Many systems do a variety of RFC5322 checks for a BOUNCE message after 
it is accepted or maybe at the DATA state.   It would be nice if we 
could enforce DSN (RFC3464) but that is not possible.  Its optional 
and the old way of doing BOUNCE messages, formats and layouts varies. 
 Inconsistent.  There are some keep addresses that "must" or "should" 
exist in the 5322.From, like the user part has "Mailer-Daemon" and 
"postmaster" when the 5321.MailFrom is NULL.  If not, it could be 
rejected then.


Finally..

Back in early days of LMAP "Lightweight MTA Authentication Protocol" 
[1] , 2003, 2004, Meng Wong made his version of a LMAP protocol called 
SPF. Before SPF, there were others like DMP "Designated Mailers 
Protocols" [2] and RMX [3]. SPF is a merge of these two LMAP methods.


My wcSMTP was among the early LMAP explorers (wcSMTP had DMP support 
before SPF came). I did an LMAP analysis and provided it to Meng Wong. 
 We had an email conversation about the need to document SPF 
CheckHost() for HELO (despite its unreliability and ambiguity) but do 
not enforce HELO checking because there will a wide degree of 
different implementations possible when it comes to HELO checking and 
the order of checking the identities.  For example, in wcSMTP, the 
order is as follows:


1- RCPT TO
2- MAIL FROM
3- EHLO/HELO (optional which is OFF by default)

Before any extended, DNS overhead augmented technology is performed, 
RCPT TO is checked for validity and existence. So when the client 
issues MAIL FROM, the following response is issued by wcSMTP:


C: MAIL FROM:
S: 250 ... Sender validation pending. Continue.

Then the RCPT TO issued:

C: RCPT TO:

If the RCPT TO address is good, then it now checks the envelope 
parameters against a suite of protocols that include RBL, SPF, CBV and 
local rules filters.


But if the RCPT TO address is not good, then a 550 is issued because 
there is no need to check for any DNS related policies.  If SPF fails 
here, DATA is never reached -- its considered an optimizer and 
remember please, SPF predated DKIM POLICIES (SSP, ADSP and DMARC).  In 
additional, there is the PRA and SUBMITTER protocol that wcSMTP SPF 
implementation considers.  PRA/SUBMITTER provides the 5322.From 
address at the SMTP level.  It can be used to for SPF checking. Its 
optional.  But now with DMARC, I think PRA/SUBMITTER can play a big 
role and enhance these DMARC SMTP/SPF checking adjustment. Its 
unfortunate there isn't another "mail engineer" that can see the 
benefit of these protocols used together. SPF doesn't need to change, 
DMARC does!!!


Here is the LMAP analysis I did. wcSMTP follows the concepts this 
analysis to help optimize LMAP protocols checking at the SMTP level:


https://secure.winserver.com/public/antispam/lmap/draft-LmapAnalysis1-2.htm

I hope this helps your understanding of the complexity of all this, 
but for me, there are some basic filter concepts that can be applied 
and I do for my wcSMTP package before all the extra DNS overhead can 
be applied.


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

[1] Lightweight MTA 

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

[Alessandro Vesely]

On Tue 02/Feb/2021 01:11:22 +0100 Douglas Foster wrote:
I think I finally understand the complexities of this issue.   SPF is two 
different validations, largely unrelated.


Test One:
A connection comes in and a server asserts a HELO name.   Before proceeding, 
the recipient was to check if the HELO name is plausible or fraudulent.    One 
way to do this would be to forward-confirm the HELO DNS name to the source IP.



That is the method described as iprev in Section 2.7.3 of RFC 8601, a.k.a. 
Forward-confirmed reverse DNS (FCrDNS).  Like many other authentication 
methods, it is not considered by DMARC.



An alternate method is to use SPF to see if the SPF policy says that the HELO 
domain can send from the Source IP.   I do not understand why the domain 
owner would be able to configure the SPF policy but not the host name in DNS.



To configure reverse DNS one needs a delegation of the relevant arpa subdomain, 
which ISPs don't routinely provide.  By contrast, A, AAA, MX, and TXT records 
can be defined by every domain owner.  In theory, each label having any of A, 
AAA, or MX resource records, deserves an SPF record as well.



Perhaps for organizations with 1000s of servers, creating a DNS entry for 
each machine seemed onerous.   In practice, the large organizations do have DNS 
entries for each server, and they encourage others to do the same.



Google, for one, don't care to define an SPF record for every server.  DMARC's 
discarding the result of helo verification is certainly not an incentive.



A recipient who gets a FAIL result from this HELO test could decide to 
reject the connection without ever proceeding to MAILFROM.



Rejecting EHLO can be problematic, since the command does not start a mail 
transaction.  Implementations may delay 5xx replies until MAIL or RCPT commands.




[...]
I expect that any attempt to require a PASS from this test will encounter an
unacceptable number of false positives, so I do not see it as particularly
useful.


To /require/ a pass on helo is very different from /discarding/ a pass on helo.



Test Two:
If the conversation proceeds past HELO to MAILFROM, then the second validation 
is performed:   Is the Source IP is authorized to send on behalf of the SMTP 
domain?   When the SMTP address is null, then postmaster@HeloDomain serves as a 
proxy for performing this test.



Testing postmaster@HeloDomain is exactly the same test done for helo.  When the 
SMTP address is null, then the test is not performed.



HELO test violations will have nothing to do with message flow path, since the 
test only examines whether the adjacent server name can be plausibly linked to 
the adjacent IP address.  A DKIM signature is not a third way of answering this 
question, because a DKIM signature cannot be reliably associated with the 
server that applied the signature.   Nor do I think we want a third solution to 
this question.  Consequently, the HELO test is unrelated to DMARC.  The SMTP 
Address test is appropriate to DMARC, whether it is evaluated using a supplied 
name or a derived name based on postmaster@helodomain.



That makes no sense.  There is no difference between evaluating HELO and 
evaluating "a derived name based on postmaster@helodomain".  It is an HELO test 
in both cases.  Either it is reliable or it is not.  Asserting that a test is 
reliable only when there are no other means to authenticate a message is an 
idiosyncrasy.




Best
Ale
--



















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

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

[Alessandro Vesely]

On Tue 02/Feb/2021 00:11:54 +0100 John Levine wrote:

In article  you write:

On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:


SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be
able to consume the Mail From result.


Perhaps Courier-MTA is not so properly implemented, but when mail from is empty 
it just omits the corresponding Received-SPF: header field.


That's a peculiarity of Courier.



Yes.  Configured as at mine, it writes three Received-SPF: fields, for helo, 
mfrom, and, as a non-standard extension, for From:.  As I said, the one for 
mfrom is only written in case mfrom is not-empty.




My MTA adds an SPF clause in the A-R header whether or not there's a null
bounce address.


How can it report, say, fail for helo and pass for mfrom in just one clause?


OTOH, properly implemented SPF verifiers could skip producing a Mail From 
result if the helo identity was verified successfully.


No, they could not.  That's not what the SPF spec says.



   If a conclusive determination about the
   message can be made based on a check of "HELO", then the use of DNS
   resources to process the typically more complex "MAIL FROM" *can* be
   avoided.
https://tools.ietf.org/html/rfc7208#section-2.3
(my emphasis)


Best
Ale
--




















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

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

[Douglas Foster]

I think I finally understand the complexities of this issue.   SPF is two
different validations, largely unrelated.

Test One:
A connection comes in and a server asserts a HELO name.   Before
proceeding, the recipient was to check if the HELO name is plausible or
fraudulent.One way to do this would be to forward-confirm the HELO DNS
name to the source IP.  An alternate method is to use SPF to see if the SPF
policy says that the HELO domain can send from the Source IP.   I do not
understand why the domain owner would be able to configure the SPF policy
but not the host name in DNS.   Perhaps for organizations with 1000s of
servers, creating a DNS entry for each machine seemed onerous.   In
practice, the large organizations do have DNS entries for each server, and
they encourage others to do the same.

A recipient who gets a FAIL result from this HELO test could decide to
reject the connection without ever proceeding to MAILFROM.  This is why the
specification suggests testing HELO before MAILFROM.   We know that
internal host names, such as "mail.example.local", will fail both of these
tests because the local domain cannot be published in DNS.   I expect that
any attempt to require a PASS from this test will encounter an unacceptable
number of false positives, so I do not see it as particularly useful.
But the option exists.

Test Two:
If the conversation proceeds past HELO to MAILFROM, then the second
validation is performed:   Is the Source IP is authorized to send on behalf
of the SMTP domain?   When the SMTP address is null, then
postmaster@HeloDomain serves as a proxy for performing this test.

We have two different tests, and two paths for performing the second test.
 Organizations have the choice of whether to implement one, both, or
neither test.   But the two tests are complementary, not mutually exclusive.

HELO test violations will have nothing to do with message flow path, since
the test only examines whether the adjacent server name can be plausibly
linked to the adjacent IP address.  A DKIM signature is not a third way of
answering this question, because a DKIM signature cannot be reliably
associated with the server that applied the signature.   Nor do I think we
want a third solution to this question.  Consequently, the HEL:O test is
unrelated to DMARC.  The SMTP Address test is appropriate to DMARC, whether
it is evaluated using a supplied name or a derived name based on
postmaster@helodomain.

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

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

[John Levine]

In article  you write:
>On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
>> I think that we're well past learning anything new in this thread.
>> 
>> SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol
>> (and shouldn't).  For any properly implemented SPF verifier, DMARC should be
>> able to consume the Mail From result.
>
>Perhaps Courier-MTA is not so properly implemented, but when mail from is 
>empty 
>it just omits the corresponding Received-SPF: header field.

That's a peculiarity of Courier.  My MTA adds an SPF clause in the A-R header
whether or not there's a null bounce address.

>OTOH, properly implemented SPF verifiers could skip producing a Mail From 
>result if the helo identity was verified successfully.

No, they could not.  That's not what the SPF spec says.

>It makes sense to add a section that modifies RFC 7208.  See below.

Please, can we stop the Mission Gallop?

R's,
John

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

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

[Scott Kitterman]

On Monday, February 1, 2021 7:17:20 AM EST Alessandro Vesely wrote:
> On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
> > I think that we're well past learning anything new in this thread.
> > 
> > SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the
> > protocol
> > (and shouldn't).  For any properly implemented SPF verifier, DMARC should
> > be able to consume the Mail From result.
> 
> Perhaps Courier-MTA is not so properly implemented, but when mail from is
> empty it just omits the corresponding Received-SPF: header field.
> 
> OTOH, properly implemented SPF verifiers could skip producing a Mail From
> result if the helo identity was verified successfully.
> 
> In conclusion, the idiosyncratic requirement can hardly be implemented.

I have no idea why you would think that.  If mail from is null, use 
postmaster@HELO domain  as mail from is trivial to implement.  If an SPF 
verification implementation does not correctly implement RFC 7208, the 
appropriate solution is to fix it, not add work arounds to DMARC.

That said, I don't think there's harm is using HELO results in DMARC if they 
align, but I don't think it will come up very often and isn't worth worrying 
about enough to rewrite that part of the DMARC specification.



> > On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> >> I don't see any justification for using HELO unless the SMTP address is
> >> null.  If the SPF RFC says otherwise, this should be corrected.
> 
> It makes sense to add a section that modifies RFC 7208.  See below.

No.  Changes to SPF are out of scope for the working group.

Scott K

> On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
> > My data, cited previously, indicates that HELO can be useful for both
> > blacklisting and whitelisting.   It should not be ignored.
> > 
> >> On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:
> >>> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
>  One way to interpret RFC 7489 is that you can put dmarc=pass based on
>  the helo identity *only if* MAIL FROM is null. >>>
> >>> 
> >>> That would be consistent with 7489.
> >>> 
> >>> Sec 3.1.2 says
> >>> 
> >>> Note that the RFC5321.HELO identity is not typically used in the
> >>> context of DMARC (except when required to "fake" an otherwise null
> >>> reverse-path), even though a "pure SPF" implementation according to
> >>> [SPF] would check that identifier.
> 
> Does that mean that an implementation that uses the RFC5321.HELO identity
> without taking care of whether RFC5321.MailFrom is empty is *atypical*?
> 
> Please note that all the text occurring before that paragraph would suggest
> that any authenticated domain, if aligned, would do.  The quoted paragraph
> comes as a note, by surprise, without bringing any rationale.  That text
> needs to be revised whether or not we remove the idiosyncrasy.
> 
> And the only rationale learnt in this thread is that one could type whatever
> it wants in the helo/ehlo command, as if that weren't true for the whole
> SMTP session.
> >>> But then 4.1 says
> >>> 
> >>> o  [SPF], which can authenticate both the domain found in an [SMTP]
> >>> 
> >>>HELO/EHLO command (the HELO identity) and the domain found in an
> >>>SMTP MAIL command (the MAIL FROM identity).  DMARC uses the
> >>>result
> >>>of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >>>[SPF] describes MAIL FROM processing for cases in which the MAIL
> >>>command has a null path.
> >>> 
> >>> That section of 7208 says that if there's a null bounce address, SPF
> >>> pretends that the MAIL FROM was postmaster@HELO.
> 
> "Postmaster" is necessary, because SPF mechanisms can refer to the local
> part.
> 
> The SPF part I'd modify, however, is Section 2.3, where it says:
> 
> If a conclusive determination about the
> message can be made based on a check of "HELO", then the use of DNS
> resources to process the typically more complex "MAIL FROM" can be
> avoided.
> 
> I'd append to that sentence:
> 
>, unless downstream filters need it anyway.
> 
> Since we're at it, that paragraph continues with the following sentence:
> 
>  Additionally, since SPF records published for "HELO"
> identities refer to a single host, when available, they are a very
> reliable source of host authorization status.
> 
> Isn't that the exact opposite of what many of us are claiming?  And is it
> legit for a proposed standard to quietly counter an existing proposed
> standard without some kind of rationale?
> 
> >>> If we want, we can say not to use the SPF HELO identity, but that would
> >>> be
> >>> an incompatible change to 7489 and I suspect would not match what most
> >>> DMARC checking code does.
> 
> OTOH, relaxing the requirement that the SPF HELO identity be used only when
> MAIL FROM is empty brings no incompatibility.  It's just a cleanup.
> 
> 

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

[Alessandro Vesely]

On Mon 01/Feb/2021 15:26:37 +0100 Douglas Foster wrote:


If Helo aligns with From, it says that the mail server has permission to send 
on behalf of the From domain, but it does not justify using a different domain 
in the SMTP address.   If the SMTP address is null, this is not a problem.   If 
it is not null and is different from the HELO domain, we have permitted domain 
abuse.



Who said a different MAIL FROM is abusive?  What if I have an account at gmail 
and, for convenience, prefer to collect bounces at that mailbox?  Would I need 
a special permission to do so?


What if helo is verified, bounce address is null, but there is a DKIM-Signature 
which is not aligned.  Is that domain abuse too?


Hm...


Best
Ale
--









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

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

[Douglas Foster]

An SPF check on MailFrom says that this host has permission to send on this
particular SMTP mail domain, and From alignment with that this SMTP mail
domain has permission to send on behalf of that same domain.

If Helo aligns with From, it says that the mail server has permission to
send on behalf of the From domain, but it does not justify using a
different domain in the SMTP address.   If the SMTP address is null, this
is not a problem.   If it is not null and is different from the HELO
domain, we have permitted domain abuse.



On Mon, Feb 1, 2021 at 7:17 AM Alessandro Vesely  wrote:

> On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
> > I think that we're well past learning anything new in this thread.
> >
> > SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the
> protocol
> > (and shouldn't).  For any properly implemented SPF verifier, DMARC
> should be
> > able to consume the Mail From result.
>
>
> Perhaps Courier-MTA is not so properly implemented, but when mail from is
> empty
> it just omits the corresponding Received-SPF: header field.
>
> OTOH, properly implemented SPF verifiers could skip producing a Mail From
> result if the helo identity was verified successfully.
>
> In conclusion, the idiosyncratic requirement can hardly be implemented.
>
>
> > On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> >> I don't see any justification for using HELO unless the SMTP address is
> >> null.  If the SPF RFC says otherwise, this should be corrected.
>
>
> It makes sense to add a section that modifies RFC 7208.  See below.
>
> On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
> > My data, cited previously, indicates that HELO can be useful for both
> > blacklisting and whitelisting.   It should not be ignored.
>
>
> >> On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:
> >>> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
>  One way to interpret RFC 7489 is that you can put dmarc=pass based on
>  the helo identity *only if* MAIL FROM is null. >>>
> >>> That would be consistent with 7489.
> >>>
> >>> Sec 3.1.2 says
> >>>
> >>> Note that the RFC5321.HELO identity is not typically used in the
> >>> context of DMARC (except when required to "fake" an otherwise null
> >>> reverse-path), even though a "pure SPF" implementation according to
> >>> [SPF] would check that identifier.
>
>
> Does that mean that an implementation that uses the RFC5321.HELO identity
> without taking care of whether RFC5321.MailFrom is empty is *atypical*?
>
> Please note that all the text occurring before that paragraph would
> suggest
> that any authenticated domain, if aligned, would do.  The quoted paragraph
> comes as a note, by surprise, without bringing any rationale.  That text
> needs
> to be revised whether or not we remove the idiosyncrasy.
>
> And the only rationale learnt in this thread is that one could type
> whatever it
> wants in the helo/ehlo command, as if that weren't true for the whole SMTP
> session.
>
>
> >>> But then 4.1 says
> >>>
> >>> o  [SPF], which can authenticate both the domain found in an [SMTP]
> >>>HELO/EHLO command (the HELO identity) and the domain found in an
> >>>SMTP MAIL command (the MAIL FROM identity).  DMARC uses the
> result
> >>>of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >>>[SPF] describes MAIL FROM processing for cases in which the MAIL
> >>>command has a null path.
> >>>
> >>> That section of 7208 says that if there's a null bounce address, SPF
> >>> pretends that the MAIL FROM was postmaster@HELO.
>
>
> "Postmaster" is necessary, because SPF mechanisms can refer to the local
> part.
>
> The SPF part I'd modify, however, is Section 2.3, where it says:
>
> If a conclusive determination about the
> message can be made based on a check of "HELO", then the use of DNS
> resources to process the typically more complex "MAIL FROM" can be
> avoided.
>
> I'd append to that sentence:
>
>, unless downstream filters need it anyway.
>
> Since we're at it, that paragraph continues with the following sentence:
>
>  Additionally, since SPF records published for "HELO"
> identities refer to a single host, when available, they are a very
> reliable source of host authorization status.
>
> Isn't that the exact opposite of what many of us are claiming?  And is it
> legit
> for a proposed standard to quietly counter an existing proposed standard
> without some kind of rationale?
>
>
> >>> If we want, we can say not to use the SPF HELO identity, but that
> would be
> >>> an incompatible change to 7489 and I suspect would not match what most
> >>> DMARC checking code does.
>
>
> OTOH, relaxing the requirement that the SPF HELO identity be used only
> when
> MAIL FROM is empty brings no incompatibility.  It's just a cleanup.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

[Alessandro Vesely]

On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:

I think that we're well past learning anything new in this thread.

SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be
able to consume the Mail From result.



Perhaps Courier-MTA is not so properly implemented, but when mail from is empty 
it just omits the corresponding Received-SPF: header field.


OTOH, properly implemented SPF verifiers could skip producing a Mail From 
result if the helo identity was verified successfully.


In conclusion, the idiosyncratic requirement can hardly be implemented.



On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:

I don't see any justification for using HELO unless the SMTP address is
null.  If the SPF RFC says otherwise, this should be corrected.



It makes sense to add a section that modifies RFC 7208.  See below.

On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:

My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting.   It should not be ignored.




On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:

On Sun, 31 Jan 2021, Alessandro Vesely wrote:
One way to interpret RFC 7489 is that you can put dmarc=pass based on 
the helo identity *only if* MAIL FROM is null. >>>

That would be consistent with 7489.

Sec 3.1.2 says

Note that the RFC5321.HELO identity is not typically used in the
context of DMARC (except when required to "fake" an otherwise null
reverse-path), even though a "pure SPF" implementation according to
[SPF] would check that identifier.



Does that mean that an implementation that uses the RFC5321.HELO identity 
without taking care of whether RFC5321.MailFrom is empty is *atypical*?


Please note that all the text occurring before that paragraph would suggest 
that any authenticated domain, if aligned, would do.  The quoted paragraph 
comes as a note, by surprise, without bringing any rationale.  That text needs 
to be revised whether or not we remove the idiosyncrasy.


And the only rationale learnt in this thread is that one could type whatever it 
wants in the helo/ehlo command, as if that weren't true for the whole SMTP session.




But then 4.1 says

o  [SPF], which can authenticate both the domain found in an [SMTP]
   HELO/EHLO command (the HELO identity) and the domain found in an
   SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
   of SPF authentication of the MAIL FROM identity.  Section 2.4 of
   [SPF] describes MAIL FROM processing for cases in which the MAIL
   command has a null path.

That section of 7208 says that if there's a null bounce address, SPF
pretends that the MAIL FROM was postmaster@HELO.



"Postmaster" is necessary, because SPF mechanisms can refer to the local part.

The SPF part I'd modify, however, is Section 2.3, where it says:

   If a conclusive determination about the
   message can be made based on a check of "HELO", then the use of DNS
   resources to process the typically more complex "MAIL FROM" can be
   avoided.

I'd append to that sentence:

  , unless downstream filters need it anyway.

Since we're at it, that paragraph continues with the following sentence:

Additionally, since SPF records published for "HELO"
   identities refer to a single host, when available, they are a very
   reliable source of host authorization status.

Isn't that the exact opposite of what many of us are claiming?  And is it legit 
for a proposed standard to quietly counter an existing proposed standard 
without some kind of rationale?




If we want, we can say not to use the SPF HELO identity, but that would be
an incompatible change to 7489 and I suspect would not match what most
DMARC checking code does.



OTOH, relaxing the requirement that the SPF HELO identity be used only when 
MAIL FROM is empty brings no incompatibility.  It's just a cleanup.



Best
Ale
--




























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

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

[Scott Kitterman]

I think that we're well past learning anything new in this thread.

SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the protocol 
(and shouldn't).  For any properly implemented SPF verifier, DMARC should be 
able to consume the Mail From result.  End of story.

I'd suggest close the ticket and move on.

Scott K

On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> I don't see any justification for using HELO unless the SMTP address is
> null.  If the SPF RFC says otherwise, this should be corrected.   Proving
> that the server domain can be tied to the IP address does nothing to prove
> that the SMTP address can be tied to the Source IP.
> 
> For DMARC, HELO is only useful if the message's From domain and the
> server's HELO domain are aligned.  A high percentage of email domains use
> servers from a different DNS domain, so this will only be true on an
> exception basis..   Consequently, software products that apply DKIM
> signatures to messages MUST be able to them to automatic messages as well.
>  Once developers provide MTA and mailstore products which service the needs
> of hosted domains, then users of non-hosted domains will be able to sign
> their automatic messages as well.   Ergo, any supposed need for HELO with
> DMARC will go away.
> 
> DF
> 
> On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:
> > On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> > > One way to interpret RFC 7489 is that you can put dmarc=pass based on
> > 
> > the
> > 
> > > helo identity *only if* MAIL FROM is null.
> > 
> > That would be consistent with 7489.
> > 
> > Sec 3.1.2 says
> > 
> > Note that the RFC5321.HELO identity is not typically used in the
> > context of DMARC (except when required to "fake" an otherwise null
> > reverse-path), even though a "pure SPF" implementation according to
> > [SPF] would check that identifier.
> > 
> > But then 4.1 says
> > 
> > o  [SPF], which can authenticate both the domain found in an [SMTP]
> > 
> >HELO/EHLO command (the HELO identity) and the domain found in an
> >SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
> >of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >[SPF] describes MAIL FROM processing for cases in which the MAIL
> >command has a null path.
> > 
> > That section of 7208 says that if there's a null bounce address, SPF
> > pretends that the MAIL FROM was postmaster@HELO.
> > 
> > If we want, we can say not to use the SPF HELO identity, but that would be
> > an incompatible change to 7489 and I suspect would not match what most
> > DMARC checking code does.
> > 
> > Regards,
> > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail. https://jl.ly
> > 
> > ___
> > 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

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

[Douglas Foster]

I don't see any justification for using HELO unless the SMTP address is
null.  If the SPF RFC says otherwise, this should be corrected.   Proving
that the server domain can be tied to the IP address does nothing to prove
that the SMTP address can be tied to the Source IP.

For DMARC, HELO is only useful if the message's From domain and the
server's HELO domain are aligned.  A high percentage of email domains use
servers from a different DNS domain, so this will only be true on an
exception basis..   Consequently, software products that apply DKIM
signatures to messages MUST be able to them to automatic messages as well.
 Once developers provide MTA and mailstore products which service the needs
of hosted domains, then users of non-hosted domains will be able to sign
their automatic messages as well.   Ergo, any supposed need for HELO with
DMARC will go away.

DF


On Sun, Jan 31, 2021 at 11:52 AM John R Levine  wrote:

> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> > One way to interpret RFC 7489 is that you can put dmarc=pass based on
> the
> > helo identity *only if* MAIL FROM is null.
>
> That would be consistent with 7489.
>
> Sec 3.1.2 says
>
> Note that the RFC5321.HELO identity is not typically used in the
> context of DMARC (except when required to "fake" an otherwise null
> reverse-path), even though a "pure SPF" implementation according to
> [SPF] would check that identifier.
>
> But then 4.1 says
>
> o  [SPF], which can authenticate both the domain found in an [SMTP]
>HELO/EHLO command (the HELO identity) and the domain found in an
>SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
>of SPF authentication of the MAIL FROM identity.  Section 2.4 of
>[SPF] describes MAIL FROM processing for cases in which the MAIL
>command has a null path.
>
> That section of 7208 says that if there's a null bounce address, SPF
> pretends that the MAIL FROM was postmaster@HELO.
>
> If we want, we can say not to use the SPF HELO identity, but that would be
> an incompatible change to 7489 and I suspect would not match what most
> DMARC checking code does.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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

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

[John R Levine]

On Sun, 31 Jan 2021, Alessandro Vesely wrote:
One way to interpret RFC 7489 is that you can put dmarc=pass based on the 
helo identity *only if* MAIL FROM is null.


That would be consistent with 7489.

Sec 3.1.2 says

   Note that the RFC5321.HELO identity is not typically used in the
   context of DMARC (except when required to "fake" an otherwise null
   reverse-path), even though a "pure SPF" implementation according to
   [SPF] would check that identifier.

But then 4.1 says

   o  [SPF], which can authenticate both the domain found in an [SMTP]
  HELO/EHLO command (the HELO identity) and the domain found in an
  SMTP MAIL command (the MAIL FROM identity).  DMARC uses the result
  of SPF authentication of the MAIL FROM identity.  Section 2.4 of
  [SPF] describes MAIL FROM processing for cases in which the MAIL
  command has a null path.

That section of 7208 says that if there's a null bounce address, SPF 
pretends that the MAIL FROM was postmaster@HELO.


If we want, we can say not to use the SPF HELO identity, but that would be 
an incompatible change to 7489 and I suspect would not match what most 
DMARC checking code does.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Alessandro Vesely]

On Sat 30/Jan/2021 22:57:44 +0100 John R Levine wrote:


Part of the problem here is that DMARC generally sits on top of an SPF library 
which doesn't tell you how it got its result.  My DMARC code just calls the SPF 
library and uses the result.  I suppose I could put in a hack to say don't use 
the SPF result if the MAIL FROM is null, but I don't think that's what 7489 says.



One way to interpret RFC 7489 is that you can put dmarc=pass based on the helo 
identity *only if* MAIL FROM is null.  So the hack there is a bit more tricky. 
 You want to use the SPF result only if MAIL FROM is null, except in cases 
when you authenticate based on MAIL FROM.  That's idiosyncratic!




On Sat 30/Jan/2021 20:59:13 +0100 Jim Fenton wrote:

The fact that a message sender can put anything there makes HELO basically
meaningless.



Here "message sender" has to be a mail server admin.  Compare with MAIL FROM, 
where "message sender" is the actual author submitting a message.  How come 
that the same assertion being more widely true for MAIL FROM doesn't make the 
latter basically meaningless?




Best
Ale
--





















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

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

[Douglas Foster]

The SMTP address and the HELO name are very similar in their trust
characteristics.
Both of them can be manipulated maliciously, but both can be verified with
similar techniques:   Using a DNS lookup to associate the name
assertion with the Source IP.
(We all know that the Source IP can be manipulated with a NAT device
sitting outside a network perimeter, but we ignore that possibility.   If
it is happening, there are worse things than email verification occurring.)

We do know that Reverse DNS is often outside the control of the mail
domain, so it is actually a less reliable indicator of domain ownership
than Helo.

Overall, the SPF design seems very intuitive and defensible.
I think it is unrealistic to expect rapid implementation of DKIM signatures
on null-address messages, and HELO is a good substitute.  Nor does it seem
necessary.  I see no problem using HELO in my DMARC evaluations when the
SMTP address is null.

My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting.   It should not be ignored.

Doug Foster
.

On Sat, Jan 30, 2021 at 7:44 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Anything can be gamed if it is trusted without verification. But
> verifiable data is hard to game.   If you ensure that Helo can be forward
> confirmed before considering it trusted, how is it risky?
>
>
> On Sat, Jan 30, 2021, 5:45 PM Michael Thomas  wrote:
>
>>
>> On 1/30/21 2:09 PM, John R Levine wrote:
>> > On Sat, 30 Jan 2021, Jim Fenton wrote:
>> >>> Part of the problem here is that DMARC generally sits on top of an
>> >>> SPF library which doesn't tell you how it got its result.  My DMARC
>> >>> code just calls the SPF library and uses the result.  I suppose I
>> >>> could put in a hack to say don't use the SPF result if the MAIL FROM
>> >>> is null, but I don't think that's what 7489 says.
>> >>
>> >> Are changes to 7489 off the table here? I didn’t know.
>> >
>> > They are certainly possible, but I would want a good reason.  At this
>> > point, SPF using HELO seems harmless so I don't see a reason to
>> > disallow it.
>> >
>> >
>>  From a security standpoint, I wonder why you would want to allow
>> something you know can be gamed. But that is probably more a question
>> for SPF itself.
>>
>> Mike
>>
>> ___
>> 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

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

[Douglas Foster]

Anything can be gamed if it is trusted without verification. But verifiable
data is hard to game.   If you ensure that Helo can be forward confirmed
before considering it trusted, how is it risky?


On Sat, Jan 30, 2021, 5:45 PM Michael Thomas  wrote:

>
> On 1/30/21 2:09 PM, John R Levine wrote:
> > On Sat, 30 Jan 2021, Jim Fenton wrote:
> >>> Part of the problem here is that DMARC generally sits on top of an
> >>> SPF library which doesn't tell you how it got its result.  My DMARC
> >>> code just calls the SPF library and uses the result.  I suppose I
> >>> could put in a hack to say don't use the SPF result if the MAIL FROM
> >>> is null, but I don't think that's what 7489 says.
> >>
> >> Are changes to 7489 off the table here? I didn’t know.
> >
> > They are certainly possible, but I would want a good reason.  At this
> > point, SPF using HELO seems harmless so I don't see a reason to
> > disallow it.
> >
> >
>  From a security standpoint, I wonder why you would want to allow
> something you know can be gamed. But that is probably more a question
> for SPF itself.
>
> Mike
>
> ___
> 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

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

[Scott Kitterman]

On Saturday, January 30, 2021 5:44:47 PM EST Michael Thomas wrote:
> On 1/30/21 2:09 PM, John R Levine wrote:
> > On Sat, 30 Jan 2021, Jim Fenton wrote:
> >>> Part of the problem here is that DMARC generally sits on top of an
> >>> SPF library which doesn't tell you how it got its result.  My DMARC
> >>> code just calls the SPF library and uses the result.  I suppose I
> >>> could put in a hack to say don't use the SPF result if the MAIL FROM
> >>> is null, but I don't think that's what 7489 says.
> >> 
> >> Are changes to 7489 off the table here? I didn’t know.
> > 
> > They are certainly possible, but I would want a good reason.  At this
> > point, SPF using HELO seems harmless so I don't see a reason to
> > disallow it.
> 
>  From a security standpoint, I wonder why you would want to allow
> something you know can be gamed. But that is probably more a question
> for SPF itself.

From a DMARC perspective, I don't think it can be in any useful way.  Agree 
that digging into it further is more about SPF itself, presumably OT here.

Scott K


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

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

[Michael Thomas]

On 1/30/21 2:09 PM, John R Levine wrote:

On Sat, 30 Jan 2021, Jim Fenton wrote:
Part of the problem here is that DMARC generally sits on top of an 
SPF library which doesn't tell you how it got its result.  My DMARC 
code just calls the SPF library and uses the result.  I suppose I 
could put in a hack to say don't use the SPF result if the MAIL FROM 
is null, but I don't think that's what 7489 says.


Are changes to 7489 off the table here? I didn’t know.


They are certainly possible, but I would want a good reason.  At this 
point, SPF using HELO seems harmless so I don't see a reason to 
disallow it.



From a security standpoint, I wonder why you would want to allow 
something you know can be gamed. But that is probably more a question 
for SPF itself.


Mike

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

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

[John R Levine]

On Sat, 30 Jan 2021, Jim Fenton wrote:
Part of the problem here is that DMARC generally sits on top of an SPF 
library which doesn't tell you how it got its result.  My DMARC code just 
calls the SPF library and uses the result.  I suppose I could put in a hack 
to say don't use the SPF result if the MAIL FROM is null, but I don't think 
that's what 7489 says.


Are changes to 7489 off the table here? I didn’t know.


They are certainly possible, but I would want a good reason.  At this 
point, SPF using HELO seems harmless so I don't see a reason to disallow 
it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

On 30 Jan 2021, at 13:57, John R Levine wrote:

This is DMARC -- the HELO domain has to match the header From: and 
there

has to be an SPF record that validates it.


True, but only if the MAIL FROM address is null and there isn’t a 
valid aligned DKIM signature.


True, but I don't see why that matters.


Just confirming the context of your earlier statement.

Because that's how DMARC works.  The header From has to match a DKIM 
or SPF identity.


Part of the problem here is that DMARC generally sits on top of an SPF 
library which doesn't tell you how it got its result.  My DMARC code 
just calls the SPF library and uses the result.  I suppose I could put 
in a hack to say don't use the SPF result if the MAIL FROM is null, 
but I don't think that's what 7489 says.


Are changes to 7489 off the table here? I didn’t know.

-Jim

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

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

[John R Levine]

This is DMARC -- the HELO domain has to match the header From: and there
has to be an SPF record that validates it.


True, but only if the MAIL FROM address is null and there isn’t a valid 
aligned DKIM signature.


True, but I don't see why that matters.


The most plausible case is that it's a bounce messsage

 From: mailer-dae...@mta27.foo.bar.example.com

the MAIL FROM is null, HELO is mta27.foo.bar.example.com, and the SPF
record for mta27.foo.bar.com says that IP is OK.


So in this case, why involve the HELO at all? One could just check the SPF 
record of the header From: that it’s trying to align with. Except that’s 
probably SenderID, not SPF.


Because that's how DMARC works.  The header From has to match a DKIM or 
SPF identity.


Part of the problem here is that DMARC generally sits on top of an SPF 
library which doesn't tell you how it got its result.  My DMARC code just 
calls the SPF library and uses the result.  I suppose I could put in a 
hack to say don't use the SPF result if the MAIL FROM is null, but I don't 
think that's what 7489 says.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

On 30 Jan 2021, at 13:23, John Levine wrote:

In article  you 
write:
The issue isn’t the existing use of HELO names, it’s how they 
could

be (mis-)used. The fact that a message sender can put anything there
makes HELO basically meaningless.


This is DMARC -- the HELO domain has to match the header From: and 
there

has to be an SPF record that validates it.


True, but only if the MAIL FROM address is null and there isn’t a 
valid aligned DKIM signature.



The most plausible case is that it's a bounce messsage

 From: mailer-dae...@mta27.foo.bar.example.com

the MAIL FROM is null, HELO is mta27.foo.bar.example.com, and the SPF
record for mta27.foo.bar.com says that IP is OK.


So in this case, why involve the HELO at all? One could just check the 
SPF record of the header From: that it’s trying to align with. Except 
that’s probably SenderID, not SPF.


-Jim

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

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

[John Levine]

In article <20210130212339.447316d04...@ary.qy> you write:
>In article  you write:
>>The issue isn’t the existing use of HELO names, it’s how they could 
>>be (mis-)used. The fact that a message sender can put anything there 
>>makes HELO basically meaningless.
>
>This is DMARC -- the HELO domain has to match the header From: and there
>has to be an SPF record that validates it.
>
>The most plausible case is that it's a bounce messsage
>
> From: mailer-dae...@mta27.foo.bar.example.com
>
>the MAIL FROM is null, HELO is mta27.foo.bar.example.com, and the SPF
>record for mta27.foo.bar.com says that IP is OK.

I wish I could type: ... for mta27.foo.bar.example.com says that the IP is OK.

>I don't feel strongly about whether to use the HELO name but it doesn't break 
>anything.

R's,
John

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

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

[Douglas Foster]

As long as Helo is forward confirmed to the source IP, why is it a risk to
use it to indicate the domain name?

On Sat, Jan 30, 2021, 2:59 PM Jim Fenton  wrote:

> On 29 Jan 2021, at 12:30, Murray S. Kucherawy wrote:
>
> > On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely 
> > wrote:
> >
> >> I just run a quick test on my current folder.  Out of 3879 messages I
> >> extracted
> >> 944 unique helo names.  721 of these matched the reverse lookup
> >> exactly.
> >> Out
> >> of the 223 remaining, 127 had an SPF pass for the helo identity
> >> anyway.
> >> So in
> >> 96 cases, roughly 10%, the helo name was indeed junk.  Isn't the
> >> remaining
> >> ~90%
> >> something worth considering?
>
> The issue isn’t the existing use of HELO names, it’s how they could
> be (mis-)used. The fact that a message sender can put anything there
> makes HELO basically meaningless.
>
> > I am admittedly quite heavily biased against using the HELO/EHLO value
> > for
> > anything.  I have simply never found value in it, probably because at
> > the
> > SMTP layer it's simply a value that gets logged or used in cute ways
> > in the
> > human-readable portion of SMTP.  I seem to recall (but cannot seem to
> > find
> > at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a
> > bogus
> > value, so it's even explicitly not useful to me.
> >
> > Even if it's not junk, there's pretty much always something else on
> > which
> > to hang a pass/fail decision about the apparent authenticity of a
> > message
> > that at least feels safer if not actually being more sound.  Or put
> > another
> > way, if you present to me a DKIM-signed message with a MAIL FROM value
> > and
> > the only thing that passes is an SPF check against HELO, I'm mighty
> > skeptical.
> >
> > Anyway, I'll let consensus fall where it may.
>
> +1 to Murray’s comments. I realize that null MAIL FROM on bounce
> messages is a problem for SPF, but relying on HELO is  not a reasonable
> substitute.
>
> -Jim
>
> ___
> 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

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

[John Levine]

In article  you write:
>The issue isn’t the existing use of HELO names, it’s how they could 
>be (mis-)used. The fact that a message sender can put anything there 
>makes HELO basically meaningless.

This is DMARC -- the HELO domain has to match the header From: and there
has to be an SPF record that validates it.

The most plausible case is that it's a bounce messsage

 From: mailer-dae...@mta27.foo.bar.example.com

the MAIL FROM is null, HELO is mta27.foo.bar.example.com, and the SPF
record for mta27.foo.bar.com says that IP is OK.

I don't feel strongly about whether to use the HELO name but it doesn't break 
anything.

R's,
John

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

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

[Jim Fenton]

On 29 Jan 2021, at 12:30, Murray S. Kucherawy wrote:

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely  
wrote:



I just run a quick test on my current folder.  Out of 3879 messages I
extracted
944 unique helo names.  721 of these matched the reverse lookup 
exactly.

Out
of the 223 remaining, 127 had an SPF pass for the helo identity 
anyway.

So in
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the 
remaining

~90%
something worth considering?


The issue isn’t the existing use of HELO names, it’s how they could 
be (mis-)used. The fact that a message sender can put anything there 
makes HELO basically meaningless.


I am admittedly quite heavily biased against using the HELO/EHLO value 
for
anything.  I have simply never found value in it, probably because at 
the
SMTP layer it's simply a value that gets logged or used in cute ways 
in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to 
find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a 
bogus

value, so it's even explicitly not useful to me.

Even if it's not junk, there's pretty much always something else on 
which
to hang a pass/fail decision about the apparent authenticity of a 
message
that at least feels safer if not actually being more sound.  Or put 
another
way, if you present to me a DKIM-signed message with a MAIL FROM value 
and

the only thing that passes is an SPF check against HELO, I'm mighty
skeptical.

Anyway, I'll let consensus fall where it may.


+1 to Murray’s comments. I realize that null MAIL FROM on bounce 
messages is a problem for SPF, but relying on HELO is  not a reasonable 
substitute.


-Jim

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

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

[Douglas Foster]

I have been using forward-confirmed DNS in my filtering logic for a long
time.   These are my results from a recent time period:
4.5% neither name confirmed
9.6% reverse DNS confirmed only
39.7% Helo confirmed only
46.2% Both confirmed

Of the ones where both were confirmed:
96% had the same domain in both names,
4% had different domains between HELO and REVDNS

I apply my DNS blacklisting rules to both domain names.
I often use a verified DNS domain (either type) with SMTP domain to define
corrections for sender SPF policy.
HELO is part of the SPF algorithm that I use, but I do not track how often
it is used to generate SPF PASS.
I use BATV to I don't worry much about SPF or DMARC for automatic messages.

Overall, I don't know how important HELO is to SPF, but it is verifiable
and often useful.

Doug Foster

On Sat, Jan 30, 2021 at 5:41 AM Alessandro Vesely  wrote:

> On Fri 29/Jan/2021 21:30:49 +0100 Murray S. Kucherawy wrote:
> > On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely 
> wrote:
> >
> >> I just run a quick test on my current folder.  Out of 3879 messages I
> >> extracted 944 unique helo names.  721 of these matched the reverse
> lookup
> >> exactly. Out of the 223 remaining, 127 had an SPF pass for the helo
> >> identity anyway. So in 96 cases, roughly 10%, the helo name was indeed
> >> junk.  Isn't the remaining ~90% something worth considering? >
> > I am admittedly quite heavily biased against using the HELO/EHLO value
> for
> > anything.  I have simply never found value in it, probably because at the
> > SMTP layer it's simply a value that gets logged or used in cute ways in
> the
> > human-readable portion of SMTP.  I seem to recall (but cannot seem to
> find
> > at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a
> bogus
> > value, so it's even explicitly not useful to me.
>
>
> There seems to be consensus on changing the MUST NOT there to a SHOULD
> NOT.
> See ticket #19 of emailcore.
>
>
> > Even if it's not junk, there's pretty much always something else on which
> > to hang a pass/fail decision about the apparent authenticity of a message
> > that at least feels safer if not actually being more sound.
>
>
> I might understand being reluctant to spend a DNS lookup for a TXT record
> that
> many operators don't care to define.  However, we're discussing the case
> that
> an upstream SPF filter already acquired and evaluated that record.
>
>
> > Or put another way, if you present to me a DKIM-signed message with a
> MAIL
> > FROM value and the only thing that passes is an SPF check against HELO,
> I'm
> > mighty skeptical.
>
> We have helo as the only valid identifier in most DSNs.  What is
> idiosyncratic
> is that a message MUST be a DSN (i.e. have an empty mfrom) in order for an
> already authenticated helo to be considered significant.  What I'm
> proposing is
> actually a simplification.
>
>
> > Anyway, I'll let consensus fall where it may.
>
>
> Thank you
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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

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

[Alessandro Vesely]

On Fri 29/Jan/2021 21:30:49 +0100 Murray S. Kucherawy wrote:

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely  wrote:

I just run a quick test on my current folder.  Out of 3879 messages I 
extracted 944 unique helo names.  721 of these matched the reverse lookup

exactly. Out of the 223 remaining, 127 had an SPF pass for the helo
identity anyway. So in 96 cases, roughly 10%, the helo name was indeed
junk.  Isn't the remaining ~90% something worth considering? >

I am admittedly quite heavily biased against using the HELO/EHLO value for
anything.  I have simply never found value in it, probably because at the
SMTP layer it's simply a value that gets logged or used in cute ways in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a bogus
value, so it's even explicitly not useful to me.



There seems to be consensus on changing the MUST NOT there to a SHOULD NOT. 
See ticket #19 of emailcore.




Even if it's not junk, there's pretty much always something else on which
to hang a pass/fail decision about the apparent authenticity of a message
that at least feels safer if not actually being more sound.



I might understand being reluctant to spend a DNS lookup for a TXT record that 
many operators don't care to define.  However, we're discussing the case that 
an upstream SPF filter already acquired and evaluated that record.




Or put another way, if you present to me a DKIM-signed message with a MAIL
FROM value and the only thing that passes is an SPF check against HELO, I'm
mighty skeptical.


We have helo as the only valid identifier in most DSNs.  What is idiosyncratic 
is that a message MUST be a DSN (i.e. have an empty mfrom) in order for an 
already authenticated helo to be considered significant.  What I'm proposing is 
actually a simplification.




Anyway, I'll let consensus fall where it may.



Thank you
Ale
--



















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

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

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely  wrote:

> I just run a quick test on my current folder.  Out of 3879 messages I
> extracted
> 944 unique helo names.  721 of these matched the reverse lookup exactly.
> Out
> of the 223 remaining, 127 had an SPF pass for the helo identity anyway.
> So in
> 96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining
> ~90%
> something worth considering?
>

I am admittedly quite heavily biased against using the HELO/EHLO value for
anything.  I have simply never found value in it, probably because at the
SMTP layer it's simply a value that gets logged or used in cute ways in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a bogus
value, so it's even explicitly not useful to me.

Even if it's not junk, there's pretty much always something else on which
to hang a pass/fail decision about the apparent authenticity of a message
that at least feels safer if not actually being more sound.  Or put another
way, if you present to me a DKIM-signed message with a MAIL FROM value and
the only thing that passes is an SPF check against HELO, I'm mighty
skeptical.

Anyway, I'll let consensus fall where it may.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Thu 28/Jan/2021 21:40:49 +0100 Murray S. Kucherawy wrote:

On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely  wrote:

DKIM (in its simplest form) returns N tuples of the form (d= domain, 
pass/fail).  All of them were run through exactly the same check; all

of them were attached to the message in exactly the same way; all of
them have essentially identical semantics.  Giving them equal footing
makes sense to me. >>>
The two identifiers in SPF hold different places in the SMTP session,
and have different semantics.  I think treating them differently is also
just fine. >>
It is relevant that both identifier come from /the same/ SMTP session. 
That's not true for many DKIM signatures. >

I guess if report consumers really want this information, we can include
it.



Helo is essential if mfrom is missing.  A second SPF identifier is optional 
anyway.



I just don't see the value in the HELO parameter if it's effectively
random junk in the session.



Where does that notion come from?  Most mail admins choose the helo name 
carefully, possibly so that it resolves both ways to the IP number.


I just run a quick test on my current folder.  Out of 3879 messages I extracted 
944 unique helo names.  721 of these matched the reverse lookup exactly.  Out 
of the 223 remaining, 127 had an SPF pass for the helo identity anyway.  So in 
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining ~90% 
something worth considering?




At least a passing DKIM signature is associated with a domain that existed
at some point in time and whose DNS contained apparently-valid public keys.


Why cannot one type DKIM-Signature: d=anyrandomjunk ...?



I can mostly type anything I want to HELO or EHLO.



That's true for any identifier.  We know an identifier is associated with a 
domain that existed at some point in time only after it's been authenticated.


One may say DKIM authentication is somewhat more precise, because the vogue is 
to include whole classes of IPs in SPF records.  But then, such lack of 
accuracy affects mfrom and helo alike.


The real difference between helo and mfrom is that the former is a 
configuration parameter of the sending relay, while the latter is set by the 
submission client.  The former is akin to d= and s=, while the latter is akin 
to From:.  No rationale to discard either, AFAICS.



Best
Ale
--















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

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

[Murray S. Kucherawy]

On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely  wrote:

> > DKIM (in its simplest form) returns N tuples of the form (d= domain,
> > pass/fail).  All of them were run through exactly the same check; all of
> > them were attached to the message in exactly the same way; all of them
> have
> > essentially identical semantics.  Giving them equal footing makes sense
> to
> > me.
> >
> > The two identifiers in SPF hold different places in the SMTP session, and
> > have different semantics.  I think treating them differently is also just
> > fine.
>
> It is relevant that both identifier come from /the same/ SMTP session.
> That's
> not true for many DKIM signatures.
>

I guess if report consumers really want this information, we can include
it.  I just don't see the value in the HELO parameter if it's effectively
random junk in the session.  At least a passing DKIM signature is
associated with a domain that existed at some point in time and whose DNS
contained apparently-valid public keys.  I can mostly type anything I want
to HELO or EHLO.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Wed 27/Jan/2021 21:10:37 +0100 Murray S. Kucherawy wrote:

On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely  wrote:


AFAIUI, there's no reason why SPF would work with a logic substantially
different than DKIM's.  DKIM can provide n identifiers, if one of them is
aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers
but one of them is of class B.  WTF?


DKIM (in its simplest form) returns N tuples of the form (d= domain,
pass/fail).  All of them were run through exactly the same check; all of
them were attached to the message in exactly the same way; all of them have
essentially identical semantics.  Giving them equal footing makes sense to
me.

The two identifiers in SPF hold different places in the SMTP session, and
have different semantics.  I think treating them differently is also just
fine.



It is relevant that both identifier come from /the same/ SMTP session.  That's 
not true for many DKIM signatures.



In addition, as I said, SPF filters are likely to report HELO as helo and 
MAIL FROM as mailfrom.  If we want to carry over this quirk, the spec must

say that a DMARC filter which gathers SPF authentication status from an
upstream filter MUST make sure that mailfrom is empty before validating
based on an aligned helo. >

...or it doesn't evaluate against SPF at all in such a situation.



Dropping SPF altogether is too much.  I'm querying about dropping just the 
idiosyncrasy...




Dropping that absurd discrimination between SPF identifiers would make
for a smoother spec.  Since non-null mailfroms are in most cases aligned
with either From: or helo, the differences between existing compliant
implementations and the smoother spec would be limited to a hardly
noticeable set of test messages. >

I don't think we should ignore what those two identifiers mean, how likely
they are to contain junk, how they are applied, outside of DMARC, etc.



How is that different from d= identifiers?


Best
Ale
--





















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

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

[Alessandro Vesely]

On Wed 27/Jan/2021 20:24:05 +0100 Scott Kitterman wrote:

On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote:


Can we fix this aberration?

The spec needs a fix anyway, because from the text I quoted above I
understood that the example message passes DMARC.  Am I the only one?

In addition, as I said, SPF filters are likely to report HELO as helo and
MAIL FROM as mailfrom.  If we want to carry over this quirk, the spec must
say that a DMARC filter which gathers SPF authentication status from an
upstream filter MUST make sure that mailfrom is empty before validating
based on an aligned helo.

Dropping that absurd discrimination between SPF identifiers would make for a
smoother spec.  Since non-null mailfroms are in most cases aligned with
either From: or helo, the differences between existing compliant
implementations and the smoother spec would be limited to a hardly
noticeable set of test messages.


Your absurd is my eminently reasonable.

I can't explain why it was added, but it makes sense, IMO, to have it there to
aid in reconstructing the exact situation for trouble shooting purposes.



Can you expand on how ignoring helo aids trouble shooting?



DMARC has always (for the SPF related portion) been about alignment of mail
from and from.  I don't think adding HELO has appreciable value and is
certainly not worth the added complexity to implement DMARC to include.



From an implementer POV, the complication stays in the idiosyncratic 
identifier processing.  I wonder how many do follow it strictly.  IMHO, a 
reasonable DMARC spec should either smooth out the discrimination or provide a 
clear explanation of why such peculiar processing is needed and what would 
happen if all identifiers were treated equal.




There are lots of ways that DMARC could have addressed SPF.  Personally I
thought it might make sense to skip using the mail from SPF result and just
check if the from address would pass if it were subjected to an SPF check, but
that's not the existing design.  I don't think it should be changed now.



Yeah, after you insisted, I vaguely recollected about an SPF argument that I 
had erased from memory.  I can't recall its merit.


DKIM'S d= are domains, and DKIM scope is exactly to identify a domain.  That's 
more akin to helo than mail from.



Best
Ale
--

























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

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

[Murray S. Kucherawy]

On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely  wrote:

> AFAIUI, there's no reason why SPF would work with a logic substantially
> different than DKIM's.  DKIM can provide n identifiers, if one of them is
> aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers
> but
> one of them is of class B.  WTF?
>

DKIM (in its simplest form) returns N tuples of the form (d= domain,
pass/fail).  All of them were run through exactly the same check; all of
them were attached to the message in exactly the same way; all of them have
essentially identical semantics.  Giving them equal footing makes sense to
me.

The two identifiers in SPF hold different places in the SMTP session, and
have different semantics.  I think treating them differently is also just
fine.

Can anyone explain why we have a helo element in aggregate
> reports?
>

Not off the top of my head.  If it's not meaningful, it should go.

In addition, as I said, SPF filters are likely to report HELO as helo and
> MAIL
> FROM as mailfrom.  If we want to carry over this quirk, the spec must say
> that
> a DMARC filter which gathers SPF authentication status from an upstream
> filter
> MUST make sure that mailfrom is empty before validating based on an
> aligned helo.
>

...or it doesn't evaluate against SPF at all in such a situation.

Dropping that absurd discrimination between SPF identifiers would make for
> a
> smoother spec.  Since non-null mailfroms are in most cases aligned with
> either
> From: or helo, the differences between existing compliant implementations
> and
> the smoother spec would be limited to a hardly noticeable set of test
> messages.
>

I don't think we should ignore what those two identifiers mean, how likely
they are to contain junk, how they are applied, outside of DMARC, etc.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote:
> On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:
> > On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
> >> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
> >>> On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
>  On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
> > On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> >> I doubt that SPF filters report envelope-from=postmaster@HELO; more
> >> likely they write helo=HELO.  In that case, the paragraph quoted
> >> above
> >> is deceptive.
> >> 
> >>> I believe the proposed text is clear enough about not using
> >>> separate HELO identity results and that's appropriate. 
> >> 
> >> My filter collects SPF results recorded from an upstream SPF filter.
> >> It writes Received-SPF: lines for each identity.  For NDNs, it writes
> >> a Received-SPF: for the HELO identity only.  Am I allowed to use that
> >> result for DMARC?
> > 
> > No.  You should only use Mail From results.
>  
>  So NDNs having only an aligned HELO will never pass DMARC?
>  
>  And what is a helo element in aggregate reports provided
>  for?
>  
>  The spec says:
>    [SPF] can authenticate either the domain that appears in the
>  
>  RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
>  HELO domain, or both.
>  
>  And then:
>  In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
>  domain must have the same Organizational Domain.  In strict mode,
>  only an exact DNS domain match is considered to produce Identifier
>  Alignment.
>  
>  So, consider the following message without DKIM signatures:
>  
>  HELO example.org
>  MAIL FROM:
>  
>  Received-SPF: pass (domain example.org
>  
> designates 192.0.2.1 as permitted sender)
> identity=helo; helo=example.org;
>  
>  Received-SPF: fail (domain of u...@example.com
>  
> denies 192.0.2.1 as permitted sender)
> identity=mailfrom; envelope-from="u...@example.com";
>  
>  Subject: Not using a mail client for this example
>  From: different-u...@example.org
>  
>  Does it pass DMARC?
> >>> 
> >>> No.
> >> 
> >> Let's not be silly, Scott.  We have example.org as the SPF-authenticated
> >> domain and it is aligned with From:.  Are you saying that the message
> >> would pass if it had an empty bounce address, but since it can bounce it
> >> does not pass?!? >
> > 
> > All I'm saying is that DMARC only uses mail from results and that's
> > appropriate.  I don't think the case of HELO name being aligned, but mail
> > from domain is not is one to worry about.
> 
> That's abnormal, not appropriate.
> 
> AFAIUI, there's no reason why SPF would work with a logic substantially
> different than DKIM's.  DKIM can provide n identifiers, if one of them is
> aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers but
> one of them is of class B.  WTF?
> 
> Can anyone explain why we have a helo element in aggregate
> reports?
> 
> Can we fix this aberration?
> 
> The spec needs a fix anyway, because from the text I quoted above I
> understood that the example message passes DMARC.  Am I the only one?
> 
> In addition, as I said, SPF filters are likely to report HELO as helo and
> MAIL FROM as mailfrom.  If we want to carry over this quirk, the spec must
> say that a DMARC filter which gathers SPF authentication status from an
> upstream filter MUST make sure that mailfrom is empty before validating
> based on an aligned helo.
> 
> Dropping that absurd discrimination between SPF identifiers would make for a
> smoother spec.  Since non-null mailfroms are in most cases aligned with
> either From: or helo, the differences between existing compliant
> implementations and the smoother spec would be limited to a hardly
> noticeable set of test messages.

Your absurd is my eminently reasonable.

I can't explain why it was added, but it makes sense, IMO, to have it there to 
aid in reconstructing the exact situation for trouble shooting purposes.

DMARC has always (for the SPF related portion) been about alignment of mail 
from and from.  I don't think adding HELO has appreciable value and is 
certainly not worth the added complexity to implement DMARC to include.

There are lots of ways that DMARC could have addressed SPF.  Personally I 
thought it might make sense to skip using the mail from SPF result and just 
check if the from address would pass if it were subjected to an SPF check, but 
that's not the existing design.  I don't think it should be changed now.

That said, I agree it's not 100% clear.  I too am interested in what others 
think.

Scott K


___
dmarc 

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

[Alessandro Vesely]

On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:

On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:

On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:

On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:

I doubt that SPF filters report envelope-from=postmaster@HELO; more
likely they write helo=HELO.  In that case, the paragraph quoted above
is deceptive.


I believe the proposed text is clear enough about not using
separate HELO identity results and that's appropriate. 


My filter collects SPF results recorded from an upstream SPF filter.
It writes Received-SPF: lines for each identity.  For NDNs, it writes
a Received-SPF: for the HELO identity only.  Am I allowed to use that
result for DMARC?


No.  You should only use Mail From results.


So NDNs having only an aligned HELO will never pass DMARC?

And what is a helo element in aggregate reports provided
for?

The spec says:
  [SPF] can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
HELO domain, or both.

And then:
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
domain must have the same Organizational Domain.  In strict mode,
only an exact DNS domain match is considered to produce Identifier
Alignment.

So, consider the following message without DKIM signatures:

HELO example.org
MAIL FROM:

Received-SPF: pass (domain example.org
   designates 192.0.2.1 as permitted sender)
   identity=helo; helo=example.org;
Received-SPF: fail (domain of u...@example.com
   denies 192.0.2.1 as permitted sender)
   identity=mailfrom; envelope-from="u...@example.com";
Subject: Not using a mail client for this example
From: different-u...@example.org

Does it pass DMARC?


No.


Let's not be silly, Scott.  We have example.org as the SPF-authenticated 
domain and it is aligned with From:.  Are you saying that the message

would pass if it had an empty bounce address, but since it can bounce it
does not pass?!? >
All I'm saying is that DMARC only uses mail from results and that's 
appropriate.  I don't think the case of HELO name being aligned, but mail

from domain is not is one to worry about.


That's abnormal, not appropriate.

AFAIUI, there's no reason why SPF would work with a logic substantially 
different than DKIM's.  DKIM can provide n identifiers, if one of them is 
aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers but 
one of them is of class B.  WTF?


Can anyone explain why we have a helo element in aggregate 
reports?

Can we fix this aberration?

The spec needs a fix anyway, because from the text I quoted above I understood 
that the example message passes DMARC.  Am I the only one?


In addition, as I said, SPF filters are likely to report HELO as helo and MAIL 
FROM as mailfrom.  If we want to carry over this quirk, the spec must say that 
a DMARC filter which gathers SPF authentication status from an upstream filter 
MUST make sure that mailfrom is empty before validating based on an aligned helo.


Dropping that absurd discrimination between SPF identifiers would make for a 
smoother spec.  Since non-null mailfroms are in most cases aligned with either 
From: or helo, the differences between existing compliant implementations and 
the smoother spec would be limited to a hardly noticeable set of test messages.



Best
Ale
--





















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

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

[Scott Kitterman]

On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
> > On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
> >> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
> >>> On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
>  I doubt that SPF filters report envelope-from=postmaster@HELO; more
>  likely they write helo=HELO.  In that case, the paragraph quoted above
>  is deceptive. 
>  
> > I believe the proposed text is clear enough about not using
> > separate HELO identity results and that's appropriate. 
>  
>  My filter collects SPF results recorded from an upstream SPF filter.
>  It writes Received-SPF: lines for each identity.  For NDNs, it writes
>  a Received-SPF: for the HELO identity only.  Am I allowed to use that
>  result for DMARC? >>>
> >>> 
> >>> No.  You should only use Mail From results.
> >> 
> >> So NDNs having only an aligned HELO will never pass DMARC?
> >> 
> >> And what is a helo element in aggregate reports provided
> >> for?>> 
> >> The spec says:
> >>   [SPF] can authenticate either the domain that appears in the
> >> 
> >> RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
> >> HELO domain, or both.
> >> 
> >> And then:
> >> In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
> >> domain must have the same Organizational Domain.  In strict mode,
> >> only an exact DNS domain match is considered to produce Identifier
> >> Alignment.
> >> 
> >> So, consider the following message without DKIM signatures:
> >> 
> >> HELO example.org
> >> MAIL FROM:
> >> 
> >> Received-SPF: pass (domain example.org
> >> 
> >>designates 192.0.2.1 as permitted sender)
> >>identity=helo; helo=example.org;
> >> 
> >> Received-SPF: fail (domain of u...@example.com
> >> 
> >>denies 192.0.2.1 as permitted sender)
> >>identity=mailfrom; envelope-from="u...@example.com";
> >> 
> >> Subject: Not using a mail client for this example
> >> From: different-u...@example.org
> >> 
> >> Does it pass DMARC?
> > 
> > No.
> 
> Let's not be silly, Scott.  We have example.org as the SPF-authenticated
> domain and it is aligned with From:.  Are you saying that the message would
> pass if it had an empty bounce address, but since it can bounce it does not
> pass?!?

All I'm saying is that DMARC only uses mail from results and that's 
appropriate.  I don't think the case of HELO name being aligned, but mail from 
domain is not is one to worry about.

Scott K


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

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

[Alessandro Vesely]

On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:

On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:


I doubt that SPF filters report envelope-from=postmaster@HELO; more 
likely they write helo=HELO.  In that case, the paragraph quoted above

is deceptive. 

I believe the proposed text is clear enough about not using
separate HELO identity results and that's appropriate. 

My filter collects SPF results recorded from an upstream SPF filter.
It writes Received-SPF: lines for each identity.  For NDNs, it writes
a Received-SPF: for the HELO identity only.  Am I allowed to use that 
result for DMARC? >>>

No.  You should only use Mail From results.


So NDNs having only an aligned HELO will never pass DMARC?

And what is a helo element in aggregate reports provided for?

The spec says:

  [SPF] can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
HELO domain, or both.

And then:

In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
domain must have the same Organizational Domain.  In strict mode,
only an exact DNS domain match is considered to produce Identifier
Alignment.

So, consider the following message without DKIM signatures:

HELO example.org
MAIL FROM:

Received-SPF: pass (domain example.org
   designates 192.0.2.1 as permitted sender)
   identity=helo; helo=example.org;
Received-SPF: fail (domain of u...@example.com
   denies 192.0.2.1 as permitted sender)
   identity=mailfrom; envelope-from="u...@example.com";
Subject: Not using a mail client for this example
From: different-u...@example.org

Does it pass DMARC?


No.



Let's not be silly, Scott.  We have example.org as the SPF-authenticated domain 
and it is aligned with From:.  Are you saying that the message would pass if it 
had an empty bounce address, but since it can bounce it does not pass?!?



Best
Ale
--






















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

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

[Scott Kitterman]

On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
> > On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> >> On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:
> >>> On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:
>  May I propose that the section labeled "SPF-Authenticated Identifiers"
>  be
>  rewritten as follows:
>  
>  [...]
>  
> The reader should note that SPF alignment checks in DMARC rely
> solely
> on the RFC5321.MailFrom domain. This differs from section 2.3 of
> [@!RFC7208], which recommends that SPF checks be done on not only
> the
> "MAIL FROM" but also on a separate check of the "HELO" identity. >
> >>> 
> >>> I think this is fine, but there is a subtlety to be aware of.
> >>> 
> >>> If you look at RFC 7208 Section 2.4, when Mail From is null,
> >>> postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
> >>> change that.
> >>> 
> >>> As a result, there are cases where Mail From results actually are
> >>> derived
> >>> from HELO and it's unavoidable.
> >> 
> >> I doubt that SPF filters report envelope-from=postmaster@HELO; more
> >> likely
> >> they write helo=HELO.  In that case, the paragraph quoted above is
> >> deceptive.
> >> 
> >>> I believe the proposed text is clear enough about not using separate
> >>> HELO
> >>> identity results and that's appropriate.
> >> 
> >> My filter collects SPF results recorded from an upstream SPF filter.  It
> >> writes Received-SPF: lines for each identity.  For NDNs, it writes a
> >> Received-SPF: for the HELO identity only.  Am I allowed to use that
> >> result
> >> for DMARC?
> > 
> > No.  You should only use Mail From results.
> 
> So NDNs having only an aligned HELO will never pass DMARC?
> 
> And what is a helo element in aggregate reports provided for?
> 
> The spec says:
> 
>   [SPF] can authenticate either the domain that appears in the
> RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
> HELO domain, or both.
> 
> And then:
> 
> In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
> domain must have the same Organizational Domain.  In strict mode,
> only an exact DNS domain match is considered to produce Identifier
> Alignment.
> 
> So, consider the following message without DKIM signatures:
> 
> HELO example.org
> MAIL FROM:
> 
> Received-SPF: pass (domain example.org
>designates 192.0.2.1 as permitted sender)
>identity=helo; helo=example.org;
> Received-SPF: fail (domain of u...@example.com
>denies 192.0.2.1 as permitted sender)
>identity=mailfrom; envelope-from="u...@example.com";
> Subject: Not using a mail client for this example
> From: different-u...@example.org
> 
> Does it pass DMARC?

No.

Scott K



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

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

[Alessandro Vesely]

On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:

On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:

May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

[...]

   The reader should note that SPF alignment checks in DMARC rely solely
   on the RFC5321.MailFrom domain. This differs from section 2.3 of
   [@!RFC7208], which recommends that SPF checks be done on not only the
   "MAIL FROM" but also on a separate check of the "HELO" identity. >


I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null,
postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
change that.

As a result, there are cases where Mail From results actually are derived
from HELO and it's unavoidable.


I doubt that SPF filters report envelope-from=postmaster@HELO; more likely
they write helo=HELO.  In that case, the paragraph quoted above is
deceptive.

I believe the proposed text is clear enough about not using separate HELO
identity results and that's appropriate.


My filter collects SPF results recorded from an upstream SPF filter.  It
writes Received-SPF: lines for each identity.  For NDNs, it writes a
Received-SPF: for the HELO identity only.  Am I allowed to use that result
for DMARC?


No.  You should only use Mail From results.



So NDNs having only an aligned HELO will never pass DMARC?

And what is a helo element in aggregate reports provided for?

The spec says:

 [SPF] can authenticate either the domain that appears in the
   RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
   HELO domain, or both.

And then:

   In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.

So, consider the following message without DKIM signatures:

HELO example.org
MAIL FROM:

Received-SPF: pass (domain example.org
  designates 192.0.2.1 as permitted sender)
  identity=helo; helo=example.org;
Received-SPF: fail (domain of u...@example.com
  denies 192.0.2.1 as permitted sender)
  identity=mailfrom; envelope-from="u...@example.com";
Subject: Not using a mail client for this example
From: different-u...@example.org

Does it pass DMARC?

Best
Ale
--





















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

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

[Scott Kitterman]

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:
> > On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:
> >> May I propose that the section labeled "SPF-Authenticated Identifiers" be
> >> rewritten as follows:
> >> 
> >> [...]
> >> 
> >>The reader should note that SPF alignment checks in DMARC rely solely
> >>on the RFC5321.MailFrom domain. This differs from section 2.3 of
> >>[@!RFC7208], which recommends that SPF checks be done on not only the
> >>"MAIL FROM" but also on a separate check of the "HELO" identity. >
> > 
> > I think this is fine, but there is a subtlety to be aware of.
> > 
> > If you look at RFC 7208 Section 2.4, when Mail From is null,
> > postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
> > change that.
> > 
> > As a result, there are cases where Mail From results actually are derived
> > from HELO and it's unavoidable.
> 
> I doubt that SPF filters report envelope-from=postmaster@HELO; more likely
> they write helo=HELO.  In that case, the paragraph quoted above is
> deceptive.
> > I believe the proposed text is clear enough about not using separate HELO
> > identity results and that's appropriate.
> 
> My filter collects SPF results recorded from an upstream SPF filter.  It
> writes Received-SPF: lines for each identity.  For NDNs, it writes a
> Received-SPF: for the HELO identity only.  Am I allowed to use that result
> for DMARC?

No.  You should only use Mail From results.

Scott K



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

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

[Alessandro Vesely]

On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:


May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

[...]

   The reader should note that SPF alignment checks in DMARC rely solely
   on the RFC5321.MailFrom domain. This differs from section 2.3 of 
   [@!RFC7208], which recommends that SPF checks be done on not only the

   "MAIL FROM" but also on a separate check of the "HELO" identity. >

I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null, postmaster@HELO
is the mail from for SPF purposes.  DMARC really can't change that.

As a result, there are cases where Mail From results actually are derived from
HELO and it's unavoidable.



I doubt that SPF filters report envelope-from=postmaster@HELO; more likely they 
write helo=HELO.  In that case, the paragraph quoted above is deceptive.




I believe the proposed text is clear enough about not using separate HELO
identity results and that's appropriate.


My filter collects SPF results recorded from an upstream SPF filter.  It writes 
Received-SPF: lines for each identity.  For NDNs, it writes a Received-SPF: for 
the HELO identity only.  Am I allowed to use that result for DMARC?



Best
Ale
--

















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

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

[Scott Kitterman]

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:
> On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely  wrote
> 
> > I agree that the spec needs some text somewhere to counter the passage in
> > Section 2.3 of RFC 7208.  This, methinks, is the intended semantics of the
> > second paragraph of section 3.1.2 of dmarcbis:
> > 
> > OLD:
> > Note that the RFC5321.HELO identity is not typically used in the
> > context of DMARC (except when required to "fake" an otherwise null
> > reverse-path), even though a "pure SPF" implementation according to
> > [RFC7208] would check that identifier.
> > 
> > I'd rather replace that paragraph and leave item 4 of Section 6.6.2 as
> > is.  For
> > a possibly less confusing wording:
> > 
> > NEW:
> > Even tough a "pure SPF" implementation, according to [RFC7208], would
> > avoid to check the RFC5321.MailFrom identity if the RFC5321.HELO was
> > conclusively determined to pass, DMARC authentication requires the
> > authenticated identity to be aligned.
> 
> May I propose that the section labeled "SPF-Authenticated Identifiers" be
> rewritten as follows:
> 
> CURRENT:
> 
>DMARC permits Identifier Alignment, based on the result of an SPF
>authentication, to be strict or relaxed.
> 
>In relaxed mode, the [SPF
> ]-authenticated domain
> and RFC5322 .From
>domain must have the same Organizational Domain.  In strict mode,
>only an exact DNS domain match is considered to produce Identifier
>Alignment.
> 
>Note that the RFC5321 .HELO
> identity is not typically used in the
>context of DMARC (except when required to "fake" an otherwise null
>reverse-path), even though a "pure SPF" implementation according to
>[SPF ] would check
> that identifier.
> 
>For example, if a message passes an SPF check with an
>RFC5321 .MailFrom domain of
> "cbg.bounces.example.com", and the address
>portion of the RFC5322 .From
> field contains "payme...@example.com",
>the Authenticated RFC5321
> .MailFrom domain identifier and
> the
>RFC5322 .From domain are
> considered to be "in alignment" in relaxed
> 
>mode, but not in strict mode.
> 
> 
> 
> NEW:
> 
> DMARC permits Identifier Alignment, based on the result of an SPF
> 
> authentication, to be strict or relaxed.
> 
> 
> In relaxed mode, the [@!RFC3986]-authenticated domain and RFC5322.From
> 
> domain must have the same Organizational Domain.  In strict mode,
> 
> only an exact DNS domain match is considered to produce Identifier
> 
> Alignment.
> 
> 
> For example, if a message passes an SPF check with an
> 
> RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
> 
> portion of the RFC5322.From field contains "payme...@example.com",
> 
> the Authenticated RFC5321.MailFrom domain identifier and the
> 
> RFC5322.From domain are considered to be "in alignment" in relaxed
> 
> mode, but not in strict mode. In order for the two identifiers to
> 
> be considered "in alignment" in strict mode, the domain parts would
> 
> have to be identical.
> 
> 
> The reader should note that SPF alignment checks in DMARC rely solely
> 
> on the RFC5321.MailFrom domain. This differs from section 2.3 of
> [@!RFC7208],
> 
> which recommends that SPF checks be done on not only the "MAIL FROM"
> 
> but also on a separate check of the "HELO" identity.

I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null, postmaster@HELO 
is the mail from for SPF purposes.  DMARC really can't change that.

As a result, there are cases where Mail From results actually are derived from 
HELO and it's unavoidable.  I believe the proposed text is clear enough about 
not using separate HELO identity results and that's appropriate.

Scott K



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

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

[Todd Herr]

On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely  wrote

>
> I agree that the spec needs some text somewhere to counter the passage in
> Section 2.3 of RFC 7208.  This, methinks, is the intended semantics of the
> second paragraph of section 3.1.2 of dmarcbis:
>
> OLD:
> Note that the RFC5321.HELO identity is not typically used in the
> context of DMARC (except when required to "fake" an otherwise null
> reverse-path), even though a "pure SPF" implementation according to
> [RFC7208] would check that identifier.
>
> I'd rather replace that paragraph and leave item 4 of Section 6.6.2 as
> is.  For
> a possibly less confusing wording:
>
> NEW:
>
> Even tough a "pure SPF" implementation, according to [RFC7208], would
> avoid to check the RFC5321.MailFrom identity if the RFC5321.HELO was
> conclusively determined to pass, DMARC authentication requires the
> authenticated identity to be aligned.
>
>
May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

CURRENT:

   DMARC permits Identifier Alignment, based on the result of an SPF
   authentication, to be strict or relaxed.

   In relaxed mode, the [SPF
]-authenticated domain
and RFC5322 .From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.

   Note that the RFC5321 .HELO
identity is not typically used in the
   context of DMARC (except when required to "fake" an otherwise null
   reverse-path), even though a "pure SPF" implementation according to
   [SPF ] would check
that identifier.

   For example, if a message passes an SPF check with an
   RFC5321 .MailFrom domain of
"cbg.bounces.example.com", and the address
   portion of the RFC5322 .From
field contains "payme...@example.com",
   the Authenticated RFC5321
.MailFrom domain identifier and
the
   RFC5322 .From domain are
considered to be "in alignment" in relaxed

   mode, but not in strict mode.



NEW:

DMARC permits Identifier Alignment, based on the result of an SPF

authentication, to be strict or relaxed.


In relaxed mode, the [@!RFC3986]-authenticated domain and RFC5322.From

domain must have the same Organizational Domain.  In strict mode,

only an exact DNS domain match is considered to produce Identifier

Alignment.


For example, if a message passes an SPF check with an

RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address

portion of the RFC5322.From field contains "payme...@example.com",

the Authenticated RFC5321.MailFrom domain identifier and the

RFC5322.From domain are considered to be "in alignment" in relaxed

mode, but not in strict mode. In order for the two identifiers to

be considered "in alignment" in strict mode, the domain parts would

have to be identical.


The reader should note that SPF alignment checks in DMARC rely solely

on the RFC5321.MailFrom domain. This differs from section 2.3 of
[@!RFC7208],

which recommends that SPF checks be done on not only the "MAIL FROM"

but also on a separate check of the "HELO" identity.



-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Tue 19/Jan/2021 22:26:09 +0100 Todd Herr wrote:

Picking up the thread on another ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

John Levine asserted that there wasn't a lot of strong opinion on the
matter, and therefore we'd be leaving the spec as is, with the MAIL FROM
SPF check the only one that matters for DMARC.

Ale replied, but I don't interpret his reply as challenging John's
assertion.



The thread went off-topic w.r.t. the purpose of ticket #1.



Can this ticket be closed?



I agree that the spec needs some text somewhere to counter the passage in 
Section 2.3 of RFC 7208.  This, methinks, is the intended semantics of the 
second paragraph of section 3.1.2 of dmarcbis:


OLD:
   Note that the RFC5321.HELO identity is not typically used in the
   context of DMARC (except when required to "fake" an otherwise null
   reverse-path), even though a "pure SPF" implementation according to
   [RFC7208] would check that identifier.

I'd rather replace that paragraph and leave item 4 of Section 6.6.2 as is.  For 
a possibly less confusing wording:


NEW:

   Even tough a "pure SPF" implementation, according to [RFC7208], would
   avoid to check the RFC5321.MailFrom identity if the RFC5321.HELO was
   conclusively determined to pass, DMARC authentication requires the
   authenticated identity to be aligned.


Best
Ale
--



















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

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

[Todd Herr]

Picking up the thread on another ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

John Levine asserted that there wasn't a lot of strong opinion on the
matter, and therefore we'd be leaving the spec as is, with the MAIL FROM
SPF check the only one that matters for DMARC.

Ale replied, but I don't interpret his reply as challenging John's
assertion.

Can this ticket be closed?

On Thu, Dec 31, 2020 at 9:47 AM Alessandro Vesely  wrote:

> On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote:
> >> We would like to close this ticket by Dec 15, two weeks from now, so
> short
> >> trenchant comments are welcome.
> >>
> >> Ticket #1 is about SPF alignment.  We need to replace references to
> 4408 with
> >> 7408, ando clarify what if anything we do with SPF HELO checks if
> >> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
> counts,
> >> if you want to align your bounces, sign them.  The other is to
> explicitly say
> >> that HELO alignment is OK on bounces.
> >
> > I didn't hear a lot of strong opinions, but I think they leaned in the
> > direction of only checking the MAIL FROM, since the name of the MTA
> often is
> > unrelated to the From: domain.
> >
> > This means that if you want your bounces to be DMARC aligned, they'd
> need DKIM
> > signatures.
>
>
> Bounces with HELO mta.example.com should have From:
> postmas...@mta.example.com,
> where example.com may be a virtual domain or the "real" domain name,
> depending
> on the configuration.
>
> --

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote:
We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


Ticket #1 is about SPF alignment.  We need to replace references to 4408 with 
7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF counts, 
if you want to align your bounces, sign them.  The other is to explicitly say 
that HELO alignment is OK on bounces.


I didn't hear a lot of strong opinions, but I think they leaned in the 
direction of only checking the MAIL FROM, since the name of the MTA often is 
unrelated to the From: domain.


This means that if you want your bounces to be DMARC aligned, they'd need DKIM 
signatures.



Bounces with HELO mta.example.com should have From: postmas...@mta.example.com, 
where example.com may be a virtual domain or the "real" domain name, depending 
on the configuration.



Best
Ale
--









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

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

[John R Levine]

We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


Ticket #1 is about SPF alignment.  We need to replace references to 4408 with 
7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF counts, 
if you want to align your bounces, sign them.  The other is to explicitly say 
that HELO alignment is OK on bounces.


I didn't hear a lot of strong opinions, but I think they leaned in the 
direction of only checking the MAIL FROM, since the name of the MTA often 
is unrelated to the From: domain.


This means that if you want your bounces to be DMARC aligned, they'd need 
DKIM signatures.


R's,
John






From: Anne Bennett 
Date: Fri, 16 Jan 2015 19:10:56 -0500
Subject: [dmarc-ietf] SPF RFC 4408 vs 7208

On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
However, -12 still has, in section "3.1. Identifier Alignment":
For example, [DKIM] authenticates the domain that affixed a
signature to the message, while [SPF] authenticates either
the domain that appears in the RFC5321.MailFrom? portion of
[SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
is null (in the case of Delivery Status Notifications).
Actually, RFC 7208 states that:
Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
if both are checked.

... and implies that if the first check passes, the second
is unnecessary:

If a conclusive determination about the message can be made
based on a check of "HELO", then the use of DNS resources to
process the typically more complex "MAIL FROM" can be avoided.
So the RFC5321.EHLO/HELO domain is checked not only if the
RFC5321.MailFrom? is null - in fact in cases where sites have
followed the RFC 7208 recommendation, it will be checked first,
at least by a "pure SPF" implementation.
This means, first of all, that the -12 text above needs fixing.
But also, I'm struggling with what it means for alignment.
I can think of some real-life cases where only one of
HELO or MAIL FROM aligns with RFC5322.From, even though
both would "pass" in a pure SPF check. IMHO, Section
"3.1.2. SPF-authenticated Identifiers" needs to be clarified
to better take HELO into account.
I'd like to see an approach similar to that for DKIM, where it
is explicitly stated that:
a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is
aligned and verifies.
Similarly, I think that for SPF, it should be considered a pass
if either the MAIL FROM or the HELO is aligned and results in a
pass at the SPF level.
But whether it is decided to take into account both HELO and MAIL
FROM, or whether it is decided to ignore HELO (modulo its use to
construct an artificial MAIL FROM if the latter is null), the text
should IMHO make this clear one way or another, both in "3.1.2.
SPF-authenticated Identifiers":
In relaxed mode, the [SPF]-authenticated domain and
RFC5322.From domain must have the same Organizational Domain.
In strict mode, only an exact DNS domain match is considered
to produce identifier alignment.

... and in "4.1. Authentication Mechanisms":

o [SPF], which authenticates the domain found in an
[SMTP] MAIL command when it is the authorized domain.
In both cases, the text should specifically mention HELO,
and whether to include or exclude a HELO SPF result, in view
of HELO's prominence in RFC 7208.
If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Mon 07/Dec/2020 23:13:44 +0100 John Levine wrote:

In article  
you write:

I have a slight preference for the first option.  HELO is too arbitrary in
the protocol for me to put much value in using it in any of these systems.


There's a bit of an implementation detail though. If one is relying on an
encapsulated ck_host() function then you may not know whether it checked
the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
seems like it verges on a layering violation.


You should be able to look at the bounce address and if it's null,
skip the SPF check.  No need to peek inside SPF for that.



That would discard most bounces, since many MTAs send them directly, without 
going through a signing filter.



Best
Ale
--





















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

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

[Douglas Foster]

Is there an identifiable attack vector which can be based on using the
(forward confirmed) HELO name for SPF pass?

If not, why change?



On Mon, Dec 7, 2020, 6:09 AM Dotzero  wrote:

>
>
> On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy 
> wrote:
>
>> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>>
>>> We would like to close this ticket by Dec 15, two weeks from now, so
>>> short
>>> trenchant comments are welcome.
>>>
>>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>>> counts, if you want to align your bounces, sign them.  The other is to
>>> explicitly say that HELO alignment is OK on bounces.
>>>
>>
>> I have a slight preference for the first option.  HELO is too arbitrary
>> in the protocol for me to put much value in using it in any of these
>> systems.
>>
>> -MSK
>>
>
> +1
>
> Michael Hammer
> ___
> 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

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

[John Levine]

In article  
you write:
>> I have a slight preference for the first option.  HELO is too arbitrary in
>> the protocol for me to put much value in using it in any of these systems.
>
>There's a bit of an implementation detail though. If one is relying on an
>encapsulated ck_host() function then you may not know whether it checked
>the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
>seems like it verges on a layering violation.

You should be able to look at the bounce address and if it's null,
skip the SPF check.  No need to peek inside SPF for that.

R's,
John

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

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

[Kurt Andersen (b)]

On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>> counts, if you want to align your bounces, sign them.  The other is to
>> explicitly say that HELO alignment is OK on bounces.
>>
>
> I have a slight preference for the first option.  HELO is too arbitrary in
> the protocol for me to put much value in using it in any of these systems.
>

There's a bit of an implementation detail though. If one is relying on an
encapsulated ck_host() function then you may not know whether it checked
the HELO or the MAIL FROM. Imposing a requirement like this from DMARC
seems like it verges on a layering violation.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Mon, Dec 7, 2020 at 2:13 AM Murray S. Kucherawy 
wrote:

> On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment.  We need to replace references to 4408
>> with 7408, ando clarify what if anything we do with SPF HELO checks if
>> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
>> counts, if you want to align your bounces, sign them.  The other is to
>> explicitly say that HELO alignment is OK on bounces.
>>
>
> I have a slight preference for the first option.  HELO is too arbitrary in
> the protocol for me to put much value in using it in any of these systems.
>
> -MSK
>

+1

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:

> We would like to close this ticket by Dec 15, two weeks from now, so short
> trenchant comments are welcome.
>
> Ticket #1 is about SPF alignment.  We need to replace references to 4408
> with 7408, ando clarify what if anything we do with SPF HELO checks if
> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
> counts, if you want to align your bounces, sign them.  The other is to
> explicitly say that HELO alignment is OK on bounces.
>

I have a slight preference for the first option.  HELO is too arbitrary in
the protocol for me to put much value in using it in any of these systems.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

Point of clarification:

On Tue, Dec 1, 2020 at 2:17 PM John R Levine  wrote:

> We would like to close this ticket by Dec 15, two weeks from now, so short
> trenchant comments are welcome.
>
> Ticket #1 is about SPF alignment.  We need to replace references to 4408
> with 7408, ando clarify what if anything we do with SPF HELO checks if
> [...]
>

The new SPF is RFC 7208, not 7408.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Wed 02/Dec/2020 00:20:12 +0100 Douglas Foster wrote:


2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC 5321 
Mail From is a different domain.
All this tells us is that the Mail From domain is a client on that system.  
  Being a client of a hosting service does not give the right to speak for the 
hosting service.



What if I wanted to collect bounces at a different domain?


OTOH, an MSA can relay using a different HELO (or even a different IP), 
according to the right (categorization) it wants to supply.



Best
Ale
--















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

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

[Alessandro Vesely]

On Tue 01/Dec/2020 23:17:15 +0100 John R Levine wrote:
We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


[...]

I think that for SPF, it should be considered a pass if either the MAIL FROM
or the HELO is aligned and results in a pass at the SPF level.


+1, especially for bounces.



If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.



If alignment is not known at step 4, both domain names (if different) must be 
passed to step 5.



Best
Ale
--



















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

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

[Douglas Foster]

1) ACCEPTABLE:   Server Domain matches RFC 5322 From domain, and RFC 5321
Mail From is missing.
HELO is an appropriate proxy for the missing Mail From, especially since a
missing Mail From implies a system message, such as a server might need to
generate.

2) NOT ACCEPTABLE:   Server Domain matches RFC 5322 From domain, but RFC
5321 Mail From is a different domain.
All this tells us is that the Mail From domain is a client on that system.
 Being a client of a hosting service does not give the right to speak for
the hosting service.

Doug Foster


On Tue, Dec 1, 2020 at 5:17 PM John R Levine  wrote:

> We would like to close this ticket by Dec 15, two weeks from now, so short
> trenchant comments are welcome.
>
> Ticket #1 is about SPF alignment.  We need to replace references to 4408
> with 7408, ando clarify what if anything we do with SPF HELO checks if
> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
> counts, if you want to align your bounces, sign them.  The other is to
> explicitly say that HELO alignment is OK on bounces.
>
> R's,
> John
>
> 
>
> From: Anne Bennett 
> Date: Fri, 16 Jan 2015 19:10:56 -0500
> Subject: [dmarc-ietf] SPF RFC 4408 vs 7208
>
> On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
> the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
> However, -12 still has, in section "3.1. Identifier Alignment":
> For example, [DKIM] authenticates the domain that affixed a
> signature to the message, while [SPF] authenticates either
> the domain that appears in the RFC5321.MailFrom? portion of
> [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
> is null (in the case of Delivery Status Notifications).
> Actually, RFC 7208 states that:
> Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
> if both are checked.
>
> ... and implies that if the first check passes, the second
> is unnecessary:
>
> If a conclusive determination about the message can be made
> based on a check of "HELO", then the use of DNS resources to
> process the typically more complex "MAIL FROM" can be avoided.
> So the RFC5321.EHLO/HELO domain is checked not only if the
> RFC5321.MailFrom? is null - in fact in cases where sites have
> followed the RFC 7208 recommendation, it will be checked first,
> at least by a "pure SPF" implementation.
> This means, first of all, that the -12 text above needs fixing.
> But also, I'm struggling with what it means for alignment.
> I can think of some real-life cases where only one of
> HELO or MAIL FROM aligns with RFC5322.From, even though
> both would "pass" in a pure SPF check. IMHO, Section
> "3.1.2. SPF-authenticated Identifiers" needs to be clarified
> to better take HELO into account.
> I'd like to see an approach similar to that for DKIM, where it
> is explicitly stated that:
> a single email can contain multiple DKIM signatures, and it
> is considered to be a DMARC "pass" if any DKIM signature is
> aligned and verifies.
> Similarly, I think that for SPF, it should be considered a pass
> if either the MAIL FROM or the HELO is aligned and results in a
> pass at the SPF level.
> But whether it is decided to take into account both HELO and MAIL
> FROM, or whether it is decided to ignore HELO (modulo its use to
> construct an artificial MAIL FROM if the latter is null), the text
> should IMHO make this clear one way or another, both in "3.1.2.
> SPF-authenticated Identifiers":
> In relaxed mode, the [SPF]-authenticated domain and
> RFC5322.From domain must have the same Organizational Domain.
> In strict mode, only an exact DNS domain match is considered
> to produce identifier alignment.
>
> ... and in "4.1. Authentication Mechanisms":
>
> o [SPF], which authenticates the domain found in an
> [SMTP] MAIL command when it is the authorized domain.
> In both cases, the text should specifically mention HELO,
> and whether to include or exclude a HELO SPF result, in view
> of HELO's prominence in RFC 7208.
> If it is decided to allow both HELO and MAIL FROM results to be
> passed back to DMARC, then in section "6.6.2. Determine Handling
> Policy", item 4 should be updated to reflect that as
> well.___
> 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

[dmarc-ietf] Ticket #1 - SPF alignment

[John R Levine]

We would like to close this ticket by Dec 15, two weeks from now, so short 
trenchant comments are welcome.


Ticket #1 is about SPF alignment.  We need to replace references to 4408 
with 7408, ando clarify what if anything we do with SPF HELO checks if
the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF 
counts, if you want to align your bounces, sign them.  The other is to 
explicitly say that HELO alignment is OK on bounces.


R's,
John



From: Anne Bennett 
Date: Fri, 16 Jan 2015 19:10:56 -0500
Subject: [dmarc-ietf] SPF RFC 4408 vs 7208

On Jan 6, Murray S. Kucherawy confirmed fixing the reference for
the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11").
However, -12 still has, in section "3.1. Identifier Alignment":
For example, [DKIM] authenticates the domain that affixed a
signature to the message, while [SPF] authenticates either
the domain that appears in the RFC5321.MailFrom? portion of
[SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom?
is null (in the case of Delivery Status Notifications).
Actually, RFC 7208 states that:
Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence
if both are checked.

... and implies that if the first check passes, the second
is unnecessary:

If a conclusive determination about the message can be made
based on a check of "HELO", then the use of DNS resources to
process the typically more complex "MAIL FROM" can be avoided.
So the RFC5321.EHLO/HELO domain is checked not only if the
RFC5321.MailFrom? is null - in fact in cases where sites have
followed the RFC 7208 recommendation, it will be checked first,
at least by a "pure SPF" implementation.
This means, first of all, that the -12 text above needs fixing.
But also, I'm struggling with what it means for alignment.
I can think of some real-life cases where only one of
HELO or MAIL FROM aligns with RFC5322.From, even though
both would "pass" in a pure SPF check. IMHO, Section
"3.1.2. SPF-authenticated Identifiers" needs to be clarified
to better take HELO into account.
I'd like to see an approach similar to that for DKIM, where it
is explicitly stated that:
a single email can contain multiple DKIM signatures, and it
is considered to be a DMARC "pass" if any DKIM signature is
aligned and verifies.
Similarly, I think that for SPF, it should be considered a pass
if either the MAIL FROM or the HELO is aligned and results in a
pass at the SPF level.
But whether it is decided to take into account both HELO and MAIL
FROM, or whether it is decided to ignore HELO (modulo its use to
construct an artificial MAIL FROM if the latter is null), the text
should IMHO make this clear one way or another, both in "3.1.2.
SPF-authenticated Identifiers":
In relaxed mode, the [SPF]-authenticated domain and
RFC5322.From domain must have the same Organizational Domain.
In strict mode, only an exact DNS domain match is considered
to produce identifier alignment.

... and in "4.1. Authentication Mechanisms":

o [SPF], which authenticates the domain found in an
[SMTP] MAIL command when it is the authorized domain.
In both cases, the text should specifically mention HELO,
and whether to include or exclude a HELO SPF result, in view
of HELO's prominence in RFC 7208.
If it is decided to allow both HELO and MAIL FROM results to be
passed back to DMARC, then in section "6.6.2. Determine Handling
Policy", item 4 should be updated to reflect that as well.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc