Issue solved: Windows-specific SMTP mail sending issues

Help! (Home for newbies)
1

Hello,

OS: CentOS Linux 6.4
Virtualmin: 3.99.gpl GPL

I’m suddenly seeing some odd issues over the last few days with one client using:

Outlook as part of Microsoft Office 2003 Professional Edition
and
Windows Mail (as a test) Version 6.0.6000.16386

Incoming mail is working as usual, but outgoing mail is taking a long time for them to send, and flashing up the odd message that SSL is not supported on the server, even though it is (with a properly signed cert), and even though no Apple Mail clients have any trouble sending mail via authentication over SSL. The person having issues is the sole Windows user who connects to my system.

I have verified that the client in question is authenticating properly with these settings (to which they have not made any recent changes, and with which they were not having any issues up until a few days ago):

Outgoing Port: 587
SSL: On
Authentication Type: Password

The username style on the server is exclusively the user.domain (not user@domain) style. There are no authentication failure messages on their end or my end.

Here are the relevant Mail Log lines (asterisks put in place for their privacy):

May 4 10:10:17 hive dovecot: pop3-login: Login: user=<.>, method=PLAIN, rip=..., lip=..., mpid=23174, TLS
May 4 10:11:36 hive postfix/smtpd[23231]: connect from ....hsd1.ca.comcast.net[...]
May 4 10:11:36 hive postfix/smtpd[23231]: lost connection after UNKNOWN from ....hsd1.ca.comcast.net[...]
May 4 10:11:36 hive postfix/smtpd[23231]: disconnect from ....hsd1.ca.comcast.net[...]
May 4 10:11:36 hive postfix/smtpd[23231]: connect from ....hsd1.ca.comcast.net[...]
May 4 10:11:36 hive postfix/smtpd[23231]: lost connection after CONNECT from ....hsd1.ca.comcast.net[...]
May 4 10:11:36 hive postfix/smtpd[23231]: disconnect from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: connect from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: lost connection after UNKNOWN from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: disconnect from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: connect from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: lost connection after CONNECT from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: disconnect from ....hsd1.ca.comcast.net[...]
May 4 10:14:02 hive postfix/smtpd[23253]: connect from ....hsd1.ca.comcast.net[...]
May 4 10:14:03 hive postfix/smtpd[23253]: 858111040E20: client=....hsd1.ca.comcast.net[...], sasl_method=LOGIN, sasl_username=.
May 4 10:14:06 hive postfix/smtpd[23253]: disconnect from ....hsd1.ca.comcast.net[...]
May 4 10:15:25 hive dovecot: pop3-login: Login: user=<.>, method=PLAIN, rip=..., lip=..., mpid=23295, TLS
May 4 10:17:26 hive postfix/anvil[23233]: statistics: max connection rate 3/60s for (submission:...) at May 4 10:14:02
May 4 10:17:26 hive postfix/anvil[23233]: statistics: max connection count 1 for (submission:...) at May 4 10:11:36
May 4 10:20:26 hive dovecot: pop3-login: Login: user=<stan.spamspameggandspam>, method=PLAIN, rip=..., lip=..., mpid=23394, TLS

I’ve tried searching the forums here, and mistakenly (I believe?) thought adding the -r parameter to saslauthd would help, until I realized that had to do with the @ in the username, which is not the case for me. It’s odd that the client in question is always able to send emails in the end, however it takes 5 or 10 minutes to do so, with SSL errors flashing up during that time. I had them reset their cable modem just in case something odd was going on there, but to no avail. For what it’s worth, I also tried this:

ps auxw | grep saslauthd

root 714 0.0 0.0 66568 1672 ? Ss May02 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2
root 715 0.0 0.0 66568 1620 ? S May02 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2
root 26116 0.0 0.0 103244 868 pts/0 S+ 11:14 0:00 grep saslauthd

I added the -r parameter (when I didn’t quite know what that meant) to /etc/sysconfig/saslauthd and then restarted saslauthd via /etc/init.d/saslauthd restart… grepping again now shows this:

root 26232 0.0 0.0 66412 1892 ? Ss 11:18 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2 -r
root 26233 0.0 0.0 64308 652 ? S 11:18 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2 -r
root 26379 0.0 0.0 103244 860 pts/0 S+ 11:23 0:00 grep saslauth

Any ideas on what could be causing this Windows-email-client-specific outgoing-only mail issue all of a sudden? Thank you again so much for your help, Virtualmin is a fantastic product and I really love it :slight_smile:

2

It would appear that adding the -r flag to saslauthd did the trick, though I wasn’t sure it would, given no usernames have the @ sign… but perhaps -r does some other things too? In any case, after adding that flag and restarting saslauthd, my sole Windows user now reports no delays in sending mail. I assume it wasn’t restarting saslauthd that did the trick, as I rebooted the whole server two days ago just to make sure that wasn’t it. So adding the -r flag appears to have solved this Windows-specific outgoing-mail case, at least for me, in case others are searching with similar issues!

3

I’m glad you figured it out, thanks for letting us know how you fixed it!

4

This morning I heard again from the Windows client in question that the issue is back… it’s taking them a long time to send emails, and their email client is reporting the following error: “Reported error (0x800CCC7D): ‘Your outgoing (SMTP) server does not support SSL-secured connections. Then it goes on to say to contact your server administrator or ISP provider.”

So I’m guessing that the -r flag had no effect after all, as I suspected since we don’t use the user@domain syntax, but instead the user.domain syntax. So… this really is an odd, intermittent error, given that this Windows client is always able to send their emails in the end, and that no Mac mail clients have any issues. Do the log lines above shed any light on the issue to those more experienced here?

I tried to grep one more time to make sure the saslauth settings hadn’t changed overnight, but they are as they were:
root 19556 0.0 0.0 103240 856 pts/0 S+ 07:39 0:00 grep saslauth
root 26232 0.0 0.0 66568 2024 ? Ss May04 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2 -r
root 26233 0.0 0.0 66568 1952 ? S May04 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2 -r

Thanks in advance for suggestions, I really do appreciate the help here, and Virtualmin, which I love :slight_smile:

5

What happens if you configure the client to use TLS, rather than SSL… does that help?

Or perhaps if you use SSL on port 465?

-Eric

6

Thank you for your prompt response; it took me a few days to have a moment to troubleshoot again, as this was only affecting the sole Windows user connecting to the server.

Their preferred client is Outlook 2003 (!!), which according to Microsoft forums does not support TLS, so I tried opening up port 465 instead. I hadn’t realized until I found other threads here that port 465 supports authentication a little differently from port 587. Lo and behold (two days running now), switching to port 465 has appeared to solve their problem… and as a bonus, the Mac users on the system report their outgoing email speed has improved slightly too! I know OS X Mail tries all three ports (25, 465, 587), I assume in that order for the change to have affected Mac clients. I can’t even recall now why I opened only 587 to begin with… it certainly didn’t give us any trouble for about a year with Windows email clients, so perhaps some Microsoft update changed the behavior, or perhaps Comcast (this Windows user’s ISP) has done something that causes intermittent connection timeouts on port 587?

In any case, port 465 was the answer for us, all over SSL so nice and secure :slight_smile: I rolled back the other change I made (referenced above) with the -r flag for saslauthd, so the flags are -n 2 as they were originally set by default. I rolled that change back prior to opening up port 465 on the Linux firewall via Webmin.

Thanks again for your prompt and informative help, we really appreciate it!! Virtualmin keeps getting better and better, and I’m so happy (as a refugee from the Plesk family :wink: