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 <[EMAIL PROTECTED]> http://dotat.at/ FAIR ISLE FAEROES: VARIABLE 3 OR 4, BUT NORTHERLY 5 OR 6 IN WEST FAEROES. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
