At 10:41 PM 2/22/2005 -0500, Martin G. Diehl wrote:
David MacQuigg wrote:
>
> At 01:24 AM 2/23/2005 +0100, Alex wrote:
>
> > Trace headers have a long history... Are you sure this
> > is "new" ?
>
> Using Received: headers is certainly a possibility,
[snip]
> RFC2822 defines the Received header as follows:
> received = "Received:" name-val-list ";" date-time CRLF
> I can't find anything further on the details of the
> name-val-list. Has this been formalized in some other
> document?
>
> I assume the reason people developed new headers like
> Received-SPF was to avoid these problems.
Do you mean these lines on pp 28 of RFC2822?
----------------------------------------------------------------------
received = "Received:" name-val-list ";" date-time CRLF
name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
name-val-pair = item-name CFWS item-value
[ snip more lines of syntax definition ]
What I'm looking for is a higher-level definition. If we are to rely on
Received: lines for authentication information, we need a standard format
for that information. For example, when we see
Received: from engine.ieee.org ([140.98.193.23] verified) by gci-net.com
... with ESMTP-TLS ...
do we know what "verified" means, or do we have to call gci-net (Gain
Communications) to find out. Will it be possible to just add a few items
to a Received header, and avoid the need for a new header entirely?
Received headers have the advantage that they are already widely
accepted. That may help us avoid the "not-invented-here" attitude that has
stalled current efforts. These headers already have most of the
fundamental items needed by any authentication protocol (domain name, IP
address, result). They even allow for added "comments" where we could put
hash codes and other items needed for a specific protocol.
The problem I anticipate is that in standardizing the format of the
authentication items in a Received header, we may force changes in programs
that have already done it some other way. For example, if we say the word
"verified" is not standard, you must state the protocol and keyword as
defined in that protocol (e.g. SPF1-PASS), will that cause problems with
programs that are now relying on the word "verified"?
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq at gain.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com