Mutt Over SSH, but What About Attachments?

From the rejection files of Linux Journal, a suggestion for handling attachments in a remote Mutt session.

If you've proposed an article for Linux Journal and haven't heard back yet, one reason is sometimes our rejection letters get a little long. Here's an example.

Dear (contributor),

I'm going to have to reject your Mutt article.

Yes, it's cool to be able to get to your mail on any server easily by ssh, and yes, it's cool to be able to specify the application of your choice to view MIME attachments.

But what about combining the two? You can't expect people to stop sending you attachments just because you're out of town.

The whole “Mutt plus viewers” concept breaks down when you're reading mail in your account on a remote server—maybe a really remote server separated from you by a slow line—and you get an attachment. This happens to me all the time, especially with images for articles.

Your choices are basically save the image and scp it back to your desktop machine, bounce it to an alternate account that's set up to use a GUI mail client on localhost or run an X-based image viewer over the ssh connection. All three are dumb. The last is the easiest if your connection is fast, but you have to send the whole X protocol instead of only the compressed image, and it can be slow, especially for PDFs.

So, how do you efficiently handle attachments in a remote Mutt? I really want to know, because the more photos I get, the more I think about this.

I like the “Only give your email address to literary UNIX greybeards who prefer text and maybe ASCII art” method, but here's a second-best choice.

Important: you should not try this unless you control and trust both the system where you're running Mutt and your local system. Do this and it's possible that a bad person on the system running Mutt will see your attachments. A better version would protect your attachments from hostile users at both ends.

First, set up an ssh tunnel. I put this in my .ssh/config:

ProtocolKeepAlives 30
Host mail
    Protocol 2
    EscapeChar none
    ForwardX11 yes
    PasswordAuthentication no
    LocalForward 8088 localhost:8088

The important part is the LocalForward line; when I establish an ssh connection to the host “mail”, I get an ssh tunnel from localhost's port 8088 to port 8088 on mail. You also need to have ForwardX11 on, since this method does use X for one little thing.

Second, which program do we know that can handle any MIME type we're interested in? Our Mozilla web browser. But it's sitting on our laps, back on the client. That's fine; we'll point it at http://localhost:8088/, which is tunneled to “mail” where the attachment is.

So we've got Mozilla making a secure connection to the host where the attachment is, but don't we need to write a web server to serve up the attachment? Sure. Here's a script suitable for demonstrating the idea, but it will need a little work to be useful on multi-user systems.

#!/bin/sh
# spewtomoz.sh
# You shouldn't install this dumb script for all users because it only
# uses one pipe and one port.  Have it pick a better name for the pipe,
# and set the port from an environment variable.
TEMP="/tmp/spewtomoz"
PORT=8088
rm -f $TEMP
mkfifo --mode=600 $TEMP
# netcat is the fun part of this script.
# -l:            listen for an incoming connection
# -q 1:          wait 1s after EOF and quit
# -s 127.0.0.1   only use the lo interface
# -p $PORT       use $PORT
netcat -l -q 1 -s 127.0.0.1 -p $PORT < $TEMP &> /dev/null &
# send the HTTP headers, followed by a blank line.
echo "HTTP/1.1 200 OK" >> $TEMP
echo -n "Content-type: " >> $TEMP
file -bni $1 2> /dev/null >> $TEMP
echo >> $TEMP
# Get started sending the file...
cat $1 >> $TEMP &
# Wait a second and tell the user's Mozilla, wherever it is, to start
# viewing the file.  This works over the X protocol.
# (the date is to blow the cache and may not be necessary)
sleep 1 && gnome-moz-remote http://localhost:$PORT/`date +%s`
# end spewtomoz.sh

All that remains is to make Mutt use this script as the handler for MIME attachments. That means we're going to have to give Mutt an alternate mailcap file. Put this in your .muttrc file:

set mailcap_path="~/.mutt-mailcap"

And put this in ~/.mutt-mailcap

