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. _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
