Outlook 2007 authentication issue

[jbarney]

I'm starting to get customers using Outlook 2007 and when they try to authenticate to send mail they get: "This client does not support any of the authentication methods used by this server" (or something very similar). Does anyone have any idea what it's looking for and/or what changes are needed in PSA to allow it to authenticate for SMTP?

 

[jbarney]

Nobody has encountered any issues with this?

 

[shalako]

I'm having this problem today. Client unable to connect to SMTP server. Incoming (IMAP) is fine. I tested his account here at the office (Outlook 2007) and fixed by unchecking "SMTP server requires authentication."

This causes me some concern. In Plesk, my server is definitely configured to require POP and SMTP authentication.

Regardless, we tried unchecking authentication and the client is still unable to connect to outgoing (SMTP) server with both Apple Mail and MS Entourage (client uses OS X). They have no problem with their .Mac and Comcast accounts (configured in Apple Mail). Further, client is able to connect to SMTP from home (via cat5 and router), but not via wireless elsewhere. But .Mac and Comcast accounts work fine everywhere.

So two, possibly related questions:
1. Why does Outlook 2007 require unchecking SMTP authentication to connect?
2. Why can client connect at home, but not elsewhere?

Thoughts?

 

[faris]

This issue applies accross Outlook 2007 on Vista and XP, and also affects Plesk 7.5x

Basically there is a bug (or there has been a change in the way outlook works) the prevents 2007 from doing authenticated smtp with the version of qmail installed (the issue is not Plesk specifically - if you do a google serach you'll find a few moans about various isps including COX but no solutions, and I doubt COX is using Plesk for all its emails?).

The work-around is to ask clients to put a tick on the receive before sending tick box in Outlook, and to enable pop-before relay in Plesk. Not all of us are happy with this workaround obviously.

What is interesting is that nothing appears in the maillog when trying to send (when getting the errors).

This is very very bad.

I believe this is an issue Microsoft will have to deal with, and not Plesk, given that all other clients work fine with qmail (with the exception of Entourage for the Mac, but I understand that's an Entourage bug).

Incidentally all clients affected have been using Norton AV, and all my tests have been done with Norton Internet Security installed so I suppose there is a small chance the issue is related to that and not outlook 2007. I doubt it though.

Faris.

 

[faris]

Hmm... something worrying is going on. Or maybe not.

I've just tried Outlook 2007 on a second server I have, running Plesk 7.5 (I know this is a plesk 8 thread but never mind - the same thing applies). The difference with that one is that I've installed the qgreylist patch, which amongst other things adds several updates to the qmail code apart from the greylisting stuff.

Outlook 2007 works perfectly on that one with authentication.

So unless I've missed something there is definitely an incompatibility between the stock version of qmail as installed by Plesk and Outlook 2007.

Faris.

 

[faris]

Soome additional info:

On a system running Vista and Outlook 2007, and Macafee AV, I found that I experienced the same issue. So it is not related to Norton.

However, get this: On accounts imported via the Vista Transfer Files and Settings option there were no problems at all. Authentication worked! But adding a new account resulted in the same issues as have been reported here.

This is defintiely an Outloook 2007 issue more than anything else. I don't know what it is doing, but it isn't doing it quite right.

Faris.

 

[futureweb]

we had this issue and per microsoft this settings at vista would help to prevent this issue:

at console as admin type:
netsh interface tcp set global autotuninglevel=disable


patrick

 

[faris]

I'm not sure this is the solution, but thanks for posting it - I didn't know about it.

You see the problem is with Outlook 2007, even under Windows XP. The problem that this solution fixes is a separate one, and Vista specific, though I have no doubt it will help a lot of Vista users.

 

[futureweb]

yes you are right, it was vista specific, not applicable for xp.

 

[jbarney]

I'm not able to replicate the email issue on Vista or XP using any other mail client besides Outlook 2007. When you turn SMTP authentication off in Outlook 2007 the messages do go through and I believe it is correctly authenticating. Wierd issue.

 

[phatPhrog]

POP SMTP and Outlook

I replaced the POP/SMTP server in Outlook from mail.domain.com to the root server IP and the problem was resolved.

Not ideal, but my Outlook and that of our clients are able to send/receive without problems.

??

 

[Galactic Zero]

Hum.. I have a client that can send and receive just fine from all but one network.. His business network with Verizon, he gets this error however if he uses his comcast network no issues. He's running outlook 2007 on XP Pro.

 

[cwickham]

We are not having issues with sending because we use the pop before send. We are having issues with customers not being able to receive when they use outlook 2007.

Its very slow or it just times out over and over. If they move to express it works fine. I can't figure out what's jacking with it but todays' call was well you know my Bell south mail works just yours doesnt and the customer is leaving.

So if anyone has any ideas. I would be very appreciative.

 

[DaveNET@]

I'm having customers now that can't send, well I have one. So I fired up Outlook 2007 to try and work through this. I set up a test account on my Plesk 8.2 Linux server. Well, guess what, I can't send no matter what I do. I have both SMTP-auth enabled and login before sending too.

Previously before upgrading to this new version of Plesk, I had SMTP auth disabled for some reason. I really do not wish to go there again, so I need to make this work.

I've tried using the IP address of the server instead of the domain. So far everything fails and the error continues. Anyone found a solution?

David

 

[faris]

It will work if you take the tick out of the "my smtp server requires authentication" tick box in Outlook 2007. If it isn't working then something else is happening and probably not related to this issue.

The error you'd get if is was authentication related would be words to the effect of outlook doesn't support any of the authentication methods used by the server....or something along those lines. If your error message is something else then it isn't the authentication "bug" in Outlook that's the problem.

Check that no other boxes have been accidentally ticked in the Advanced tab in Outlook (like use SSL).

ALSO, make sure all your ISP's have not started to block access to external mail servers on port 25. You may need to switch to using port 587. Search the forums for port 587 for a very very easy way of implementing this.

Faris.

 

[DaveNET@]

Hi,

I was getting the error about not having any authentication methods compatible with the server.

Well, tonight it works. I used the option in the 'Outgoing Server' tab at the bottom, 'Log on to incoming mail server before sending mail'.

I can't explain it but I will have my customer try it and see if it works for her too.

David

 

[reliablepenguin]

This problem is caused by Qmail on recent versions of plesk failing to include an AUTH statement in response to EHLO commands.

From older servers:

> telnet rs04.reliablepenguin.com 25
Trying 72.32.68.171...
Connected to rs04.reliablepenguin.com.
Escape character is '^]'.
220 rs04.reliablepenguin.com ESMTP
ehlo
250-rs04.reliablepenguin.com
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250-PIPELINING
250 8BITMIME

From newer servers:

> telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 xxx.mydomain.com ESMTP
ehlo
250-xxx.mydomains.com
250-STARTTLS
250-PIPELINING
250 8BITMIME

The lack of the AUTH lines is causing some mail clients to not attempt SMTP AUTH because they think the server does not support it.

Don't have the solution yet to this problem. Has anybody solved it already?

 

[ncc@sgcom.com.s]

Plesk has not done a good job with the Qmail on Plesk 8 and above

Thanks to reliablepenguin. We manage to pin-point the actual error on Qmail.

We managed to find how we can reproduce the error:

1) On Plesk control panel, Go to server-> Mail
2) Select “Authorization is required:†with:
• “POP3 lock time†enabled
• “SMTP†enabled

