Subject: [spfbis] New Issue: Requirement to check mail from

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 16:44:47 -0500

Sorry for being late.  I forgot about this one.

Paragraph 2.2, The MAIL FROM Identity, includes this statement:

   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
   the "MAIL FROM" identity by applying the check_host() function to the
   "MAIL FROM" identity as the <sender>.

There are applications that check HELO first and can reach a final conclusion 
about message disposition based on that check.  In such a case, the Mail From 
check is a waste of resources.

I'm recommend changing this to either:

SPF clients MUST check the "MAIL FROM" identity unless a HELO check has 
already produced a definititive policy result. ...

or

SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO check 
has already produced a definititive policy result). ...

Scott K

---

From: Paul Midgen <[email-masked]>
Date: Tue, 21 Feb 2012 03:08:47 +0000

Outside of the case where the envelope sender is empty (e.g. NDR), most of the HELO domains we observe are garbage.

Is there a reason why we do not recommend that HELO be checked only if Mail From does not produce a definitive policy result?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 1:45 PM
To: [email-masked]
Subject: [spfbis] New Issue: Requirement to check mail from

There are applications that check HELO first and can reach a final conclusion about message disposition based on that check.  In such a case, the Mail From check is a waste of resources.

SPF clients MUST check the "MAIL FROM" identity unless a HELO check has already produced a definititive policy result. ...

or

SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO check has already produced a definititive policy result). ...

Scott K
_______________________________________________
spfbis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spfbis

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 22:14:36 -0500

If you get a FQDN HELO checks can be useful.  

Generally the most complex HELO record you'll see is v=spf1 a -all.  In my 
experience HELO records are much less expensive in DNS looksups, so even if 
it's less likely to be definitive (if it's not a FQDN, you just don't look it 
up, no harm done) it's less expensive so doing the HELO check first can be a 
resource saver.

There's no interoperability benefit to doing one or the other check first.  
There's equally no point in trying to insist on software doing additional 
checks once it already has a definitive result.  I don't think we want to 
specify either.

Scott K

On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote:
> Is there a reason why we do not recommend that HELO be checked only if Mail
> From does not produce a definitive policy result?
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM
> To: [email-masked]
> There are applications that check HELO first and can reach a final
> conclusion about message disposition based on that check.  In such a case,
> the Mail From check is a waste of resources.
>

---

From: Paul Midgen <[email-masked]>
Date: Tue, 21 Feb 2012 03:30:28 +0000

>From the point of view of defining the mechanism itself, that is probably the right thing to do.

But: as a large-scale receiver, I am less concerned about conserving DNS queries than getting a definitive authentication result the first time at bat, especially when that authentication result will trigger a number of secondary actions associated with the authenticated identity - such as positive identification UX, authentication policy, domain reputation, and so on.

If the spec leaves it up to me, I will choose the entity statistically most likely to yield the result I need. I just hope this freedom of choice doesn't hurt interoperability by not being prescriptive.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 7:15 PM
To: [email-masked]
Subject: Re: [spfbis] New Issue: Requirement to check mail from

Generally the most complex HELO record you'll see is v=spf1 a -all.  In my experience HELO records are much less expensive in DNS looksups, so even if it's less likely to be definitive (if it's not a FQDN, you just don't look it up, no harm done) it's less expensive so doing the HELO check first can be a resource saver.

There's no interoperability benefit to doing one or the other check first.  
There's equally no point in trying to insist on software doing additional checks once it already has a definitive result.  I don't think we want to specify either.

Scott K

On Tuesday, February 21, 2012 03:08:47 AM Paul Midgen wrote:
> Outside of the case where the envelope sender is empty (e.g. NDR), 
> most of the HELO domains we observe are garbage.
> 
> Is there a reason why we do not recommend that HELO be checked only if 
> Mail From does not produce a definitive policy result?
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 1:45 PM
> To: [email-masked]
> conclusion about message disposition based on that check.  In such a 
> case, the Mail From check is a waste of resources.
> 
> SPF clients MUST check the "MAIL FROM" identity unless a HELO check 
> has already produced a definititive policy result. ...
> 
> or
> 
> SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a HELO 
> check has already produced a definititive policy result). ...
> 
> Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 22:33:32 -0500

As long as the working group stays out of trying to define local policy beyond 
what 4408 does, I think it's not a problem.

In any case, I think that the HELO check first approach I described only makes 
sense if a site is doing SPF based rejection at SMTP time, I don't think it's 
your use case.

