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

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Feb 2021 13:17:20 +0100

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 <[email-masked]> 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
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 1 Feb 2021 09:26:37 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 1 Feb 2021 17:59:34 +0100

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Feb 2021 14:48:32 -0500

On Monday, February 1, 2021 7:17:20 AM EST Alessandro Vesely wrote:
> > (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.
> 

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.

> 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

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

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2021 18:11:54 -0500

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

>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

---

From: Douglas Foster <[email-masked]>
Date: Mon, 1 Feb 2021 19:11:22 -0500

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 12:59:31 +0100

On Tue 02/Feb/2021 00:11:54 +0100 John Levine wrote:
> 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?

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 13:57:52 +0100

On Tue 02/Feb/2021 01:11:22 +0100 Douglas Foster wrote:
> 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.

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Feb 2021 10:42:04 -0500

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

> validation is performed:   Is the Source IP is authorized to send on
> behalf of the SMTP domain?   When the SMTP address is null, then

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:<return-address>
S: 250 <return-path>... Sender validation pending. Continue.

Then the RCPT TO issued:

C: RCPT TO:<forwarding-address>

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 Authentication Protocol (LMAP) Discussion and 
Applicability Statement, 
https://secure.winserver.com/public/ietf/drafts/draft-irtf-asrg-lmap-discussion-00.txt

[2] Designated Mailers Protocol (DMP), 
https://tools.ietf.org/html/draft-fecyk-dmp-01

[3] The RMX DNS RR and method for lightweight SMTP sender 
authorization, https://tools.ietf.org/html/draft-danisch-dns-rr-smtp-03

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2021 12:49:08 -0500

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

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 2 Feb 2021 19:17:35 +0100

> whatever the SPF library returns, so I don't see the point of this argument.

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: [email-masked]".

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

My point is that the DMARC spec says something inconsistent, namely that SPF 
helo results are reliable but typically they are not.

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

We can stop now and get back on it later.  That idiosyncrasy is going to stay 
there until we fix it.  I'd suggest to fix it by accepting an aligned helo pass 
unconditionally.  However, it can also be fixed by an explanation, as long as 
it is something more persuasive than "one can type anything at helo".

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 2 Feb 2021 14:13:42 -0500

> 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: [email-masked]".

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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Jim Fenton" <[email-masked]>
Date: Tue, 02 Feb 2021 11:41:59 -0800

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: 
>> [email-masked]".
>
> 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?

> 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

---

From: "John R Levine" <[email-masked]>
Date: 2 Feb 2021 14:54:33 -0500

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

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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 2 Feb 2021 19:30:23 -0500

Yes, it is true that the spec says

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
<https://tools.ietf.org/html/rfc7208#section-4>) to the "HELO"
identity as the
   <sender>.

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

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

---

From: Douglas Foster <[email-masked]>
Date: Wed, 3 Feb 2021 06:51:22 -0500

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 <[email-masked]> wrote:

> result to
> DMARC

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 3 Feb 2021 18:43:54 +0100

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

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

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2021 13:12:26 -0500

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

>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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 4 Feb 2021 13:50:22 +0100

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

---

From: "John R Levine" <[email-masked]>
Date: 4 Feb 2021 11:43:06 -0500

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?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 05 Feb 2021 17:50:34 -0500

On Thursday, February 4, 2021 7:50:22 AM EST Alessandro Vesely wrote:
>      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

---

From: Dotzero <[email-masked]>
Date: Sat, 6 Feb 2021 14:53:27 -0500

> 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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 6 Feb 2021 15:57:30 -0800

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

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

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Feb 2021 17:15:58 -0800

> +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
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Douglas Foster <[email-masked]>
Date: Sun, 7 Feb 2021 07:34:33 -0500

"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

---

From: Todd Herr <[email-masked]>
Date: Mon, 8 Feb 2021 09:50:09 -0500

On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
[email-masked]> 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?"
>

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
<policy_evaluated> section of the aggregate report will show "fail" for
SPF, even if the <results> bit of the <auth_results> section shows "pass"
in the <spf> sub-section.

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

> 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:* [email-masked]
*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.

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2021 20:28:04 -0500

In article <CAHej_8k6DA8140QB2buaRCaJfc0U9fVSC=[email-masked]> you write:
>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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 9 Feb 2021 22:13:37 -0500

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 <todd.herr=
[email-masked]> wrote:

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 09 Feb 2021 23:19:38 -0500

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

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Feb 2021 10:49:46 +0100

Just to clarify:

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

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

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.

>> senders. This may also be true, but I don't think this is something that

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Feb 2021 09:43:04 -0500

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 10 Feb 2021 08:49:17 -0800

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

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

--Kurt

---

From: Douglas Foster <[email-masked]>
Date: Wed, 10 Feb 2021 18:24:11 -0500

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 = [email-masked]
FROM= [email-masked]

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 = [email-masked]
FROM = [email-masked]

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Feb 2021 15:29:02 -0800

> 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
[email-masked]
408.329.0791

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Feb 2021 10:08:02 +0100

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

---

From: Douglas Foster <[email-masked]>
Date: Thu, 11 Feb 2021 06:35:49 -0500

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Feb 2021 08:50:42 -0500

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

---

From: Douglas Foster <[email-masked]>
Date: Thu, 11 Feb 2021 23:24:16 -0500

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Feb 2021 13:01:43 -0500

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:
> > > Applying SPF to DMARC could become out of scope, if we choose to remove
> > 
> > SPF
> > 
> > > to leave it untouched.  Implication is different from specification, so
> > 
> > our
> > 
> > > 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:
> > > evaluation of the MAILFROM Address.   Some recipients may evaluate SPF
> > 
> > HELO
> >

---

From: Seth Blank <[email-masked]>
Date: Fri, 12 Feb 2021 10:07:44 -0800

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 <[email-masked]>
wrote:

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

-- 

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

`

---

From: "John Levine" <[email-masked]>
Date: 12 Feb 2021 15:40:04 -0500

In article <CAOZAAfM1yq9=[email-masked]> you write:
>-=-=-=-=-=-

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

R's,
John