ietf-822
[Top] [All Lists]

Re: a header authentication scheme

2004-10-23 14:29:46

In <200410221106(_dot_)53024(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:

On Wed October 20 2004 23:05, Laird Breyer wrote:

On Oct 20 2004, Justin Mason wrote:

As you said previously, the Received header is always prepended.  This can
be exploited more simply for the Processed header, as long as the
Processed header is *also* prepended *only*, and never appended, by each
processor.

Just a quick explanation on why quoting text is perhaps a good idea.

If each piece of software which writes a Processed header always puts
it at the top, then you're right it's enough to look for the next
Received header down to discover where the Processed header was added,
so there's no need to quote ID or datestamp.

The ID or datestamp quoting described is intended to cope with
Processed headers which are either added somewhere else (e.g. many
filters add headers at the end of the list - sometimes it's simply
easier to add at the top, sometimes it's simply easier to add at the
bottom), and also to cope with possible third party rearranging of
headers (because header order is only guaranteed for Received headers
in general).

A fundamental problem is that the Internet mail model does
not permit adding arbitrary fields "at the top", "at the bottom",
or anywhere else. It provides only for addition or modification
of specific fields by Submission agents, and for time stamp
fields (a.k.a. Received fields) by SMTP receivers, and for a
Return-Path field when final delivery is performed.  There is no
provision for any other addition, and provision only for removal
of Return-Path fields by an SMTP receiver.  Otherwise,
message transport via SMTP is intentionally transparent.

Nevertheless, it is often done, and it is not going to stop being done. It
is even useful in tracking problems, provided it is understood that the
extra headers are for tracing of some form, and are always added at the
front so as to give a full history of how the message propagated.

For example, a mail sent to a list may acquire a few Received fields on
the way to the list-expander. There it may acquire an assortment of
List.*: fields, and then some more Received fields as it finds it way to
some final recipient.

Then again, if it passes through a site that does forwarding to some other
address, then you may see assorted X-fields describing its progression
through the forwarding machinery.

And it some site provides a spam or virus filtering service, then one
would expect to see some account of that in the headers, e.g. an account
of the Spamassassin score and the things that contributed to it.

And so if Laird wants to propose his Processed: field and have it
accepted as a proposed standard, then the standard has only to say that it
updates RFC 2822, and that the extra field is to be a "trace" field for
the purposes of RFC 2822.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, 
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5