mutt/2735: printing mails with/without attachments

>Number:         2735
>Notify-List:    
>Category:       mutt
>Synopsis:       printing mails with/without attachments
>Confidential:   no
>Severity:       normal
>Priority:       medium
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 06:58:22 +0100 2007
>Originator:     Robert W.
>Release:        1.5.13
>Organization:
>Environment:
MacOS/X, Gentoo Linux, NetBSD 3.0
>Description:
scenario: There several tagged messages. All of the tagged messages are to be printed.
wish: An option to print the emails with or without their attachments.
>How-To-Repeat:
>Fix:
Copy messages for printing in a separate mailbox, delete all attachments, tag them, print them.
>Add-To-Audit-Trail:

>Unformatted:

[PATCH] [RFC] Allow mutt to render an e-mail from the command-line

Background: In trying to write yet another biff app, I wanted to
create a brief summary of an e-mail. After fighting some Perl and
MIME packages, and seeing what others had done before, it soon
became clear that I was reinventing a rather large wheel. Mutt does
a wonderful job of rendering e-mail as text already, handling
multi-part messages, HTML, character set conversion, etc. The only
thing it is missing is the ability to call it from the command-line
and render an e-mail to stdout.

The attached patch adds the -r (render) flag, which accepts the
filename of a raw e-mail message. It renders the message to stdout
as you would view it in mutt, but leaves the headers intact. e.g.:
  $ mutt -r <file containing raw e-mail>

I think it'd be a small, but useful addition to mutt.

I'm not familiar with the internals of mutt however, so if there's
something grossly wrong, please let me know. It works for me(tm). :)

Kind regards,
Bernard.

Index: mutt-1.5.13/copy.c
===================================================================
--- mutt-1.5.13.orig/copy.c	2007-02-02 17:45:20.000000000 +1100
+++ mutt-1.5.13/copy.c	2007-02-02 18:15:33.000000000 +1100
 <at>  <at>  -32,6 +32,7  <at>  <at> 
 #include <string.h>
 #include <stdlib.h>

Re: [PATCH] [RFC] Allow mutt to render an e-mail from the

Re: Bernard Blackham 2007-02-02 <20070202072430.GA24799 <at> mersenne.largestprime.net>
> The attached patch adds the -r (render) flag, which accepts the
> filename of a raw e-mail message. It renders the message to stdout
> as you would view it in mutt, but leaves the headers intact. e.g.:
>   $ mutt -r <file containing raw e-mail>
> 
> I think it'd be a small, but useful addition to mutt.

Hi,

I'm not opposed to this patch, but here's some crude hack that roughly
does the same:

$ mutt -e'set print_command=cat; push py<enter><quit><enter>' -Rf filename

Maybe some idea from it can be reused...

Christoph
--

-- 
cb <at> df7cb.de | http://www.df7cb.de/

Mail loss

Moin moin,

sadly I learned that for quite some long time mails to my previous
addr have been lost (always more the more recenty).

If you have sent any personal or public msg and haven't received
an answer yet (for private, off-/ on-topic, meta-ML/ ML-tech),
then please remind me with some context quote to this new addr.
Thank you and I'm sorry for the noise.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL of it: you get what you give.

EXACT_ADDRESS define and ADDRESS.val, can someone explain.

I am completely new to the mutt codebase, and I am trying to create a
simple patch to allow mutt to auto create capability keys and add these
keys to the
source e-mail address (user <at> domain -> user+key <at> domain). I'll not go into
the what any further right now as it is the how that is giving me some
problems right now. The rfc822.h defines a ADDRESS struct type with a
'val' field
that is aparently optional depending on the compiler flag EXACT_ADDRESS.
Given that for my patch I need to be working with the mailbox and personal
fields of the ADDRESS structure, the optional 'val' field may be relevant to
what I am working on, but I can not make any sense of what it is for
and/or when the compile flag would be enabled or disabled.

Could someone help me to gain understanding on how and why of the  ADDRESS
val field and the EXACT_ADDRESS compile flag in order to find out if I
need to worry about them for my patch.

T.I.A.

Rob J Meijer

header cache for all folder types?

I'm inclined to suggest that we turn on the header cahce for *all*
folder types, not just for maildirs -- or at least to do some
performance testing as to whether there's a way to activate it for
mbox folders that would make parsing these much faster.

Any takers?
--

-- 
Thomas Roessler   <roessler <at> does-not-exist.org>

Re: header cache for all folder types?