Now do a telnet to your qmail server running on Plesk 8.X

C:\Documents and Settings\Administrator>telnet mail.mydomain.com 25

220 hostname.mydomain.com ESMTP
ehlo
250-hostname.mydomain.com
250-STARTTLS
250-PIPELINING
250 8BITMIME
quit
221 hostname.mydomain.com

In this way, Outlook 2007 will not work if you have chosen:

1) Enable "My outgoing server (SMTP) requires authentication
2) Select "Use same settings as my incoming mail server"

The reason is because Outlook will try to look for "SMTP AUTH" options in Qmail which is missing in Plesk 8.X

There are 2 workarounds:

1) Use Faris' method,

1) Enable "My outgoing server (SMTP) requires authentication
2) Select "Log on to incoming mail server before sending mail"

2) Disable Plesk "POP3 lock time"

1) On Plesk control panel, Go to server-> Mail
2) Select “Authorization is required:†with:
• “POP3 lock time†disabled
• “SMTP†enabled

If you use method 2, you will realise that when you telnet into your machine:

C:\Documents and Settings\Administrator>telnet mail.mydomain.com 25

220 hostname.mydomain.com ESMTP
ehlo
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250-PIPELINING
250 8BITMIME
quit
221 hostname.mydomain.com

You have 2 additional lines missing with "POP3 lock time" disabled.

This is the reason why we are all facing the problem with Outlook 2007 because Plesk has removed the lines.

Any help from Plesk, now that we have provide you the pin to the problem?

Thanks

Ng Cher Choon

 

[reliablepenguin]

Correct

I agree with ncc@sgcom.com.s's post. The problem only happens if the user has been previously authenticated via "POP before SMTP" in which case qmail does not advertise SMTP AUTH. Some email clients don't have a problem (such as Thunderbird) which don't seem to pay attention to the server's advertisement. Other clients like Apple Mail fail frequently.

The two workarounds mentioned are the only solutions that we've found. We're setting up new servers without POP before SMTP to avoid the problem.

Thanks,
Lee

 

[faris]

Ah. This is interesting.

So, to summarise, if you disable pop-before-relay in Plesk, conventional smtp auth works correctly for Outlook (and Mac Mail and Entourage which also exhibit the behaviour).

Interesting.

What does Plesk do to smtp_psa when you remove pop-before-relay? Does it just remove /var/qmail/bin/relaylock from the server_args line?

If so, can someone try this please?
1) Create a second smtp instance on port 587 (by copying smtp_psa to smtp_psa587 and changing service smtp to service submission at the top)
2) Remove "/var/qmail/bin/relaylock" from the smtp_psa (for the normal port 25).
3) Restart xinetd

If and only if simply removing /var/qmail/bin/relaylock disables pop-before-relay and allows normal smtp-auth to work correctly then in theory, you can allow customers who MUST have pop-before-relay on one port and customers who use Outlook 2007 on another (as long as they change their smtp port).

You could of course have a third instance on some other port if need be (Most of our customers are on port 587 already since a lot of ISPs are blocking port 25).

Like I say, all this assumes that qmail works "correctly" (though without pop-before-relay) simply by removing /var/qmail/bin/relaylock -- if this isn't the case then what I'm suggesting won't work at all and is utterly useless and complete nonsense.

I'm just assuming that /var/qmail/bin/relaylock is the "pop-before-relay" addition while /var/qmail/bin/smtp_auth is the normal smtp-auth.

Faris.

Note: All this is important because "receive before sending" is not an option for Mac Mail and Entourage customers -- there is no such auth option as far as I remember. So while my original solution works for Outlook 2007 it does not work for the Mac clients.