Re: Writing the 'From ' line

* Bill Moseley ([email protected]) [040121 19:29]:
> Ok.  So, say you want to go through all messages and add a header and
> write back to the same mbox.  Do you have to clone and write it as a new
> message?

No... then simply modify the message.  But be warned, that officially,
if you mutulate the header too much, you should update the Message-ID
as well.

> > A clone is rarely needed: it is only required when you take one message
> > and then base a new message on that.
> 
> That's ok.  But are you saying that it may loose the "fromLine" along
> the way?  That makes sense in that the fromLine is a mbox thingy --
> although it's nice to retain as much envelope info as possible.

Yes and yes.

> Back to the ->clone.  I was first reading messages from one mail box,
> sorting them, and then writing them back to a new mailbox.  When I
> didn't clone I was getting:
> 
>   Attempt to free unreferenced scalar: SV 0x8575844.

That's a bug in Perl.

> > There are more people wanting me to change things around the fromLine.
> > For instance, sometimes Mail::Message->read(\*STDIN) tumbles over it,
> > when (for instance) sendmail is conifgured to pass it on.  So it may
> > well be that in one of the coming releases, any kind of message has
> > such a line.  I'm still hesitating.
> 
> Hope I'm following, but The 'From ' is a mbox thing.  But, if messages
> were read from a mbox and written to maildir then it would be nice to
> somehow retain that data -- like adding an Envelope-To: and
> Delivery-date: header from the address and date in the 'From ' line.
> Assuming those headers are not already there.

Patches in this field may get accepted ;-)

> I'm making that up because I don't know what the RFCs say.  My comment
> is that data should not be lost in the translation.

There are always things you lose.  In this case, it is not too bad,
because the MTA (who hands you the message) will also add a Received
field to the message, which contains the same info.
-- 
               MarkOv

------------------------------------------------------------------------
drs Mark A.C.J. Overmeer                                MARKOV Solutions
       [email protected]                          [email protected]
http://Mark.Overmeer.net                   http://solutions.overmeer.net