[Email-SIG] header api

[Stephen J. Turnbull]

Eric S. Johansson writes:

 > have a specific question on headers and the related api.  according to another 
 > listmember (which I've forgotten), all headers should be used at
 > most once. 

This is false.  A few standard headers may appear only once.  Most
headers may appear multiple times.  See the table in section 3.6 of
RFC 5322.  It's not clear from the wording whether the maximum is a
"SHOULD NOT" or a "MUST NOT" appear more than once.

 > I've seen many apps that use the same header repeatedly to hold info specific to 
 > that app.  what is the preferred way of storing multiple lines of application 
 > specific info?  unique headers? multi-line header?  to what extent should the 
 > api support/enforce this info management ideal?

Conceptually, each header is a single variable, containing a single
logical line (which may be *folded* into several physical lines).  The
MUA VM is written in Lisp.  It keeps its highly structured internal
bookkeeping data in a Lisp list, which works fine because Lisp doesn't
care about whitespace at all (and it's very unusual for such a header
to be used by anything but VM).  MIME headers often contain multiple
parameters, separated by semicolons.  There are other such conventions
you could use.  On the other hand, if you are sending these headers
through the mail system, then you need to be aware that older MTAs and
filtering programs may rebreak lines at inopportune places; you cannot
be sure that data structured into lines will not be corrupted in that
way (for example, the email package itself has some such, er,
"undesigned features").  Also, if you use multiple instances of the
same header (say "X-App-Data"), you cannot guarantee that the headers
will not be reordered by some intermediate MTA or MUA.  (I believe RFC
5322 forbids that, but sufficently old versions of the Internet
Message Format standard did not.)

IMO the email package should allow the app to request warnings if an
incoming message is not standard-conforming, and should strongly
discourage (but not necessarily make impossible) construction of
messages that exceed the limits on the number of certain headers that
are allowed.