Scott K

On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote:
> But: as a large-scale receiver, I am less concerned about conserving DNS
> queries than getting a definitive authentication result the first time at
> bat, especially when that authentication result will trigger a number of
> secondary actions associated with the authenticated identity - such as
> positive identification UX, authentication policy, domain reputation, and
> so on.
> 
> If the spec leaves it up to me, I will choose the entity statistically most
> likely to yield the result I need. I just hope this freedom of choice
> doesn't hurt interoperability by not being prescriptive.
> 
> Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM
> To: [email-masked]
> it's less likely to be definitive (if it's not a FQDN, you just don't look
> it up, no harm done) it's less expensive so doing the HELO check first can
> be a resource saver.
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 20 Feb 2012 23:29:15 -0500

> HELO domains we observe are garbage.

I don't think good guys will issue garbage, only bad guys, so what you 
observe if reflective of the amount of bad guys going your way.

The different between the client domain and mail from, is there is 
historical precedence for incorrect configurations with requiring a 
valid domain, MUAs that do no have a public side domain name (hence 
why some use the NETBIOS computer name) or more accurately provide a 
domain that does not map with the the connection IP. Hence there is no 
requirement with the public port SMTP to validate the client domain 
since there is history of good guys erroneous failure.  Only the 
private port SUBMISSION protocol enforces a proper client domain and 
allows for validation and canceling of a transaction on this basis.

But there are rules that one can apply. If the client explicit issues 
a IP literal, then this MUST be match the connecting IP, a valid 
technical reason for enforcement.  If the client issues a domain that 
is specifically own your network or perhaps LocalHost, this too offers 
strong triggers to do IP matching checks.  The issue is when the 
domain is anonymous and has some form of a valid Domain format (at 
least one dot).  What do you do then?

With the MAIL FROM, SMTP requires this to be 100% valid, but no 
enforcement to check if that is true.  But it MUST be valid, no room 
for errors, and this opens the door to do introduce validation methods 
like SPF or even a CBV.

> Is there a reason why we do not recommend that HELO be checked only if Mail From 
> does not produce a definitive policy result?

There was always a lot of talk that an client domain check is all one 
needed, like CSV/DNA idea was proposing.  It followed the Chain of 
Trust concept from hop to hop, machine to machine.

