Topic: two SME servers for one domain and mail client verification

[mophilly]

We have two SME servers at the moment. One is SME 8 on an old machine slated to be retired. The other is SME 9.2 on new hardware. The user accounts were migrated to the new server and seem to be working. We were hoping to migrate things in small chunks, and finally retire the old server.

We can send and receive email using Horde on the new server and I can do the same using an iPhone that outside the LAN. The Apple Mail.app on MacOS 10.11.6 inside the LAN cannot connect to the smtp server.

The DNS zone record has MX, and other records, pointed to the new server. We also have on the old server some iBays hosting other domains, as well as the web site for the primary domain. So the www.mydomain.com is pointed at the old server, but the MX records, e.g. mail.mydomain.com and smtp.mydomain.com, point to the new server.

Also, email addressed to, say, "support" at the other domains used to flow through to the primary account named "support". That is not working, but I expected that it wouldn't without adjustment.

So I have two issues that someone here may be able to help me resolve. First, how to set the hostnames or other config so that the new server email is used by the domains still hosted on the old server. Second, how to get the Apple Mail.app to connect to the smtp on the new server.

Suggestions, links to docs and articles, etc., are most welcome.

[mmccarn]

First, how to set the hostnames or other config so that the new server email is used by the domains still hosted on the old server.

Configuring an "internal mail server" for the remaining domains should work:
https://wiki.contribs.org/Email#Deliver_email_for_one_domain_to_an_internal_or_external_mail_server

Second, how to get the Apple Mail.app to connect to the smtp on the new server.

Do you know if the problem is DNS related or SSL related?  Modern email clients seem to want "real" certificates.  This advice is really old, but might be useful:
https://wiki.contribs.org/Email#Entourage:_Using_SME.27s_Self-Signed_Certificate_for_SSL_Connections_from_Entourage_on_OS_X_10.4

[mophilly]

Thank you, mmccarn.

I will give the internal mail server setting a go.

I am pretty certain the issue with the mail client is DNS/hostname related, as we use an SSL UCC certificate from GoDaddy. I have tested the site with MX Toolbox with favorable results.

dmarc is not yet set up on the new server. perhaps that is the issue. However, this type of connection problem with MacOS mail.app has been seen rather often. Apple is aggressive, in some ways, with security updates. That, with the various versions of mail.app, make support for MacOS a regular sprint.

In this case, the iPhone works but the desktop client sitting on the LAN does not. It can receive but not send.

[mmccarn]

Apple Mail.app - like Thunderbird - stores the incoming (IMAPS) username and password separately from the outgoing (SMTPS) username and password.  I've had users get the wrong password on the SMTP side, then had a difficult time getting the prompt back to enter a new one, or pick the wrong SMTP server if they get an error when trying to send an email.

Also, I feel like I have always had to change the SMTPS port from 25 to 465 when setting up email clients with a SME server.  I think the TLS support on port 25 is supposed to make this unnecessary, but I do it anyway.

For DNS - as long as you get the new IP address for the configured smtp server from the workstations they should be able to send email. MX, DMARC, SPF, etc don't come into it.  You mention both 'mail.mydomain.com' and 'smtp.mydomain.com' in your original post.  'smtp.mydomain.com' is not one of the default hostnames created during the SME server install -- if your Mail.app clients are using that host for SMTP the name may still resolve to the old server.

In the vein of the 'internal mail server' for incoming mail, you could also configure the old server to use the new server as the "internet provider's mail server":
https://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter13#E-mail_Delivery

This doesn't solve the client configuration problem, but it would cause all of your email to pass through the new server on its way to wherever it is going...

[mophilly]

I set the old server Email Delivery setting "Address of internal mail server" to point to the IP address of the new server. I wasn't sure whether I could use a FQDN in that value.

Regarding the Apple mail.app and authentication, it seems to be an issue of very sticky caches. Having verified that all the mail account settings were correct, we ran the following using the Terminal.app:

Code: [Select]

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder;
That seemed to allow the Mac to renegotiate things and connect with the correct server.

We also found that we goofed on the user account migration. The Lazy Admin Tools helped a lot, but because I didn't shut down the old server email at the same time, we gathered new mail on both servers. Oops. So a bit of rsync magic helped get us caught up in a fashion.

Code: [Select]

#!/bin/sh
# August 30, 2017 with help from Greg Simpson, Joe Maus, Mark Phillips
#
# include dot files
echo set bash to include dot file
shopt -u dotglob
#
# set up command line and go for it
echo Starting rsync, ingore existing, preserve permissions, owner and group.
ehco verbose, recursive, and compressed
RSYNC=/usr/bin/rsync
SSH=/usr/bin/ssh
KEY=/root/cron/new-server-rsync-key
RUSER=root
RHOST=192.168.xxx.yyy
RPATH=/home/e-smith/files/users/
LPATH=/home/e-smith/files/users/
$RSYNC --ignore-existing -zrvpog -e "$SSH -i $KEY" $RUSER@$RHOST:$RPATH $LPATH
# fini
echo rsync complete
So, with everything sync'd in mostly good order, we are on our way forward again.