🚀 go-pugleaf

On 2010-01-04, blueman <NOSPAM@nospam.com> wrote:
> HOWEVER, vm-pipe-message-part is skipping the initial 'From' line since
> it is using (vm-headers-of m) as the start rather than (vm-start-of m).
> Similarly, it uses (vm-text-end-of m) rather than (vm-end-of m)
>
> Since the usual reason for splitting/piping messages to an external
> shell command is to pass the message to some standard 3rd program, it
> would be helpful to use standard conventions -- by which I mean
> something relatively consistent with 'formail' or better yet the RFC's.
> In particular, when you ask for the "entire message", I at least expect
> the entire message.

VM is behaving correctly. The initial From line is NOT part of the RFC
standard, nor is it part of the message. It's an obsolete Unix mbox hack
that should have been killed off decades ago - the mbox format is
patently unsuitable, leading to abominations like From-stuffing.
I've had immense trouble with very broken mail systems (procmail) that
insist on putting the From in where it has no business - it caused
standards-compliant mail filters to break, because they saw a From
instead of a proper message.

> In my case, spamassassin thinks a collection of messages is just one big
> message since it doesn't see the 'From' line.
>
> I would suggest making the following change so that the default "entire
> message" truly includes the entire message and perhaps add an option
> with four universal arguments that gives the current default behavior.

Bad idea. If you want to have a command that does
"take bunch of messages, concatenate them into given (mbox in your case)
mailbox format, pipe resulting mbox to program"
then write a command to do that - don't break an existing well
specified command.