If one used the SUBMISSION (RFC4409( protocol, EHLO must be correct, 
so that was another point of validation.  But then again, I always 
felt that since 4409 requires ESMTP AUTH (authentication), then 
perhaps any EHLO or even MAIL FROM SPF checking was redundant.  In 
fact, with the growth of NATS and the SOHO's there was a growth of 
where the even usage of an EHLO IP literal no longer matched the 
Connection IP, i.e, an older version of Thunderbird used the private 
LAN machine [IP Address] but on the public side the server saw the NAT 
public address.  So our SUBMISSION server offers operators an option 
to delay any EHLO checking until the ESMTP AUTH is completed.

Anyway, with your question, I once felt this was probably the right 
way, but you have to always ask yourself what if one of them was a 
hard fail and the other PASS, which one has a stronger requirement to 
be correct?  If the MAIL FROM check is valid, shouldn't the EHLO check 
be correct as well and vice versa?

The LMAP analysis here tried to address some of these questions by 
looking all all possible combinations of input and logical results, 
including when it made sense or was impossible to occur in a valid system.

    http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm

If I recall, when this was discussed and it was at length, I think an 
answer was or rather one that was needed to be true, was that if you 
supported SPF (or a domain created SPF records to send mail), then SPF 
compliance reinforce SMTP compliancy by making sure the client domain 
was always using 100% valid EHLO/IP domains and not junk.  This was to 
help systems that was doing EHLO SPF check reduce DNS NXDOMAIN delays.

Not sure if this is answering the question, I am suggesting to look at 
the conditions and results and ask yourself which once make sense or 
doesn't.

     If the MAIL FROM SPF check is valid, why would an EHLO check not 
be done, and
     if so, what if its was invalid?  Is it safe to suggest that valid 
MAIL FROM
     checks trumps the possibility of a EHLO check failure.

I suggest that its an illogical condition under across the board 
compliant system.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Paul Midgen <[email-masked]>
Date: Tue, 21 Feb 2012 06:43:14 +0000

How do you mean "not my use case"?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 7:34 PM
To: [email-masked]
Subject: Re: [spfbis] New Issue: Requirement to check mail from

As long as the working group stays out of trying to define local policy beyond what 4408 does, I think it's not a problem.

In any case, I think that the HELO check first approach I described only makes sense if a site is doing SPF based rejection at SMTP time, I don't think it's your use case.

Scott K

On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote:
> But: as a large-scale receiver, I am less concerned about conserving 
> DNS queries than getting a definitive authentication result the first 
> time at bat, especially when that authentication result will trigger a 
> number of secondary actions associated with the authenticated identity 
> - such as positive identification UX, authentication policy, domain 
> reputation, and so on.
> 
> If the spec leaves it up to me, I will choose the entity statistically 
> most likely to yield the result I need. I just hope this freedom of 
> choice doesn't hurt interoperability by not being prescriptive.
> 
> Behalf Of Scott Kitterman Sent: Monday, February 20, 2012 7:15 PM
> To: [email-masked]
> Generally the most complex HELO record you'll see is v=spf1 a -all.  
> In my experience HELO records are much less expensive in DNS looksups, 
> so even if it's less likely to be definitive (if it's not a FQDN, you 
> just don't look it up, no harm done) it's less expensive so doing the 
> HELO check first can be a resource saver.
> 
> There's equally no point in trying to insist on software doing 
> additional checks once it already has a definitive result.  I don't 
> think we want to specify either.
> 
> Scott K
> 
> > Is there a reason why we do not recommend that HELO be checked only 
> > if Mail From does not produce a definitive policy result?
> > 
> > SPF clients SHOULD check the "MAIL FROM" identity (e.g. unless a 
> > HELO check has already produced a definititive policy result). ...
> > 
> > Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 06:26:42 -0500

I'm expecting you won't do smtp time rejection based on SPF results.

Scott K

Paul Midgen <[email-masked]> wrote:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 7:34 PM
To: [email-masked]
Subject: Re: [spfbis] New Issue: Requirement to check mail from

Scott K

> > HELO check has already produced a definititive policy result). ...

_____________________________________________

spfbis mailing list
[email-masked]

_____________________________________________

spfbis mailing list
[email-masked]

---

From: Paul Midgen <[email-masked]>
Date: Tue, 21 Feb 2012 17:04:30 +0000

If the policy is there, we’ll do it.

Unless you’re raising the point that Hotmail currently evaluates SenderID – that is currently still true, however in order to fully support DMARC we will be switching to SPF just as soon as I can make it happen.

I don’t think that changes anything though, we’ll still choose a consistent model for evaluation that may be backwards from what is currently written. The assumptions underlying the way it is currently written are important insofar as they represent something not immediately obvious – “cheaper” DNS queries is the only reason provided so far, and in my use case “DNS query cheapness” is not a concern.

So beyond that, if I always check Mail From first (when present) then stop if satisfied, will that create some obvious problem? If not, great! If there’s any doubt, it should be examined.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Tuesday, February 21, 2012 3:27 AM
To: [email-masked]
Subject: Re: [spfbis] New Issue: Requirement to check mail from

Scott K
Paul Midgen <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Scott Kitterman
Sent: Monday, February 20, 2012 7:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [spfbis] New Issue: Requirement to check mail from

Scott K

On Tuesday, February 21, 2012 03:30:28 AM Paul Midgen wrote:
> But: as a large-scale receiver, I am less concerned

 about

conserving
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On
> To: [email-masked]<mailto:[email-masked]>

> > Is there a reason why we do not

recommend that HELO be checked only
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On
> > To: [email-masked]<mailto:[email-masked]>

> > HELO check has already produced a definititive policy result). ...

________________________________

spfbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spfbis

________________________________

spfbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spfbis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 12:11:51 -0500

I think the checks can be done in either order.  I think it's OK to check Mail 
>From only and just do HELO for Null Mail From.  I'm not proposing we specify 
more policy, but that we back off a bit from over-specifying a check that in 
some cases will have no value.

For DMARC you'll need to go to the end of DATA before you can make a policy 
evaluation to reject, so the consideration I'm bringing up won't come into 
play.

Scott K

On Tuesday, February 21, 2012 05:04:30 PM Paul Midgen wrote:
> Unless you’re raising the point that Hotmail currently evaluates SenderID –
> that is currently still true, however in order to fully support DMARC we
> will be switching to SPF just as soon as I can make it happen.
 
> I don’t think that changes anything though, we’ll still choose a consistent
> model for evaluation that may be backwards from what is currently written.
> The assumptions underlying the way it is currently written are important
> insofar as they represent something not immediately obvious – “cheaper” DNS
> queries is the only reason provided so far, and in my use case “DNS query
> cheapness” is not a concern.
 
> So beyond that, if I always check Mail From first (when present) then stop
> if satisfied, will that create some obvious problem? If not, great! If
> there’s any doubt, it should be examined.
 
> Scott Kitterman
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> On Behalf Of Scott Kitterman
> As long as the working group stays out of trying to define local policy
> beyond what 4408 does, I think it's not a problem.
 
> In any case, I think that the HELO check first approach I described only
> makes sense if a site is doing SPF based rejection at SMTP time, I don't
> think it's your use case.
 
> > From: [email-masked]<mailto:[email-masked]>
> > [mailto:[email-masked]]<mailto:[mailto:[email-masked]
> > ]> On
> > > From: [email-masked]<mailto:[email-masked]>
> > > [mailto:[email-masked]]<mailto:[mailto:spfbis-bounces@ietf
> > > .org]> On
 Behalf Of Scott Kitterman Sent: Monday, February 20, 2012
> > > 1:45 PM To: [email-masked]<mailto:[email-masked]>
> > >    the "MAIL FROM" identity by applying the check_host() function
> > >    to
> > >    the

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 21 Feb 2012 15:46:12 -0800

> If the spec leaves it up to me, I will choose the entity statistically most likely to yield the result I need. I just hope this freedom of choice doesn't hurt interoperability by not being prescrip…

Heuristics are essential for many aspects of practical applications in this space.

But they have no place in a protocol standard.  Protocols are for 
interoperability and this requires that both sides of the exchange rely on 
deterministic behaviors.

For the current discussion, that means the protocol needs to strictly dictate 
one of:

    1.  Do this one thing

    2.  Do these two things

    3.  Do this one thing; if it doesn't work, do this other thing.

Specifically:

1.  One thing:

     a)  EHLO MUST be checked; MAILFROM MUST be ignored, or

     b)  MAILFROM MUST be checked; EHLO is ignored

2.  Two things:

     EHLO and MAILFROM MUST be checked every time.

3.  Sequence

     a) EHLO MUST be checked first; if it succeeds, you are done; if it fails, 
MAILFROM MUST then be checked;

     b) MAILFROM MUST be checked first; if it succeeds, you are done; if it 
fails, EHLO MUST then be checked

Once this validation step is completed, the receiver moves into "local policy" 
and all sorts of heuristics might come into play, but have nothing to do with 
the SPF spec.

I suggest that the working group should determine the relative values of EHLO 
and MAILFROM domain checking.  If either of them has proved to be sufficiently 
useless, we should drop it and specify Alternative 1, from above.

If they are both deemed essential to retain, we should decide an #2 or #3a or #3b.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 18:52:53 -0500

Dave CROCKER <[email-masked]> wrote:

>> If the spec leaves it up to me, I will choose the entity
>statistically most likely to yield the result I need. I just hope this
>freedom of choice doesn't hurt interoperability by not being
>prescriptive.
>
>

There's no interoperability benefit to adding this complexity to the specified requirements.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 21 Feb 2012 16:21:00 -0800

> There's no interoperability benefit to adding this complexity to the specified requirements.

Perhaps I wasn't clear that I was describing an exercise to /reduce/ the 
ambiguity and complexity currently in the spec?

The exercise is to have the spec contain only /one/ of the choices I outlined.

d/

-- 

   Dave Crocker

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Feb 2012 19:23:18 -0500

> I'm expecting you won't do smtp time rejection based on SPF results.

   (I hope I'm taking this out of context!)

   This scares me.

   MAIL-FROM checks that return "This domain never sends email" certainly
_should_ lead to SMTP-time rejects. Otherwise you're almost guaranteeing
that any later problems will cause black-holing the email (and complicating
the resolution of honest problems).

   (What happens in lesser cases of SPF result on MAIL-FROM seems to be
an open issue which I would like to see discussed on this list.)

--
John Leslie <[email-masked]>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 19:29:48 -0500

> an open issue which I would like to see discussed on this list.)

The 'you' in this case was limited to Hotmail.  I know they are planning on 
supporting DMARC (see dmarc.org) so they will need both SPF and DKIM results 
to reach a policy decision.  That means they need to get to the end of DATA.

