[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another user-visible goal


On 8-jun-04, at 4:58, Bruce Lilly wrote:

For example, consider a recent message on this mailing list. It contained,
when it appeared in by mailbox, aside from the content-related fields:

[...]

9 Received fields (NINE of them! Each one several lines long)

In essence, each email message contains its own logfile.

1 X-Sieve field
1 X-Authentication-Warning field
1 X-Mailer field
1 Precedence field:(which is neither standard nor user-defined)
1 List-Archive field
1 List-Unsubscribe field
1 List ID field

Most of these are the same for all messages to the list or all messages to the list from the same poster, so good database design principles dictate that they not be present in each message.

The trouble is that there is only upward pressure on the inclusion of extra information, and very little downward pressure (except people like me complaining about it on mailing lists like this) so this is spiraling out of control.

1. Make digital signing of the message content (body *and* _sender-specified_ header fields) practical

I think this can easily be accomplished by tagging all information that is added to a message with a label that indicates where this happened. It is then trivial to sign a message as it was at any given point along the path.

2. Keep transport-related markings out of the message content

I don't think this is useful, as the trend is in the opposite direction. For instance, a message doesn't have to contain the actual recipient anywhere in the headers, but there are many different headers that actually include this information because it's useful to have available after the message delivery process has completed. (Sender, received and so on.) Another way to approach this is to assume the delivery process never completes so this envelope information stays with the message indefinitely.

Having a standardized format that includes ALL the information about a message (body, header and envelope) would also allow the transport protocol to be very simple, as it may consist of simply transferring the whole file as-is. (Back to ftp...)