🚀 go-pugleaf

On 2010-01-04, blueman <NOSPAM@nospam.com> wrote:
> Julian Bradfield <jcb@inf.ed.ac.uk> writes:

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

No. THE FROM LINE IS NOT PART OF THE MESSAGE!
It's part of the folder's meta-data.
I keep my mailboxes in MMDF format - there is no conceivable sense in
which the enclosing ^A^A^A^A's can be considered "part of the
message". (Although VM "D" does, buggily in my view, display them in
the presentation buffer.)

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

That would be the "entire message" option, then - which should surely be the
default.
If you want the folder separators as well, define an option to include
them.

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

Then you didn't ask for what you wanted. Beside which, spamassassin is
perfectably capable of taking an *individual* message in standard
form and processing it - indeed, that's what it does by default, isn't
it? If you want to feed it a folder in mbox format, don't you have to
give a special argument?


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

The message together with the folder data is not a legal
message. That's very destructive - I lost quite a bit of mail a few
years ago because I didn't notice that various filters were barfing on
the From line that procmail added.

If you absolutely NEED to contenate a bunch of messages and pipe the
resulting folder to a command, then do it.

> Do you have any specific use cases where the change I am proposing will
> mess up existing code or applications? Theoretical problems encountered

Yes: it will break every use I make of the | command in VM, where I'm
always piping to a progam that expects (or I want, in the case of
printing) to receive a message in RFC2822 form.

In any case, I don't understand your use case:
vm-pipe-message-to-command says that it runs the command separately
for each message - how are you using it?