Mutt Over SSH, but What About Attachments?
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.
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:
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.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- New Products
- Users, Permissions and Multitenant Sites
- diff -u: What's New in Kernel Development