I agree with you in the general case, although I think we need to be careful 
not to specify too much about required receiver policy in 4408bis.  Once 
4408bis is done though, I think it would be beneficial to recharter for a BCP 
or AS deliverable to get more into such recommendations.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 19:33:47 -0500

> The exercise is to have the spec contain only /one/ of the choices I

I understood that.

That's the opposite direction of what I was trying to go with this issue.

I am assuming that we are not moving away from RFC 4408's perspective that 
recevier policy should generally not be specified.  Given that we aren't doing 
to specify what to do with SPF results, there's no benefit to specifying 
processing order.

RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From.  If a 
HELO result is dispositive then the Mail From result is pointless.  Doing it 
doesn't help interoperability, it's just a waste of resources.

Whether doing 3a or 3b (or any of your other options) makes the most sense is 
a function of receiver policy.  There is also 4: Only check HELO if Mail From 
is Null.  I don't think trying to hard code any of these choices into 4408bis 
is helpful.

In SPF terms I think interoperabliity is defined in terms of "If I publish 
record A and send mail from server B, receivers will get SPF result C".  How 
receivers use that result is not something we should take on.

Scott K

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 21 Feb 2012 16:53:44 -0800

> to specify what to do with SPF results, there's no benefit to specifying

And nothing I am proposing disagrees with that... policy.

What I am proposed is to clarify and refine those SPF results.

Random choices about processing order can produce differing assessments of the 
objective, authentication information.  That's a definition of non-interoperability.

SPF publishers need to know how their records will be interpreted, at the 
validation level.  This is quite different from the next layer up, where the 
validated information is used -- and, yes, subject to receiver-side local poliy 
and no, not known to the publisher.

> doesn't help interoperability, it's just a waste of resources.

We were just given data to suggest that checking the EHLO is a waste of effort.

If it is a waste, we should drop it.

The current requirements of the specification means that the client SMTP cannot 
know what the basic validation will be.  We need to remove that non-determinacy.

> a function of receiver policy.

So you think it is ok that the basic validation results will vary depending upon 
the whims of the receiver?

 >   There is also 4: Only check HELO if Mail From

I mean this to be covered by 3b.

> receivers use that result is not something we should take on.

We agree on that goal.

Where we seem to be disagreeing is on the fact that letting the receiver decide 
what fields to validate makes result C unpredictable.

d/

-- 

   Dave Crocker

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Feb 2012 19:58:00 -0500

> to reach a policy decision.  That means they need to get to the end of DATA.

   The proper context _does_ help...

   But I fail to grok why hotmail shouldn't do an SMTP-time reject for
MAIL-FROM that returns SPF "This domain never sends email."

   Usless I misunderstand DMARC, it is based off of a DNS lookup based on
a From: header (in the DATA) -- which of course will often return nothing
at all.

> I agree with you in the general case, although I think we need to be
> careful not to specify too much about required receiver policy in 4408bis.

   I also dislike "required receiver policy"; but we should be able to
discuss "meaning" of SPF records without requiring a particular policy;
and we should be able to highlight SPF's strength at reducing the
blowback/blackhole problem.

> Once 4408bis is done though, I think it would be beneficial to recharter
> for a BCP or AS deliverable to get more into such recommendations.

   It feels premature to me to assume that we can produce a good BCP
after the fact without laying the basis in the Proposed Standard.

---

From: Paul Midgen <[email-masked]>
Date: Wed, 22 Feb 2012 01:24:43 +0000

SPF evaluation at Hotmail will not be limited to domains publishing a DMARC record. Domains publishing an SPF record but not supplying a DKIM signature or publishing a DMARC record will simply be evaluated per SPF(bis) as one would expect.

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
Sent: Tuesday, February 21, 2012 4:30 PM
To: [email-masked]
Subject: Re: [spfbis] New Issue: Requirement to check mail from

On Tuesday, February 21, 2012 07:23:18 PM John Leslie wrote:
>    MAIL-FROM checks that return "This domain never sends email" 
> certainly _should_ lead to SMTP-time rejects. Otherwise you're almost 
> guaranteeing that any later problems will cause black-holing the email 
> (and complicating the resolution of honest problems).
> 
>    (What happens in lesser cases of SPF result on MAIL-FROM seems to 
> be an open issue which I would like to see discussed on this list.)

The 'you' in this case was limited to Hotmail.  I know they are planning on supporting DMARC (see dmarc.org) so they will need both SPF and DKIM results to reach a policy decision.  That means they need to get to the end of DATA.