* On 2007.02.05, in <20070205174845.GT24582 <at> raktajino.does-not-exist.org>,
*	"Thomas Roessler" <roessler <at> does-not-exist.org> wrote:
> I'm inclined to suggest that we turn on the header cahce for *all*
> folder types, not just for maildirs -- or at least to do some
> performance testing as to whether there's a way to activate it for
> mbox folders that would make parsing these much faster.

I would like to see that.  I'm afraid I can't spare time now -- many
projects open at once -- but perhaps I could at some point if it's not
already adopted.  Nonetheless, maybe it's meaningful to talk about
strategy.

T. Glanzmann has implied that caching mbox is not doable[1] because of
cache consistency concerns, presumably because mboxes messages aren't
discrete and associated to a unique filestore object that carries change
metadata.

I think a "good enough" solution can be reached by storing message byte
offsets in the cache db with a checksum/hash of the N bytes following
that offset.  From offset deltas you can deduce the message length in
the real mbox file (the cache may already know the length) and the
hash over length N gives you a probabilty of N/length that the message
has not been externally modified.

If N is equal to the header length, then that's equal to Maildir's
confidence, but N can vary (at cost of confidence) if it improves
performance.  N can be different for each message, and cached.

Performance of an mbox cached in this way is probably not notably
greater (if at all) than uncached where messages are small (under one

Segfault with CVS mutt

When opening an IMAPS mailbox, I am getting a crash with the
head-of-CVS mutt.  The mailbox starts to read in the headers, then
mutt prints out "Error opening mailbox" and segfaults.

Here is a backtrace, 'mutt -v' output is below that, and the tail of
.muttdebug0 is after that.

David

Program received signal SIGSEGV, Segmentation fault.
imap_free_header_data (data=0x54) at message.c:943
943       mutt_free_list (&(((IMAP_HEADER_DATA*) *data)->keywords));
(gdb) p data
$1 = (void **) 0x54
(gdb) bt full
#0  imap_free_header_data (data=0x54) at message.c:943
No locals.
#1  0x080e3bcc in imap_close_mailbox (ctx=0x92d8980) at imap.c:1303
        i = 7
#2  0x08091db4 in mx_fastclose_mailbox (ctx=0x92d8980) at mx.c:750
        i = 0
#3  0x08091d5b in mx_open_mailbox (
    path=0xbfc71450 "imaps://xxx.xxx.xxx/INBOX", flags=0, pctx=0x0)
    at mx.c:731
        ctx = (CONTEXT *) 0x92d8980
        rc = -1
#4  0x080679e7 in mutt_index_menu () at curs_main.c:1118
        buf = "imaps://xxx.xxx.xxx/INBOX", '\0' <repeats 989 times>
        helpstr = "q:Quit  d:Del  u:Undel  s:Save  m:Mail      ?:Help\000\000<\000\000\000\000\000\000\000=\000\000\000\000\000\000\000P\000\000\000\000\000\000\000\204�\204\000l;\006\b\000\000\000\0008\024ǿM�\177\000h\232$\thE,\tH\024ǿ�1\006\bh\232$\t\000\000\000\000\210\030ǿ\212<\006\b"
        op = 99

Re: [PATCH] [RFC] Allow mutt to render an e-mail from the

Christoph Berg wrote:
> Re: Bernard Blackham 2007-02-02 <20070202072430.GA24799 <at> mersenne.largestprime.net>
>> The attached patch adds the -r (render) flag, which accepts the
>> filename of a raw e-mail message. It renders the message to stdout
> 
> I'm not opposed to this patch, but here's some crude hack that roughly
> does the same:
> 
> $ mutt -e'set print_command=cat; push py<enter><quit><enter>' -Rf filename
> 
> Maybe some idea from it can be reused...

It's a good idea, thanks! It seems though that my Maildir messages don't 
contain the From line that starts an mbox message, so it doesn't 
recognise the message alone as being a folder. I don't want to have to 
rewrite the e-mail in order to get mutt to parse it. I could link the 
file into a temporary Maildir structure I guess, but that's still an 
icky hack.

Kind regards,

Bernard.

Re: EXACT_ADDRESS define and ADDRESS.val, can someone explain.

=- Rob Meijer wrote on Sun  4.Feb'07 at 20:54:49 +0100 -=

> Could someone help me to gain understanding on how and why of
> the ADDRESS val field and the EXACT_ADDRESS compile flag in
> order to find out if I need to worry about them for my patch.

No idea, but grepping the source for that FLAG should reveal not
too many places where it plays a role and perhaps you understand.

Also check the archive, I vaguely remember this has been discussed
some months ago.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL of it: you get what you give.