[CentOS] Email access via Android device

Les Mikesell lesmikesell at gmail.com
Mon Oct 7 23:37:40 UTC 2013


On Mon, Oct 7, 2013 at 5:20 PM, Frank Cox <theatre at melvilletheatre.com> wrote:
>
>> Hard to beat a free gmail account - if you are concerned about
>> privacy, you probably shouldn't be sending the stuff over the internet
>> in the first place.
>
> I figure that if my data lives on my computer, I know where it is and I can
> read it, search it, back it up and delete it anytime I want.
>
> I learned a long time ago that if you see something on the Internet that you
> think you might want to refer to in the future, get it now because it might not
> be there tomorrow.

Ok, but that applies to hardware that you own as well.   Maybe you can
beat Google for redundancy, reliability, distributed backups, etc. but
it won't be easy.   And with a simple imapsync or maybe even some
tweaks to your sylpheed setup you could have both.  That is, use
google for live access  but keep a mirror copy.  My guess is that your
disk(s) will die before googles'.   Other ISP type accounts will come
and go as you change services.

> For outbound mail my best idea so far is to set up postfix to send outbound
> mail via the appropriate mailserver by checking the From: field.  I see a
> method for doing that here:http://tekman.livejournal.cohm/83609.html

But how do you set your From: separately for every message in the
android mailer - and it seems awkward when you could be connecting
directly to the account in question.

> By doing it this way I can get away with doing everything over a ssh tunnel to
> my main computer from my Android device.  VX Connectbot apparently supports ssh
> tunneling so once that and K9Mail (which I haven't actually installed or
> looked at yet) are set up on my phone it should just work.

Again, seems awkward to tunnel access to a private host to access
stuff that had just been pulled from publicly reachable accounts.

>>   Alternatively your android device is perfectly capable of dealing
>> with 6 remote servers directly.
>
> The reason for handling outbound email this way instead of sending it directly
> from my phone (or whatever) is that this way I won't have to worry about sender
> restrictions on the various mailservers.

Android could reply back through the account directly.  Your
complications are coming from combining things in the first place.

> For example,  my own little mail and
> webserver lives on the 192.168.0.x network in my theatre, and postfix relay is
> set up to permit_mynetworks only.  In addition, I think (though I'm not
> completely certain) that both of the ISPs that I have service from allow email
> to be relayed through their mailservers only from a network address that's one
> of theirs.

Many/most ISP and email hosts allow mobile access with login/password.

> That's my scheme so far.  Any of you fine folks are very welcome to tell me why
> it won't work or suggest a better way to get from Point A to Point B.  I've
> never set up anything quite like this before so it's a figure-it-out-as-I-go
> procss.

Sure, it will work, but I don't really see what you gain over just
using the services as-is as separate accounts, especially if they all
offer IMAP so your computer and phone see the same things.  (Plus your
archived copy if you want...).    I have several accounts myself, but
nearly all of them are configured to forward to gmail and I never use
them directly.

> I'm obviously going to set up some dummy email accounts and experiment with
> this a bit and get it all up and running before trying to convert my real email
> and go live with it.  I really don't want to blow up my email; things would
> become far more interesting that they need to be if something like that
> happened.
>
> I think it'll be pretty cool once it's up and running, though.

I ran something similar using an SME server as the imap host for a
long time - before google offered imap service.  But now that box is
dead and google is still running...

-- 
   Les Mikesell
       lesmikesell at gmail.com



More information about the CentOS mailing list