I agree with you in the general case, although I think we need to be careful not to specify too much about required receiver policy in 4408bis.  Once 4408bis is done though, I think it would be beneficial to recharter for a BCP or AS deliverable to get more into such recommendations.

Scott K

---

From: Paul Midgen <[email-masked]>
Date: Wed, 22 Feb 2012 01:36:01 +0000

> Unless I misunderstand DMARC, it is based off of a DNS lookup based on a From: header (in the DATA) -- 
> which of course will often return nothing at all.

Correction (and clearly outside the scope of this list):

Unless you are referring to *where* the _dmarc record is found, the underlying authentication mechanisms are operated as they normally would.

- SPF using the RFC5321.MailFrom
- DKIM using d=

Producing as many results as the receiver cares to check signatures and identities. DMARC selects only the SPF/DKIM results associated with an identity that aligns to the RFC5322.From domain as configured in the sender's DMARC record.

Those interested can refer to: http://dmarc.org/draft-dmarc-base-00-01.txt

-p

---

From: John Leslie <[email-masked]>
Date: Tue, 21 Feb 2012 20:56:46 -0500

>>> The exercise is to have the spec contain only /one/ of the choices I

   I think I smell straw... ;^)

>> I am assuming that we are not moving away from RFC 4408's perspective
>> that recevier policy should generally not be specified. Given that we
>> aren't doing to specify what to do with SPF results, there's no benefit
>> to specifying processing order.

   I agree.

> What I am proposed is to clarify and refine those SPF results.

   ... which would be commendable -- but it's hard to read Dave to
actually _say_ anything about that.

> Random choices about processing order can produce differing assessments
> of the objective, authentication information. That's a definition of 
> non-interoperability.

   No, actually, processing order has little or nothing to do with the
final result unless actions to be taken are required in real-time.

> validation level.  This is quite different from the next layer up, where 
> the validated information is used -- and, yes, subject to receiver-side 
> local poliy and no, not known to the publisher.

   I know Dave understands the distinction between EHLO and MAIL-FROM,
because he and I talked about it at length during MARID. But let me
state a difference for the rest of our readers:

- EHLO SPF results give an authentication of the EHLO string (or not)

- MAIL-FROM SPF results give an assurance that NDN responses are
  appropriate (or not, or maybe)

Neither of these gives any assurance that what will be visible to the
eventual reader is valid.

   EHLO results give a basis for a reputation query which Dave and I
used to agree was more useful than the IP address of the sending SMTP
client.

   MAIL-FROM results give an assurance that returning NDNs _after_
SMTP time is appropriate.

   The order in which these are done matters little. I would do the
EHLO query at the time I get the EHLO (and proceed with a reputation
check), and the MAIL-FROM check when I receive the MAIL-FROM (in hopes
that it would show no danger of blowback/blackhole). If I get a useful
reputation response (quite outside the SPF spec!) I might return a
"Get thee behind me, spammer!" result during the SMTP session. If I
get a "this domain never sends email", I'd return a policy error during
the SMTP session.

   Dave sounds as if he's claiming that which of these comes first should
be required in an SPF spec: I think that's silly.

   Other folks want to remove the EHLO check entirely because it's not
useful to them yet. While this isn't "silly", it is ill-advised IMHO.

>> RFC 4408 specifies that one SHOULD check HELO and MUST check Mail From.  
>> If a HELO result is dispositive then the Mail From result is pointless.

   Scott ignores timing issues. And, of course, the EHLO result is rather
seldom clearly "dispositive".

>> Doing it doesn't help interoperability, it's just a waste of resources.

   It's a waste of DNS resources in the few cases where the results of
an EHLO SPF check are available before a MAIL-FROM SPF check can be
started. That feels rare to me, and optimizing for rare cases in a
Proposed Standard isn't usually a good idea.

> If it is a waste, we should drop it.

   No -- we should leave that option for future users of SPF to judge.
We can reasonably argue whether an EHLO SPF check should be MUST, SHOULD,
or MAY; but there's no justification to go to MUST NOT.

> The current requirements of the specification means that the client SMTP 
> cannot know what the basic validation will be.  We need to remove that 
> non-determinacy.

   I don't understand that statement. (Neither EHLO nor MAIL-FROM give a
final validation in the "ordinary" case.)