text/*; spewtomoz.sh %s
application/*; spewtomoz.sh %s
image/*; spewtomoz.sh %s
audio/*; spewtomoz.sh %s

Now, when you restart Mutt and select an attachment, it will come up in your Mozilla browser, if Mozilla understands the attachment's MIME type; if not, Mozilla will start a helper application, such as Abiword or xpdf.

I'm not totally satisfied with this method of handling attachments, and I haven't tried it over a very slow connection, but it's better than the alternatives I've seen. For example, if you get an interlaced image, it should display while loading, saving you some time.

A good Mutt article would have to handle this issue. I would welcome any suggestions for a better way.

Don Marti is editor in chief of Linux Journal.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Mutt over SSH: just pipe the attachments

Anonymous's picture

Here's what I do:

I just pipe the attachment directly to a file on my client, using ssh.

In Mutt, I select the attachment and then press the pipe keystroke, which is logically "|". Then:

ssh client 'cat >Desktop/my_attach.jpg'.

This has no setup unlike the other methods. It means you save writing out the attachment as a temp file on the server. However, you still have up the temp files on the client. That would be easily solved by writing them first a tmp directory, which was cleaned out a cron script.

Maybe a slick helper script could generate this syntax, replacing 'my_attach.jpg' with the actual file name of the attachment.

This works great - Thanx for

Anonymous's picture

This works great - Thanx for this tip. BUT unfortunately I can't use this as my desktop doesn't have public IP :-(

Re: Mutt Over SSH, but What About Attachments?

Anonymous's picture

Funny this should come up, I had just put together basically the same system for myself. The scripts i wrote are at http://people.internet2.edu/~danno/mozilla-stuff/

I did one different thing. rather than setting up an ssh tunnel for the file transfer, i copy attachments to my public_html directory, wait 5 seconds for the moz-remote client to do its thing, and delete the file from public_html. This is riskier than the ssh forwarding to localhost way, but was simpler to set up.

Obviously my approach only works if i have personal web space on the same server.

I'd really like to figure out a way to extend this to work when i am stuck sitting at a windows machine. The best idea i have come up with so far is to run cygwin and an sshd there, and scp the files back, like you mention above. I don't like this much; i'd really like to find something that is not real intrusive.

Maybe extending puTTY to accept a special escape sequence...hmm.

One thought about the need to "control" the mail server. The issue of control is different than the issue of trust, and what is important here is trust. Also, this system does not add any additional risk beyond what probably already have - your mail is already going to this server, and you probably already ssh-tunnelling X11 to it.

I tried something simlar a few years ago and netscape -remote was pretty awful over a medium-speed WAN connection. I seem to recall lots of xevents querying each window id on my X server. I haven't tried this thing over a slow connection yet but it probably hasn't changed.

i'm danpritts at ya hoo.

Re: Mutt Over SSH, but What About Attachments?

Anonymous's picture

well, the putty idea led me to look at putty's web site looking for it and they have heard this idea already (big surprise) and don't like it for security reasons (also big surprise).

they have a solution, though it is a little more heavyweight: DoIt

Re: Mutt Over SSH, but What About Attachments?

Anonymous's picture

Your idea is quite ok, but it maybe more comfortable

to open attachments (specifically office documents)

directly in Office Suite.

Once upon a time I've discovered that StarOffice

has kind of API which can be used over the network.

I haven't checked but I suppose it would be also

supported in the OpenOffice.

Check out: http://czarnobyl.pik-net.pl/openinso/

Re: Mutt Over SSH, but What About Attachments?

pdxmph's picture

How about installing imapd on the remote server, since it's one you "control and trust." Then you can tunnel IMAP from your local system back to the remote using the functionality mutt provides to do just that:

Here's a wiki entry describing it, or there's always the guide that's been around forever on SourceForge.

Re: Mutt Over SSH, but What About Attachments?

dmarti's picture

IMAP support in mutt is heinously slow. I tried getting to my server with IMAP for several months but it's so much faster, especially with the very large mailboxes I need to search, just to ssh in.

Re: Mutt Over SSH, but What About Attachments?

Anonymous's picture

Yeah, I've had the same issue (with Cyrus as the server); mutt's about 100-200 times slower than KMail opening a mailbox with a thousand messages. I'm gonna try comparing their IMAP code sometime.

Re: Mutt Over SSH, but What About Attachments?

pdxmph's picture

IMAP support in mutt is heinously slow.

It seemed so to me, as well. Then I applied a fix I found in the SquirrelMail archives when I faced similar performance with that client . Applies to UW IMAP, btw:

http://www.squirrelmail.org/wiki/en_US/SpeedWithUW

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix