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 ;-)
> 
> 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?
> 
> 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.

sshfs is also an option for simply sharing your maildir from one machine
but may be laggy if your link is high latency.
 
> 
> 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.  SSL 
connections can be to protect data in transit.  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.

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

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.

> Assistance/suggestions greatly appreciated.
> 


Reply via email to