>> Whether doing 3a or 3b (or any of your other options) makes the most
>> sense is a function of receiver policy.
> 
> So you think it is ok that the basic validation results will vary
> depending upon the whims of the receiver?

   I've given up tilting at such windmills.

>> There is also 4: Only check HELO if Mail From is Null. I don't think
>> trying to hard code any of these choices into 4408bis is helpful.

   I agree.

>> In SPF terms I think interoperabliity is defined in terms of "If I
>> publish record A and send mail from server B, receivers will get
>> SPF result C".  

   s/will/may/

   We can't force receivers to even initiate the checks, least of all
to receive and act on the results.

>> How receivers use that result is not something we should take on.
> 
> We agree on that goal.

   (What are we arguing about then?)

> Where we seem to be disagreeing is on the fact that letting the receiver 
> decide what fields to validate makes result C unpredictable.

   There are so many other sources of unpredictability that I decline to
get worked up over that one.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 23:52:12 -0500

On Tuesday, February 21, 2012 04:53:44 PM Dave CROCKER wrote:
> Random choices about processing order can produce differing assessments of
> the objective, authentication information.  That's a definition of
> non-interoperability.
> 
> validated information is used -- and, yes, subject to receiver-side local
> poliy and no, not known to the publisher.

Yes, but there isn't one input and output here.  There is a potential HELO 
check and a Mail From check each with their own results.  Two inputs, two 
outputs.  How they are evaluated (either separately or in tandem) is a matter 
for local policy.

I agree as far as "If I publish this SPF record and use this name in HELO I 
should get SPF Pass for HELO checks for this machine."  That must be reliable.

What order I run the code that produces the SPF results doesn't change what 
those results are, so there's no interoperability need to specify the order.

Since the receiver knows what the local policy is the receiver will know when, 
as an efficiency, it's not necessary to perform one of the checks.  We should 
let them decide that.  The current MUST for Mail From checks (which is where 
this started) doesn't make sense.

> We were just given data to suggest that checking the EHLO is a waste of

I think we were given an opinion.  Here's another set of data ...

I run the mail test service listed on http://www.openspf.net/Tools (spf-
[email-masked]).  I have a small script that parses the current log file to 
see the distribution of results.  Note that these are generally very error 
prone since the people who generally use this are trying to initially deploy 
SPF.  There are probably duplicates in here from people that tried more than 
once (I didn't check).

Messages in current log file - 274

Mail From Pass - 109
Mail From None - 63
Mail From Fail - 66
Mail From Softfail - 15
Mail From Neutral - 11
Mail From Temperror - 0
Mail From Permerror - 10

HELO Pass - 43
HELO Fail - 7
HELO None - 214
HELO Softfail - 2
HELO Neutral - 1
HELO Temperror - 0
HELO Permerror - 7

So in this data set there's ~25% coverage of one kind of another for HELO 
(compared to ~75% for Mail From).  While this is significantly less deployment 
than for Mail From, it's hardly trivial.  It is, of course, a statistically 
insignificant sample, but I suspect it is at least generally representative of 
initial deployment efforts.

> If it is a waste, we should drop it.

It's not.

> cannot know what the basic validation will be.  We need to remove that

We can't.  The non-determinacy is about local policy.  We aren't going to 
remove that.  The SPF results are quite deterministic.

> So you think it is ok that the basic validation results will vary depending
> upon the whims of the receiver?

No, I think that the need to doing them in some cases is a function of 
receiver policy.  I have an open source implementation for Postfix that has, 
for years, rejected messages with SPF HELO results of Fail, Softfail, 
Permerror by default before I even start to check Mail From.  I've never had a 
complaint.

https://launchpad.net/pypolicyd-spf

> > is Null.  I don't think trying to hard code any of these choices into
> > 4408bis is helpful.
> 

OK.

> > publish record A and send mail from server B, receivers will get SPF
> > result C".  How receivers use that result is not something we should
> > take on.
> 
> We agree on that goal.
> 

No it doesn't.  The only thing I'm looking for is changing a MUST to a SHOULD 
so that in cases where, due to local policy, the reciever knows the check 
won't affect the message disposition there's no requirement for a pointless 
check.  

Fundamentally, I think any MUST MUST be a true requirement for 
interoperability.  I'm confident this isn't one of those.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 21 Feb 2012 21:13:32 -0800

Hello,

This thread is off-topic at the moment.  Please do not comment on 
issues which have not been opened yet.

Thank you,
S. Moonesamy
SPF WG co-chair