spf-discuss
[Top] [All Lists]

Re: The New SPF: introducing RFROM

2004-05-24 14:25:14
"Meng" == Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> 
writes:

    Meng> Do we have a good understanding of which M*As will prepend
    Meng> and which will append the Resent-* headers?  Mutt, I think,
    Meng> will append.  Appending is more trouble than prepending,
    Meng> because it screws up the linear-chronology assumption.

Considering this from a standards point of view, there are two cases
here: mailers that purport to comply with RFC822, and mailers that
purport to comply with RFC2822.

RFC822 states that the order of the headers is not constrained, and is
not semantically significant (4.1).  It also says that the
interpretation of multiple Resent-* fields of the same type is
undefined (4.2).

So any prudent implementor of RFC822 resending would hopefully remove
any preexisting Resent-* headers prior to adding their own.  Since an
RFC822 message will hopefully only contain one set of Resent-*
headers, it doesn't matter really matter where in the header they
occur.

Although RFC2822 (3.6) only says that Resent-* fields SHOULD be
prepended in blocks, the BNF requires all Resent-* and Received
headers to come before all the other headers, so appending would
appear to be prohibited.  Given that, it's highly unlikely that any
conformant RFC2822 mailer would choose to do anything other than
prepend.

I'll also note in passing that according to my reading, RFC2822 does
not allow for the creation of additional trace fields.  In particular,
adding Received-SPF headers causes the message to violate the BNF in
section 3.6 (since the Received-SPF header is an optional-field, and
hence must come after all Resent-* and Received headers).

So what we get is this:

Prepending is obviously fine, and is recommended by RFC2822.

Appending is fine, so long as any preexisting Resent-* headers are
removed.  This behaviour would seem perfectly reasonable for a mailer
following RFC822 rather than RFC2822, and causes no problems for the
PRD algorithm.

Appending, but leaving preexisting Resent-* headers intact will break
the PRD algorithm in the case of multiple resending.

    -roy