SMTP authentication failing

Hi there,

I am using mail via postfix and horde, with users synced to an MS AD server. Using mail through horde works fine, and I have set the server up to relay through sendgrid which is also working well.

The problem I have is that no users can authenticate directly to the server via SMTP to send a mail (using port 587). The TLS handshake works ok, but it always returns authentication failed. I have tried using the email address and login as the username, but nothing seems to work.

I need this to be able to have service accounts forwarding emails (for RAID failures, IDS notifications, etc). It doesnt make sense that horde worked out of the box yet SMTP through postfix doesnt.

Help pls? Am running 4.4-4 errata499 (Blumenthal)


some questions:

  • Did you install the mailserver app?
  • Is the users email set in the primary email field (first tab in the users UMC module)? The setting on the contact tab is not relevant.
  • What is written to the mail log (/var/log/mail.log) when you try to login?

Daniel Tröder

Hi troeder,

  1. Yes, I have installed the mailserver app.
  2. I am using the primary email address as the username
  3. When using port 587, no errors seem to show up. It just shows the connection dropping.

I tried using swaks and ended up being able to authenticate using tls and plain authentication, so I now suspect that the servers arent implementing tls properly. When I turn off the tls switch and try plain authentication it errors out saying that plain auth without TLS doesnt work, which is expected.

I then tried to use SMTPS on port 465 since both servers also had options to use that. However, when using this I get different errors from each server trying to authenticate, as per the below:-

Apr 6 22:24:53 ucs postfix/smtpd[22073]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:…/ssl/record/rec_layer_s3.c:1407:SSL alert number 48:

Apr 6 22:25:46 ucs postfix/smtpd[22073]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:…/ssl/record/rec_layer_s3.c:1407:SSL alert number 46:

I have tried to import my own ssl certificates and pointed postfix towards a different CA chain, certificate and key file within the ucs variable settings, but the errors dont change.

I am at the point where I would enable plain auth with no tls, and limit it to specific server IPs. Port 587 isnt exposed externally so its not “that much” of a security risk.

That is how it’s supposed to be used with UCS: PLAIN passwords transferred using TLS.
See here:
PLAIN is not unsafe, as it’s tunneled through TLS.

Daniel Tröder

Thanks Daniel.

I know that is expected, but essentially I am looking for more flexibility to either force plain text without tls (and use IP filtering) or enable SMTPS on port 465 and fix the errors that are appearing in the logs above.

Do you have any source of reference for that? When I looked up the error elsewhere it looks like there is supposed to be an option to turn off SSL client verification, but I couldnt find the appropriate variable within UCS config.


Well… this is insecure, as passwords will be readable on the wire! but you could turn off encryption enforcement on the submission port with

ucr set mail/postfix/mastercf/options/submission/smtpd_enforce_tls=no
service postfix restart

It will allow clients to choose to not use TLS when receiving STARTTLS (see
I have never tried it out, as that is insecure, but it should work.
To get rid of the certificate errors, inport the UCS CA into your client. It can be obtained at http://YOUR.MACHINE/ucs-root-ca.crt

Daniel Tröder

Thanks again Daniel.

I had already tried the mail/postfix/mastercf/options/submission/smtpd_enforce_tls=no variable but it didnt seem to make any difference. I sill kept getting plain auth failed, starttls failed errors in the clients.

I also had imported the UCS CA onto the machine in question, but that didnt seem to help the certificate errors. I also recreated all the certificates for postfix, imported the certs and the CA from another machine and created certificates on each client machine using the same CA, but that didnt work either.

strange thing is, it all works when I use swaks from the command line on the same machine. something within the application itself must be sending or interpreting the tls options wrongly, or at least something unexpected. they both work with google’s smtp servers on port 587 though, so I cant work out what its doing differently.

right now I am using IP based relay permission from servers within the LAN (for lack of an alternative working option), but I dont like it. plain auth without tls is unsecured, but if its only within my LAN on a specific VLAN that isnt used by normal PCs I prefer that to an open IP based relay.