RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 4407, "Purported Responsible Address in E-Mail Messages", April 2006

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 100
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-05-16
Held for Document Update by: Alexey Melnikov

 

(1)
On page 3 of RFC 4407, the third paragraph,

   Note that the results of this algorithm are only as truthful as the
   headers contained in the message; if a message contains fraudulent or
   incorrect headers, this algorithm will yield an incorrect result.
   [...]

should say:

   Note that the results of this algorithm are only as truthful as the
|  header fields contained in the message; if a message contains
|  fraudulent or incorrect header fields, this algorithm will yield an
   incorrect result.
   [...]


(2)
On page 3, the first sentence in Section 2,

   The PRA of a message is determined by the following algorithm:

should say more precisely:

   The PRA of a message is determined by the following algorithm,
   applied to the message header (i.e., the first mail header within
   the message, in case of a MIME message):


(3)
Subsequently, within the description of the six steps of the
algorithm (on page 3/4), the term `header` should always be replaced
by `header field`, and `headers` should always be replaced by
`header fields` (total of 16 occurrences).


(4)
On page 4 (just below the emumerated algorithm steps), the paragraph,

   For the purposes of this algorithm, a header field is "non-empty" if
   and only if it contains any non-whitespace characters.  Header fields
   that are otherwise relevant but contain only whitespace are ignored
   and treated as if they were not present.

should say:

   For the purposes of this algorithm, a header field is "non-empty" if
|  and only if its body contains any non-whitespace characters.  Header
|  fields that are otherwise relevant but contain only whitespace bodies
   are ignored and treated as if they were not present.

(5)
Immediately following the paragraph mentioned above in item (4), still
on page 4, the substitutions from item (3) above should be applied to
the next two paragraphs and the last paragraph of Section 2 as well
(total of 8 occurrences).


(6)
On page 5, the first paragraph of section 3,

   The PRA, as described by this document, is extracted from message
   headers that have historically not been verified.  Thus, anyone using
   the PRA for any purpose MUST be aware that the headers from which it
   is derived might be fraudulent, malicious, malformed, and/or
   incorrect.  [...]

should say (apply item (3) above twice):

   The PRA, as described by this document, is extracted from message
|  header fields that have historically not been verified.  Thus, anyone
|  using the PRA for any purpose MUST be aware that the header fields
   from which it is derived might be fraudulent, malicious, malformed,
   and/or incorrect.  [...]

and the second paragraph of Section 3,

   A message's PRA will often be extracted from a header field that is
   not normally displayed by existing mail user agent software.  If the
   PRA is used as part of a mechanism to authenticate the message's
   origin, the message SHOULD NOT be displayed with an indication of its
   authenticity (positive or negative) without the PRA header field also
   being displayed.

should say:

   A message's PRA will often be extracted from a header field that is
   not normally displayed by existing mail user agent software.  If the
   PRA is used as part of a mechanism to authenticate the message's
   origin, the message SHOULD NOT be displayed with an indication of its
|  authenticity (positive or negative) without the PRA header field body
   also being displayed.

Notes:

The RFC adds to the trouble of mis-used
terminology from the Internet Message Format (IMF) framework;
it repeatedly confuses the precisely defined terms, 'header',
'header field', and 'header field body'.

The most recent summary of the IETF standardized IMF terminology
(from RFC 2822 et al.) can be found on page 3 of RFC 4249:


3.1.1. Standard Terminology

Terms related to the Internet Message Format are defined in
[N2.RFC2822]. Authors specifying extension header fields should use
the same terms in the same manner in order to provide clarity and
* avoid confusion. For example, a "header" [I1.FYI18], [N2.RFC2822] is
* comprised of "header fields", each of which has a "field name" and
* usually has a "field body". Each message may have multiple
* "headers", viz. a message header and MIME-part [N4.RFC2046] headers.

* A message header has a Date header field (i.e., a field with field
* name "Date"). However, there is no "Date header"; use of such non-
* standard terms is likely to lead to confusion, possibly resulting in
* interoperability failures of implementations.


For details, see Sections 2.1 and 2.2 of RFC 2822 and other places.
I also recommend the terminology sections in RFC 4021 and RFC 3864.

from pending

Report New Errata



Advanced Search