wayne <wayne(_at_)schlitt(_dot_)net> wrote:
http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
which includes:
]
] 7. The Received-SPF header field
]
] It is RECOMMENDED that SMTP receivers record the result of SPF
] processing in the message headers. If an SMTP receiver chooses to do
] so, it SHOULD use the "Received-SPF" header defined here for each
] identity that was checked. This information is intended for the
] recipient. (Information intended for the sender is described in
] Section 6.2, Explanation.)
]
] The Received-SPF header is a trace field (see [RFC2822] section
] 3.6.7) and SHOULD be prepended to existing headers, above the
] Received: header that is generated by the SMTP receiver. It MUST
] appear above any other Received-SPF headers in the message.
This is a very interesting idea, with some promise of enabling a
chain of trust.
(Of course, any chain of trust is only as strong as its weakest link;
but any trust at all could greatly improve the forwarding problem.)
We SHOULD discuss on this list whether such a header can be considered
a "trace field"; and I'd like to suggest that we do so in a context of
what "envelope information" means.
IMHO, it has become clear that we wish "envelope information" to
include more than the SMTP commands. (I think John Klensin had the
right general idea in his draft-klensin-email-envelope draft.)
Unfortunately, we currently have vagueness about envelope.
draft-crocker-email-arch discusses:
"
" Section 4.1.1 Envelope:
"" Information that is directly used by, or produced by, the MHS is
"" called the "envelope". It controls and records handling activities
"" by the transfer service. Internet Mail has a fragmented framework
"" for handling this "handling" information. The envelope exists partly
"" in the transfer protocol SMTP [RFC2821] and partly in the message
"" object [RFC2822]. The SMTP specification uses the term to refer only
"" to the transfer-protocol information.
""
"" NOTE:
"" Due to the frequent use of the term "envelope" to refer only to
"" SMTP constructs, there has been some call for using a different
"" term, to label the larger set of information defined here. So
"" far, no alternative term has developed any community support.
""
"" Direct envelope addressing information, as well as optional transfer
"" directives, are carried within the SMTP control channel. Other
"" envelope information, such as trace records, is carried within the
"" content header fields. Upon delivery, some SMTP-level envelope
"" information is typically encoded within additional content header
"" fields, such as Return-Path.
(Note the "such as trace records", and "encoded within additional
content header fields"...)
IMHO, we have a potentially-useful "envelope" entity if we limit it
to SMTP commands and trace information.
Other mentions of "envelope" in Crocker's draft seem to fit as
SMTP:
"
" Recipient address(es) specified in the envelope
"
" [Aliasing] resubmits the message, replacing the envelope address
"
" An MDA that is re-posting a message to an alias typically changes
" only envelope information
or trace:
"
" A Relay may add information to the envelope, such as with trace
" information
(This is a bit problematic, since a Relay is likely to add information
to headers which clearly are NOT intended as envelope information.)
or both:
" A mail Relay... adds envelope-level handling information
"
" However it does not modify existing envelope information
"
" A message comprises a transit handling envelope
"
" The envelope contains handling information used by the Message Handling
" Service, or generated by it
"
" Hence an MTA implements both client and server MTA functionality.
" It does not make changes to addresses in the envelope or
" reformulate the content, except as transfer-encoding requirements
" dictate. Also it may add trace information.
So, my first question to the group is, "Is there anything beyond
SMTP commands and trace headers (however defined) that we want to be
included when we talk of "envelope information"?
--
John Leslie <john(_at_)jlc(_dot_)net>