Smoot Carl-Mitchell wrote: > > Actually, I'm pretty sure it is only the Received header that would > > ever show more than once in the main header of a message. > > Read the relevant RFCs for mail message standards. I'd start with > RFC2822 and work forward from there.
This is definitely a good idea for anyone writing a full-scale mail handler > There are a number of header fields > which can legally appear more than once in a message I don't doubt that. I am going on what I have actually observed in some fairly extensives sequential archives of mail-as-received. I did produce a quite successful arcive storage, retrieval and search system without dealing with duplicate header lines. A full-scale mailer would probably be much more complicated. Presumably, one step to simplify the task somewhat would be to sort possible hear lines into broad grouoings that can be handled in uniform manner, then sort out the special cases, as well. Most instances where I have seen multi-valued header fields are single lines with the value string delimited in ways specific to the type of header tag. They do take some pretty sensitive handling, and I do not mean to trivialize the task. > . Most MTAs do > not check the message headers in detail. They only deal with the > envelope information. So it is easy to generate a technically > illegal message. Also note that any header can be folded, although it is > typically only the Received: headers which are routinely wrapped for > readability. I'll do some more scanning through my hdr directory to see how many folded lines I actually see. Ooooh! I see The To line can also get folded. I think the trick that I showed for testing for initial space should work for that It is very clear that the input processing has to use some sort of $curent_tag and $current_value scoped outside the input loop to handle this., Headers like Received should indeed be pulled aside for special handling, but I do not think you will find that many in actual use. > As usual when writing code against a protocol standard, be liberal > in what you will accept as valid input. True, but for headers, a good filter helps a lot. There is a lot of extraneous material there. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>