Hello, i#m using Liquidfiles with a external mail relay. Problem is that it seems Liquidfiles is not sending those eMails cause it got a certificate name-match error detected with the external mail server. That's correct and there is a reason behind that which i could not change, so i need to DISABLE relay mail servers certificate check. Error message is "Server certificate not verified" How can i do that?
By default the LF server has configured the "Email Delivery Security Level = May Opportunistic TLS" in "Admin > Configuration > Email" settings. When this option is set then LF is trying to negotiate a compatible TLS/SSL connection with a remote server but will not close the connection if the certificate can't be verified. If any compatible TLS/SSL protocol can't be negotiated it drops to the plain text and emails are sent. If you have this option enabled and the LF server still can't rely the emails the problem will be something else, i.e. in authentication. More details you will see then in the Mail Queue (in the details of emails in the queue which could not be relayed) or in the further email debug logs either on the LF server in "Admin > System Log" or better on the SMTP relay server.
Still got problems. Even the mail got send, it ewnds still in Spam. And the login is correct. The Admin of that MS365 service tells me it's the fault of Liquidfiles. 0B95710185F7: to=<AdminMails@mycomp.com>, relay=10.7.70.30[10.7.70.30]:25, delay=6.9, delays=0.12/0.16/6.6/0, dsn=4.7.3, status=deferred (SASL authentication failed; server 10.7.70.30[10.7.70.30] said: 535 5.7.3 Authentication unsuccessful)
if i send a test email via SMTPDiagPro, i got no SALS authentication error, even using the same credentials.
The Authentication unsuccessful error is returned by a remote email server when not only the login and password are wrong but also when some other authentication requirements defined by the particular email server/service for the account are not fulfilled. Some time ago 365 service automatically enforced OAuth method which is not compatible with most of email servers and also devices like copiers and scanners. If this is also your case you will need to manually disable it for the client submission account which is used for relaying with your LF appliance. If the basic SMTP authentication can't be re-enabled and OAuth disabled in your 365 profile then you will need to switch to some another SMTP relay service. For more information about this topic please read this man page: https://man.liquidfiles.com/email/outgoing_smtp_office365.html
Well, we are not sending to O365, but to a "normal" on-premise smtp-host. When sending test-emails via a smtp-test tool like SMTPDiagPro, i got no problem sending that eMails. Same with some other sendwers, all relay without problem directly to that smtp-server, only liquidfiles did not. I have now tested configuring that smtp-server via a DNS-A record instead using the direct IP. To archive that, i have created a entry in the hosts-file of liquidsfiles pointing to that smtp-relay. Now i got a different error message: Code: 5D299100131C: to=<AdminMails@iteanova.com>, relay=none, delay=0.23, delays=0.13/0.06/0/0.04, dsn=4.3.5, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=smtpauth.in.msg.de type=A: Host found but no data record of requested type) Seems like TLS on Liquidfiles requires some dedicated MX-record or something? Which is not provided in that type of setup. Could you tell me something about that?
That latest error is not related to TLS. It's another issue, a DNS misconfiguration. Postfix in LF appliance also does not need necessarily the MX record to be able relay that emails. If MX is not found then it will be tried A and AAAA record instead. Note: I think when you added the relay host to the /etc/hosts file Postfix is designed to to looks up the SMTP hosts via the configured DNS resolver anyway. When it can't get the IP of the SMTP server that error is displayed. But generally for the troubleshooting of the initial email relay issue you can simply use the private IP address of the SMTP server in the email configuration. What do mean with the "normal on-premisse smtp-host" in your infrastructure, MsExchange?