Re: [secdir] SECDIR Review of draft-ietf-spfbis-4408bis-19

[S Moonesamy <[e-mail]>]

Hi Phillip,
At 05:07 11-09-2013, Phillip Hallam-Baker wrote:
>Minor issues.
>
>1.1.3.  MAIL FROM Definition
>
>I found this section completely opaque and very confusing. It should 
>not be necessary to hunt through other specs to find a definition. 
>Particularly since the referenced specs do not give an explicit 
>definition for the term as used and the references point to the 
>whole spec rather than a particular section.

The text below is to address the comment about Section 1.1.3 (credits 
to Rolf E. Sonneveld):

1.1.3.  MAIL FROM Definition

    This document uses "MAIL FROM" to refer to RFC5321.MailFrom (reverse-path).
    The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 as an end-to-end
    string that specifies an email address for receiving return control
    information, such as returned messages.

>The Security Considerations section is adequate for the purpose 
>except that no mention is made anywhere in the specification about 
>DKIM and how a mail receiver should interpret presence of DKIM and 
>SPF policy at the same time. This is a legitimate concern since DKIM 
>is already a standards track proposal and SPF is only now being 
>promoted to Standards Track. Thus the SPF document should address 
>the question of dual use.

I commented about the above in my previous reply.

>8.7.  Permerror
>"This signals an error condition that definitely requires operator 
>intervention to be resolved."
>
>I cannot imagine a circumstance which definitely requires a human to 
>be involved in mail delivery.

These are permanent DNS errors or SPF record errors.  For example, if 
an SPF record requires too many DNS lookups, someone has to change 
the record to make the error go away.

The definitely was intended to distinguish from cases such as a DNS 
SERVFAIL that may or may not be permanent, but are temperrors in 
SPF.  In the case of ambiguity about if an error is temporary or 
permanent, it's treated in the design as assumed to be temporary.

>11.2.  SPF-Authorized Email May Contain Other False Identities
>
>    Do not construe the "MAIL FROM" and "HELO" identity authorizations to
>    provide more assurance than they do.
>
>Document has quasi normative language that should be worded as 
>statements of fact rather than as direction.

The following change is proposed is response to the above:

    The "MAIL FROM" and "HELO" identity authorizations do not provide assurance
    about the authorization/authenticity of other identities used in the
    message.

Regards,
S. Moonesamy (as document shepherd)