On Wed, 27 Jun 2007, Jeremy Shaw wrote:
Currently I am difficulty dealing with headers that could appear more than once.
I recommend that you treat the header fields as an ordered list. Do not
use the latitude that the specification gives you to re-order headers, and
do not assume that messages you have to process will be within the minimum
and maximum count requirements for each field. (This rules out encoding
those requirements in the type system.) Postmasters will hate your
software if you do either of these things :-)
You need to support appending new fields to the top as well as the bottom
of the header. Although it's traditional in most situations to add a new
field to the bottom of the header, Received: fields must be added to the
start. For any application that does message processing on an MTA, it's a
*really* good idea to add new fields to the top of the header, so that
they appear interspersed amongst the Received: lines in a way that
indicates where and when the processing happened. Doing this also means
your program will play nicely with DKIM. Ignore the strict syntax in RFC
2822 that prevents arbitrary trace header fields: this is a bug that will
be fixed in the next version of the spec, and in practice software doesn't
mind unexpected trace fields.
Tony.
--
f.a.n.finch