mail-ng
[Top] [All Lists]

Another user-visible goal

2004-06-03 11:58:21

One item that could be improved in next-generation email is better
orthogonality between envelope, header, and body.

In physical mail, the envelope contains sender and recipient addresses,
postmarks, special handling instructions (delivery notifications, etc.)
and is visible and inseparable from the content throughout delivery
(except for unusual circumstances).  The content itself is contained
within the envelope and is not generally visible; it is only examined
or modified (censored) in the hands of fascist regimes.

Current email has evolved differently. The envelope is usually separate
from the content, and might not be visible in some parts of transport.
Conversely, the content is often visible and is frequently subject to
alteration (header field slicing, dicing, and munging, for example).
Postmarks (Received fields) and special handling instructions
(Disposition-Notification-{To,Options}) are imposed upon the content
rather than the envelope. At final delivery, the sender envelope
information (Return-Path) is affixed to the content.  Content is
frequently subject to snooping (filtering) and censorship (content
munging by anti-virus spammers (er, scanners)).  Such fuzzy boundaries
between envelope, header, and body make things analogous to a sealed
message difficult at best (e.g. there is at present no simple
mechanism for digital signing or encryption of message content
including header fields).

It would be nice if next-generation email kept envelope information
clearly separate from, yet firmly attached to, the content (header
plus body) during transit.  The user-visible advantages include the
ability to view the message header (as an electronic version of a
physical message heading and footer; author(s), origination date,
cc list, etc.) without extraneous clutter, the ability to digitally
sign and encrypt content including the header, and availability of
consolidated envelope information for those who wish to examine
postmarks, etc.


<Prev in Thread] Current Thread [Next in Thread>