Subject: [spfbis] Section 2 of draft-ietf-spfbis-4408bis-06

From: S Moonesamy <[email-masked]>
Date: Sat, 01 Sep 2012 01:14:16 -0700

Hello,

These comments are about Section 2 of draft-ietf-spfbis-4408bis-06.

 From Section 2.1 of RFC 4408:

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

And Section 2.1 of the draft:

  'SPF verifiers MUST check the ""MAIL FROM" identity if a completed
   "HELO" check has not reached a definitive policy result by applying
   the check_host() function to the "MAIL FROM" identity as the
   <sender>.'

There is a change from RFC 2119 recommendation to RFC 2119 
requirement in the above.  This is related to Issue #15.

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

I don't recall this being discussed on the mailing list.  I am making 
a note of it as it is a change from RFC 4408.

  'Note that requirements for the domain presented in the EHLO or HELO
   command are not always clear to the sending party, and SPF verifiers
   MUST be prepared for the "HELO" identity to be malformed or an IP
   address literal.'

There is an additional RFC 2119 requirement compared to what is in RFC 4408.

 From Section 2.2 of RFC 4408:

  'SPF verifiers MUST check the ""MAIL FROM" identity if a completed
   "HELO" check has not reached a definitive policy result by applying
   the check_host() function to the "MAIL FROM" identity as the
   <sender>.'

 From the draft:

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

It would be better to have this in one sentence to have the RFC 2119 
requirement clear.

In Section 2.3:

  'An SPF-compliant domain MUST have valid SPF records as described in
    Section 3.'

This is similar to what is in RFC 2119.

 From RFC 4408:

  'If domain owners choose to publish SPF records, it is RECOMMENDED
   that they end in "-all", or redirect to other records that do, so
   that a definitive determination of authorization can be made.'

And the draft:

  'If domain owners choose to publish SPF records and want to support
   receivers making negative authorization determinations, then they
   MUST publish records that end in "-all", or redirect to other
   records that do, otherwise, no definitive determination of
   authorization can be made.  Potential issues and mitigations
   associated with negative determinations are discussed in Section 9.'

The terminology (domain owners in this case) is inconsistent when 
compared with other sections of the draft.  The RFC 2119 requirement 
is a significant change.

 From the draft:

   "This can be as much as 30 days."

There was a short discussion about this change on the mailing list.

 From Section 2.4:

  'A mail receiver can perform a set of SPF checks for each mail message
   it receives.'

What is a mail receiver?

  "When a mail receiver decides to perform an SPF check, it MUST use a
   correctly-implemented check_host() function (Section 4) evaluated
   with the correct parameters."

This is an unnecessary RFC 2119 requirement.

  "Although the test as a whole is optional, once it has been decided
   to perform a test it MUST be  performed as specified so that the
   correct semantics are preserved between publisher and receiver."

A new RFC 2119 has been added compared to RFC 4408.

  'Implementations MUST take care to correctly extract the <domain> from
    the data given with the SMTP MAIL FROM command as many MTAs will
    still accept such things as source routes (see [RFC5321], Appendix
    C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).'

There is a new RFC 2119 requirement compared to RFC 4408.  As a nit, 
the above text creates two normative references causing more required reading.

 From Section 2.5 of the draft:

  "Performing the authorization other than using the return-path and
   client address at the time of the MAIL command during the SMTP
   transaction can cause problems, such as the following"

The usage of return-path is inconsistent with Section 1.3.3.

 From RFC 4408:

  "Generating non-delivery notifications to forged identities that have
   failed the authorization check is generally abusive and against the
   explicit wishes of the identity owner."

And the draft:

  "Generating non-delivery notifications to forged identities that have
   failed the authorization check is a source of backscatter and SHOULD
   be avoided.  [RFC3834] section 2 describes backscatter and the
   problems it causes."

A RFC 2119 recommendation was added.  Section 2 of RFC 3834 is about 
automated responses.

 From Section 2.5.1 of RFC 4408:

  'A result of "None" means that no records were published by the domain
   or that no checkable sender domain could be determined from the given
   identity.  The checking software cannot ascertain whether or not the
   client host is authorized.'

And the draft:

  'A result of "none" means either (a) no syntactically valid DNS domain
   name was extracted from the SMTP session that could be used as the
   one to be authorized, or (b) no TXT records were retrieved from the
   DNS that appeared to be intended for use by SPF verifiers.'

