BUG REPORT: SMTP Authentication is not working

Simon,

can you post your SMTP settings (only the relevant) you had in 5.009 when SMTP auth worked for you? What exactly did change in the behaviour?

Enabling these two SSL options in OE had to be done in all versions (including V4) - it's not new in 5.010.

~marcel

In version 4.022 I had all users authenticating via Outlook through the ASL SMTP proxy.

I had assigned a single user for authentication.
(mmsmtp/xxxxx)

In Outlook, my settings were purely to use a defined username and password to authenticate to the SMTP proxy.

(For our local LAN users, I simply added my LAN to allowed networks).

On Friday I upgraded to version 5.010 and imported existing config in.

At home on saturday I sent a number of emails to the office, worked fine.  Next I sent an email to an outside domain and got a relay denied message from ASL.

After much gnashing of teeth and a phone call from the boss who also could not now send emails to outside addresses I fixed the problem by setting the SMTP server to authenticate via SSL.

This works, tho I was warned I was using an unverifiable certificate.
So I sent a message to all staff asking them to tick the checkbox for SSL.

Come monday I get a number of office staff who had applied this fix to their outlook now unable to send emails from INSIDE the office network, even though:

A) They were in an allowed network
B) They had told Outlook to use SSL for SMTP auth.

I verified this behaviour myself and told them to remove the SSL requirement whilst in the office.  All OK.

Went back to my workstation and was unable to ping/webmin/ssh to ASL 5.010 from my workstation.  Went to another machine on the LAN and it worked fine from there.

At this point I pulled the plug on v5 and stuck the v4 box I had wisely kept back onto the system, all OK again.

Now, the systems that seemed to work with SSL were Outlook 2003.  Outlook 2000 seemed to have SSL auth issues.

It seems behaviour between the different versions changes.  (As it does for Outlook Express, which by the way, worked with SSL).

I would *MUCH* prefer to use plain unencrypted authentication for this.  Or at the very least, have SSL authentication work consistantly across versions.

I sent a support email with some screenshots of settings to support@astaro.com on Saturday, perhaps you can have a look at these?  I'd repost but do not have access to the screenshots from here.

Also, I've NEVER had a problem using Outlook Express WITHOUT SSL from home before.

My home network is NOT in ASL's SMTP allowed networks, but I can send mail to outside domains as long as I authenticate with the mmsmtp/xxxx account. (without SSL)

I just double checked settings now and the above statement is definately true.

Simplest solution:
Allow unencrypted authentication.
Allow encrypted auth as an autodetect function or a button to turn it on.

Using Outlook Express 6.00.3790 I just sent an email through SMTP authentication on ASL 4.022 *without* having SSL turned on.  Just normal unencrypted.

It also works with SSL encryption turned ON.

SMTP auth working without TLS was a bug in 4.0xx that was never fixed to stay backwards-compatible. AUTH was never intended to work over a unencrypted connection.

I fixed this for 5.0xx. Now I'm aware that this does create some problems when upgrading from 4.0xx [:)]cators. Then stop and start the proxy.

Thanks for the explanation Tom.

However, I'd prefer not to edit exim.conf, especially when up2dates are coming out so often, I'd be editting it quite often I think.
Could we have a button for this in SMTP proxy?

Also, it does not explain why SSL authentication doesn't work from inside the firewall with Outlook 2000.

It still appears to me as if different email clients act differently depending on the authentication used.  I need a consistent setup for our corporate environment.

[ QUOTE ]
SMTP auth working without TLS was a bug in 4.0xx that was never fixed to stay backwards-compatible. AUTH was never intended to work over a unencrypted connection.
 

[/ QUOTE ]

I'm really not a mail protocol expert, but I'm seeing the same thing where a Pocket PC client could relay in 4.xx but can't under 5.xx with the same configuration.    

Are you saying that it's because 5.xx now enforces TLS encryption, and for whatever reason, some clients (like the Pocket PC) aren't able to properly negotiate the TLS encryption and that's why we get the "Cannot Relay" error message?

I will try some testing later tommorow with the fix you mentioned to see if that works.

Here's a trick that may help resolve this.  Many of us who have witnessed SMTP proxy problems imported a configuration from version 4.  Try shutting down the SMTP proxy and then restarting it (using the switch in WebAdmin).  Rebooting the firewall will NOT achieve the same results.  Apparently, this causes SMTP configuration data to be rewritten to the database, fixing what may be a glitch in the v4 import process.  We tried it here, and it seems to have resolved the SMTP authentication troubles.  Of course, you'll still have to enable SMTP authentication and SSL encryption on the client side.  Hope this helps.

I have discovered the problem that was causing SMTP authentication to fail.

The culprit is Symantec Internet Security product.  This software intercepts outgoing mails and somehow causes the connection to fail.

Outlook 2003 gives the error:
Task 'mail.micromine.com.au - Sending' reported error (0x800CCC7D) : 'Your outgoing (SMTP) server does not support SSL-secured connections. If SSL-secured connections have worked in the past, contact your server administrator or Internet service provider (ISP).'

Uninstalling this software and installing Symantec Antivirus appears to fix the issue.
I have not tried just disabling the mail checking in the Symantec Internet Security product, (well I did disable it and it still didn't work, but I didn't reboot the client to test completely, you may get more mileage than I did.)

Symantec Internet Security comes preinstalled on many machines so please beware.

Apologies for ranting to much about this issue, but it was driving me crazy.

I've just had this query from a customer and found this thread. I am a little confused: why is it not possible to use authentication without encryption? The two are very different things for different purposes. If a  system administrator is happy sending passwords in the clear, Astaro should not prevent them from doing so. You could equally say that PPTP should not be allowed now that L2TP is available, but that would not be helpful for people happy with that level of security.

[ QUOTE ]
I've just had this query from a customer and found this thread. I am a little confused: why is it not possible to used authentication without encryption? 

[/ QUOTE ]

It certainly is possible to do this.  All you need is the IP address (or address block) of the remote site, then you put that network (or host address, as the case may be) in the allowed networks area under "Outgoing Mail" in the SMTP Proxy settings.  No encryption or authentication will then be required in order to use the SMTP Proxy.  HOWEVER, if a user is roaming (they don't have a fixed IP), then you will have to tell them to use SMTP Authentication and SSL encryption.  Of course, you could just put "Any" in the allowed networks area of your SMTP proxy, but I'd bet that within a few hours your firewall would be in heavy use by spammers, because you'd become an open relay.