🚀 go-pugleaf

Julian Bradfield <jcb@inf.ed.ac.uk> writes:

> 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.

Except that I doubt too many people are using it since the command
itself is rather broken (at least if you try to use the optional
arguments)

Also, the command is *not* well specified. It says *entire* message
which includes the From lines and anything else.

If you want just the header or just the message then you can use the
already defined options with prefix args. If you want the sum total of
the headers (without the From) and the message (without any potential
trailers) then I am suggesting adding a 4th option.

Moreover, the multiple message functionality was actually a feature
request that I made of Robert a couple of years ago specifically for the
purpose of grabbing the *entire* message for use with spamassassin but
never got around to testing...

So I stand by my suggestion unless multiple others have coded on the
basis of this function -- especially since I seem to be one of the few
people who have really been using this code to any real extent unless
others have fixed the bugs without notifying the group...

I really think that the default should "do no harm" to the folder since
you may want to use this function to pipe portions of your mailbox
folder(s) non-destructively somewhere else... If you are not using mbox
format then this change shouldn't make any distance since your mta will
have stripped off the from. And if you are using mbox format, then you
probably want the from included or else you will be destructively
changing the output. Indeed, the casual user of mbox format will be
surprised to find his/her message format destroyed -- in fact, it took
me a while to figure out why spamassassin and formail were not able to
parse the extracted messages...

Do you have any specific use cases where the change I am proposing will
mess up existing code or applications? Theoretical problems encountered
elsewhere that may involve some theoretical future code is not
compelling especially since I am proposing to add an option that would
give you the sum total of the headers and footers (by adding a 4th
prefix). In fact, there would even be logic to building up the message
that way from its component parts...