on 18:39 Mon 27 Jun, goraxe (gor...@goraxe.me.uk) wrote: > On Sun, 2011-06-26 at 20:04 -0700, Dr. Ed Morbius wrote: > > This is a usage scenario which largely doesn't involve mutt directly, > > though it does impact heavily on its use and usability. > > > > TL;DR: > Noted will try and be concise ;-)
That was actually aimed at myself ;-) > > > > Consider the following configuration: > > > > - Remote Linux shell account on system with full mail access. > > - Local laptop/desktop with intermittant network connectivity. > Is your access ssh only? Or are smtp, imap etc externally accessible? > > > > Astute observers may note that the email address used to send this mal > > is hosted through gmail -- the issue exists with another account (gmail > > + offlineimap + mutt FTW, BTW). > Guessing this means no external access to that box? Sorry? I don't have phyiscal access to that box, no. However it's got a public Internet presence and handles modest amounts of mail for a domain, several individuals, and a couple of mailing lists. > > I can rsync the remote mutt Inbox maildir locally reasonably easily. > > Done. > > > > > > The first hitch is keeping local/remote folders in sync (this is > > possible through rsync, though I need to look into how best to do this > > such that the last change (whether it's local or remote) is preserved. > > Archiving mail outside the rsync tree should avoid having to deal with > > large/wholesale changes to mail volume (and reduce remote storage > > requirements). > > cron and rsync the spit and glue of the internet. hint --delete and > maildir format should work, less certain about other mail formats. You > may just want the --delete on the push side where you do your reading so > as not to accidentally delete unread mail. Right. I can handle the rsync aspect of things pretty easily. I'm also aware of --delete, though I'm cautious in applying that to my mailstream. Right now, periodically manually rsyncing the inbox when starting a mail processing session (I may hit mail once a day or a few times a day) is sufficient. I've got a shell script I can invoke manually. If cronning that makes sense, it's easy enough to do. > sshfs is also an option for simply sharing your maildir from one machine > but may be laggy if your link is high latency. It's too laggy, I've tried that. sshfs is unbelievably awesome in general though. > > > > The second hitch is coming up with a good way to have local mail > > submitted to the remote host when sending. Local and remote MTAs are > > both exim4. I'm thinking some magick with SSH (ssh-agent is running) or > > such. > > > > You could have your mail mta relay through the remote mta. That's pretty much the solution I'm looking at. There are a couple of distinct local users and their handling needs to be individualized (and/or domain sending), so I'll need to look through the Exim docs to sort this out at some point (in which case the problem is properly dealt with in the Exim space, and really isn't a mutt problem, other than that mutt is part of the mailstream. > SSL connections can be to protect data in transit. Or ssh tunnels (the autossh recipe suggested earlier is being tried now). I'll need to see if the remote exim server can use SSL and authenticated transfer as well. > I have set this up with postfix to exim (I did not have access to the > exim side). Has the advantage that you can just spool if there is not > a connection to remote mta and deliver, when connection is restored. > MTA software can also automaticly verify certs and refuse to deliver > mail if the host cert suddenly looks phishy. I believe the spooling thing works with the autossh solution. I'd set up the local exim instance to send gmail traffic through gmail, other traffic through its specified host, and local delivery locally. > Other options include use of ssh -w any <host> to create a p-t-p vpn > over ssh, this requires the admin of the remote machine are prepared to > make some changes as outlined in > http://www.debian-administration.org/articles/539 Oooh. I forgot openssh had made ad-hoc VPNs so easy (though I remember reading about them). _This_ would solve the problem on the routing side. Hrm.... > This will give you an full vpn into your remote host which may have side > benefits. May need some coaxing of admin to allow it. Yeah, I think that's going to require remote root, right? Not an option then. Regular tunnel should work. -- Dr. Ed Morbius, Chief Scientist / | Robot Wrangler / Staff Psychologist | When you seek unlimited power Krell Power Systems Unlimited | Go to Krell!
