Subject: [spfbis] Possible ABNF nit with Received-SPF

From: Hector Santos <[email-masked]>
Date: Mon, 03 Sep 2012 16:03:15 -0400

In 4408 section 7 (7.1 for BIS), there is:

    key              = "client-ip" / "envelope-from" / "helo" /
                       "problem" / "receiver" / "identity" /
                        mechanism / name

    identity         = "mailfrom"   ; for the "MAIL FROM" identity
                       / "helo"     ; for the "HELO" identity
                       / name       ; other identities

Isn't the keys for identity redundant for the regular set of possible 
keys?

        "mailfrom"  same as "envelope-from" for key
        "helo"      same as "helo" for key
        "name       same as "name" for key

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Sep 2012 14:04:31 -0400

> Isn't the keys for identity redundant for the regular set of possible keys?
>

No.  The "key" production specifies what goes on the *left* side of
the "=" sign, such as

   envelope-from=<[email-masked]>

and

   helo=example.com

whereas the "identity" production is what goes on the *right* side of
the "=" sign when the *key* is "identity":

   identity=mailfrom

or

   identity=helo

I think it would be a good idea to change the name of the "identity"
production to "identity-val", or some such, to avoid that confusion.

But I think there *is* a bug in the ABNF for "key": shouldn't
"mechanism" be in quotes?  I think what's meant is to have something
like this:

   mechanism=MX

Right?  That needs "mechanism" to be in quotes in the "key" production.

Barry

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Sep 2012 15:22:18 -0400

> production to "identity-val", or some such, to avoid that confusion.

+1 or perhaps this suggestion based on the intent of this identity= 
key field as currently described:

    identity   the identity that was checked; see the <identity> ABNF
               rule

which I presume is to provide a tracing data point of what identity 
caused the Received-SPF: result value.  A possible better reading may 
be to use  "result-identity":

    key              = "client-ip" / "envelope-from" / "helo" /
                       "problem" / "receiver" / "result-identity" /
                       mechanism / name

    result-identity  = identity

Part of the confusion I had besides not catching key value "identity" 
was double quoted, was related to the section 7.1 example and also 
reading section 7.2:

    Received-SPF: fail (mybox.example.org: domain of
                      [email-masked] does not designate
                      192.0.2.1 as permitted sender)
                      identity=mailfrom; client-ip=192.0.2.1;
                      envelope-from="[email-masked]";

I was getting the impression that in general these keys are inputs:

    envelope-from=
    helo=
    client-ip=

and identity= key would indicate which identity failed among 
envelope-from or helo. So with the example not having helo=, it 
implies envelope-from was the only identity checked.  Having 
identity=mailfrom is redundant, this is somewhat confirmed with 
section 7.2 where  it says:

    The reason SHOULD include a key-value-list with keys provinding [TYPO]
    information normally included in a Received-SPF header field that is
    not already part of the Authentication-Results header field.  That
    is, at least "client-ip", "helo", and, if the "MAIL FROM" identity
    was checked, "envelope-from".

So it seems to say that using identity= may be redundant depending on 
what Inputs are provided.

Does it make sense to trace this with without helo= key added?

    Received-SPF: fail (mybox.example.org: domain of
                      [email-masked] does not designate
                      192.0.2.1 as permitted sender)
                      identity=helo;
                      client-ip=192.0.2.1;
                      envelope-from="[email-masked]";

Also, how does one write the trace when both identities are checked?

> Right?  That needs "mechanism" to be in quotes in the "key" production.

I think so. So there was a possibility of typos!

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 05 Sep 2012 11:18:24 +0200

> production to "identity-val", or some such, to avoid that confusion.

IMHO, the gain in clarification that we could possibly achieve by such
change is certainly less than the added confusion that any changes in
production rules inevitably produce.  I'd limit them to necessary
error corrections, if at all possible.

-1 to this suggestion.