On 06/12/13 22:39, mick wrote: {}
I don't know what your internal DNS looks like either, but I suspect from what you say above though that you are having a problem because you have separate names for your mail server depending upon whether you are sending mail from inside your home (via hst.me.uk) or from outside your home (via hst.no-ip.com). Is that right?
Ideally, and to make things easier, you should have a single name for your mailer (say mail.hst.me.uk) which you can use in your mail client configs. Internally, your DNS (or hosts files or whatever you use) would then point mail.hst.me.uk to the correct IP address. Externally, your DNS should also point mail.hst.me.uk to the correct IP address but there you have a problem. You don't have a static address. Unfortunately, you cannot point an MX record at an alias (otherwise it would be a simple matter of pointing mail.hst.me.uk to hst.no-ip.com). So, given that you are stuck with the name hst.no-ip.com as the MX externally, I suggest that you use exactly the same name internally. (So set up a hosts file entry for that name pointing to the correct internal IP address, or frig the DNS by running your own internal version of the no-ip.com domain.) Your phone's email client could then be configured to always connect to hst.no-ip.com andit wouldn't matter whether you used the internal wifi or the 3G data connection.
Now to the certificate.
It doesn't matter if the CN, OU or other details in the certificate do not match the name or domain details of the mail server. At worst your email client will object on first connection, but once you have agreed and accepted the certificate, all future connections will proceed quite happily.
{}
Hi Mick,
Thanks for looking into this for me.
One of the problems I've had is not knowing which name to put in certificates - the me.uk or no-ip.com variants. You've covered that in that as you say either will work.
The other major problem that I've had, even before trying to connect a mobile phone to the server. I did not want to introduce any vulnerabilities onto my server.
(As I understand it - feel free to point out any problems with my understanding!)
I didn't want to make it an open relay (intentionally or unintentionally). Consequently I think that means I need to authenticate with the server. Authenticating with the server requires certificates, otherwise passwords could be sniffed. Even with certificates, I'd like to make sure that they were being used and that unauthenticated and/or logins without certificates not be allowed. I also don't want to someone could telnet onto my server and keep trying to guess user names and passwords. - I know that it's possible to use denyhosts and similar to monitor ssh access and block suspicious login attempts/addresses - I'd like to do something similar with email if possible.
As I said, thanks for the pointers. I'll work thorough it next week when I have a bit more time.
Cheers Steve