That could be considered as a clarrification.

Section 2.5.4 generated significant discussion.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Sep 2012 20:02:44 -0700

On Sat, Sep 1, 2012 at 1:14 AM, S Moonesamy <[email-masked]> wrote:
> There is a change from RFC 2119 recommendation to RFC 2119 requirement in
> the above.  This is related to Issue #15.

I agree that the logic should be consolidated.

> I don't recall this being discussed on the mailing list.  I am making a note
> of it as it is a change from RFC 4408.

It's a useful clarification and is not normative, so I don't think
it's a big deal.

> There is an additional RFC 2119 requirement compared to what is in RFC 4408.

I think it's important to point out that the HELO/EHLO parameter might
not be a fully-qualified domain name and might not resolve.  However,
RFC5321 already does this as I recall.  The MUSTard can probably go
here, therefore.

> It would be better to have this in one sentence to have the RFC 2119

The sentences are so short already that I don't think it matters that much.

> This is similar to what is in RFC 2119.

Sorry, can you clarify?  RFC2119 says something like this?

> The terminology (domain owners in this case) is inconsistent when compared
> with other sections of the draft.

ADMD is probably appropriate here.

> The RFC 2119 requirement is a significant
> change.

The RFC2119 change is appropriate, because interoperability of the
stated goal (negative determinations) requires "-all".  It is not the
default.

> There was a short discussion about this change on the mailing list.

The question was asked where this value came from.  I never saw an
answer.  Perhaps it's better to use a term like "arbitrarily long".

>  'A mail receiver can perform a set of SPF checks for each mail message

RFC5598 defines "recipient"; we should use that.

> This is an unnecessary RFC 2119 requirement.

+1.

> A new RFC 2119 has been added compared to RFC 4408.

I think it's an unnecessary statement overall.

> There is a new RFC 2119 requirement compared to RFC 4408.  As a nit, the
> above text creates two normative references causing more required reading.

I would change MUST to "need to".

> A RFC 2119 recommendation was added.  Section 2 of RFC 3834 is about

I think the normative recommendation is reasonable; it avoids an
undesirable side effect of interoperability in certain cases.

> That could be considered as a clarrification.

+1; it fits.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:21:19 -0400

> requirement in the above.  This is related to Issue #15.

This is a change, but it relaxes a requirement, it doesn't impose any new 
requirement.

> a note of it as it is a change from RFC 4408.

It was.

> There is an additional RFC 2119 requirement compared to what is in RFC 4408.

This is one that is part of my global changes from 4408 to 4408bis.  It seems 
to me reasonable to change this because there will be interoperability 
problems if one does not do that.  

> It would be better to have this in one sentence to have the RFC 2119

You have these reversed.  The first one is from the draft and the second is 
from 4408.

> compared with other sections of the draft.  The RFC 2119 requirement

This should be matched to be consistent terminology wise, but now is the MUST 
significant?  What would be an SPF compliant domain with no SPF record?  Of 
course it MUST publish one.

>   'A mail receiver can perform a set of SPF checks for each mail message

What terminology would you suggest?

> This is an unnecessary RFC 2119 requirement.

How so?  You can't get a correct SPF result without a correct implementation.  
There are pseudo SPF implementations out there and they should not call their 
results SPF results.  Doing so creates confusion.  I think it's reasonable to 
state that the SPF check must be done correctly or not at all (or not called 
an SPF check).

> A new RFC 2119 has been added compared to RFC 4408.

This is perhaps redundant with the previous one, so I guess we might pick one.

> the above text creates two normative references causing more required

This is another must/MUST change.  I think it is reasonable, since if you 
extract the wrong domain, it's pretty well all over as far a interoperability 
goes.

> The usage of return-path is inconsistent with Section 1.3.3.

No.  It's not.

> A RFC 2119 recommendation was added.  Section 2 of RFC 3834 is about

This was discussed on the list and was considered to be an improvement in the 
draft.

> Section 2.5.4 generated significant discussion.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sun, 02 Sep 2012 22:34:50 -0700

Hi Murray,
>Sorry, can you clarify?  RFC2119 says something like this?

It was a typo.  I should have written that it was similar to what is 
in RFC 4408.

Regards,
S. Moonesamy