<pipe-message> vs. <save-message> / <pipe-entry> vs. <save-entry>
Jon Brinkmann
brinkmann at nmsu.edu
Wed Mar 23 21:01:31 UTC 2022
First the background:
I'm forced to use a Microsoft Exchange server for my email. It's configured
(not by me) to tag SPF incorrectly authorized and other suspect messages
as "Undeliverable". It always attaches the original message with the full
original header as attachment 5. Here's what the "v" command shows for a
typical message:
I 1 <no description> [multipa/alternativ, 7bit, nK]
I 2 <no description> [text/plain, quoted, us-ascii, nK]
I 3 <no description> [text/html, quoted, us-ascii, nK]
I 4 <no description> [message/delivery-s, 7bit, nK]
I 5 <original subject> [message/rfc822, 7bit, nK]
I 6 <no description> [multipa/alternativ, 7bit, nK]
I 7 <no description> [text/plain, quoted, iso-8859-1, nK]
I 8 <no description> [text/html, quoted, iso-8859-1, nK]
I'm working to extract the original message and send it back through procmail
to be properly sorted into my mailboxes. I've mapped this process to the
'E' key:
macro index E '<view-attachments>5<enter><pipe-entry>procmail;tail procmail.log<enter>' 'extract & process a message that Microsoft Exchange called undeliverable'
It works great, with one problem: <pipe-entry> doesn't pass the mailbox
delimiting "From [email_address] [message_date]" to procmail, which sorts and
writes what it received to a file that's not recognized as a mailbox by mutt.
Is there some way to tell <pipe-entry> to pass the delimiter line? If not,
should this be a code change request?
FYI, it appears that <pipe-message> and <pipe-entry> are identical. At
least they produce identical results.
I could work around the problem by using <save-entry> (and it appears
that <save-message> and <save-entry> are also identical) which does pass
the delimiter line. I'd have to save the attachment to a temporary file,
redirect it to procmail and then delete the file. I'd prefer not to do this
if possible.
I also realize that <pipe-entry> is a simpler operation than <save-entry>.
The latter has to deal with, among other things, a pre-existing file with
older messages, file locking, etc.
Thanks,
Jon
More information about the Mutt-users
mailing list