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>


Reply via email to