Own SMTP Server - Error: A call to SSPI failed, see inner exception

Integrations
1

Hi, I recently redirected my mailserver through a different firewall (still same server, and still on same IP, etc.)

Other emails are working fine, but quickfile this morning emailed me with an error:

Error: A call to SSPI failed, see inner exception. --> The client and server cannot communicate, because they do not possess a common algorithm

I’ve tried re-configuring it with a different server, but now the page brings up another error:

Error Message: A call to SSPI failed, see inner exception.
More Details: The token supplied to the function is invalid

Not sure what’s going on with it - is it a problem Quickfile side, or mine?

My email server logs show these, which i assume is related to QuickFile:

Mar 11 08:52:25 postfix/smtpd[17062]: connect from unknown[5.2.23.6]
Mar 11 08:52:25 postfix/smtpd[17064]: warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer
Mar 11 08:52:25 postfix/smtpd[17064]: SSL_accept error from unknown[5.2.23.6]: -1
Mar 11 08:52:25 postfix/smtpd[17064]: lost connection after STARTTLS from unknown[5.2.23.6]
Mar 11 08:52:25 postfix/smtpd[17064]: disconnect from unknown[5.2.23.6]

As I say, the actual server which was being contacted remains the same, just the firewall it goes through has changed, and it’s not doing anything special.

2

This looks like a TLS Protocol issue, i.e. we are not able to negotiate a mutual TLS protocol version. Are you able to determine from your email service provider which TLS versions are supported? We haven’t made any changes on our side.

3

Hi Glenn, thanks for getting back to me.

This is quite an old server, and looks to only support TLS1.0.

Testing connection gave:

SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA

But i did try a different server before and got the invalid token message… i’ll try the other server again.

Thanks

4

Trying my other server again, even by ip address, results in:

It looks like there was a problem reaching your SMTP service
Error Message A call to SSPI failed, see inner exception.
More Details The token supplied to the function is invalid

5

Hi @Helpquick

Do you know what version of TLS this server is using?

6

By the way, the alternative server is able to accept TLSv1.2

7

Emails don’t get sent out every day, so looking at my email logs, it seemed ok on 5th March.

Logs for that were:

Mar 5 11:32:01 postfix/smtpd[4733]: setting up TLS connection from unknown[5.2.23.6]
Mar 5 11:32:01 postfix/smtpd[4733]: Anonymous TLS connection established from unknown[5.2.23.6]: TLSv1 with cipher AES256-SHA (256/256 bits)

So TLSv1 was working ok on 5th March

You haven’t disabled TLSv1 between 5th March and today?

I’ll try and increase verbosity of the logging on my server, see if that sheds any more light on it.

8

You say you changed firewalls though in the meantime, when did that get changed over?

9

Last night, which is why it seems too much of a coincidence to me…

Rules are exactly the same between firewalls, NAT is used from external to internal IP.

NAT is standard port forwarding, no SSL inspection or anything fancy like that.

Double checked all routing is correct.

Other emails are flowing in as expected, my own tests work from external to internal as expected.

Only thing not working (so far) is Quickfile.

10

Verbose logging:

Mar 11 11:59:59 postfix/smtpd[21374]: initializing the server-side TLS engine
Mar 11 11:59:59 postfix/smtpd[21374]: connect from unknown[52.138.170.15]
Mar 11 12:00:00 postfix/smtpd[21374]: setting up TLS connection from unknown[52.138.170.15]
Mar 11 12:00:00 postfix/smtpd[21374]: unknown[52.138.170.15]: TLS cipher list “ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH”
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:before/accept initialization
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:SSLv3 read client hello B
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:SSLv3 write server hello A
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:SSLv3 write certificate A
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:SSLv3 write server done A
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept:SSLv3 flush data
Mar 11 12:00:00 postfix/smtpd[21374]: warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer
Mar 11 12:00:00 postfix/smtpd[21374]: SSL_accept error from unknown[52.138.170.15]: -1
Mar 11 12:00:00 postfix/smtpd[21374]: lost connection after STARTTLS from unknown[52.138.170.15]
Mar 11 12:00:00 postfix/smtpd[21374]: disconnect from unknown[52.138.170.15]

OK, lets forget about the old server for now…

I deleted the SMTP settings on Quickfile, and entered details for my new mail server (it supports TLSv1.2).

But i get the error:

11

Ok, it seems my new mail checker (mailcleaner) is using a self-signed cert which uses an MD5 signature :frowning:

That’ll be why QuickFile is producing the error “The token supplied to the function is invalid.” (Thanks google)

Guess my new task is to replace the (smtp) SSL cert on mailcleaner install with a better one.

12

So, I generated a new self-signed certificate for SMTP, with Signature Algorithm: sha256WithRSAEncryption (most servers don’t care that it’s self-signed)

However, now QuickFile gives a different error: The remote certificate is invalid according to the validation procedure.

So from that, i can only assume QuickFile requires a fully trusted certificate, and the hostname must match the one in the certificate.

Next step = Lets Encrypt cert for it. :crossed_fingers:

13

Ok, Eventually got it working…

I gave up on the SSL negotiation problems as that server is so old and will be decommissioned shortly anyway.

For reference, QuickFile DO REQUIRE a fully valid TRUSTED certificate, using the same hostname as the one you specify in the SMTP config as the subject name of the Certificate.

I created a new certificate using LetsEncrypt for this, and it works fine.

Problem being is that the certificate on Mailcleaner is stored in the database by the looks of it, so getting the auto-renewed cert applied is going to take a bit of work.

Working for now, but it would have been a lot easier if QuickFile would accept untrusted or self-signed certificate for SMTP servers.

14

In QF’s defence, with the ease of getting SSL certificates (and now for free from letsencrypt), no-one should ever be accepting self-signed certificates any more.

I’d also recommend, as you’re running your own mail server, in setting up SPF, DKIM and DMARC - if you haven’t already done so - to reduce spam and the risk of your own domain being spoofed.

15

Yes, I fully agree, and yes I run my own server, already have SPF, DKIM and DMAC setup - hence why i want to send QF emails via my own servers.

Luckily, i’m a techie, and know how to set this sort of stuff up, but for joe-average tiny business who has his own SBS server setup, and wants to use that for mail routing, it’d be a nightmare.

I’m not knocking QF at all, I’ve been using it for a very long time, and have always been appreciative of the service, and speed at which Glenn & co. respond and fix things.

I’ve made suggestions in the past, and seen them implemented :+1:

Maybe we could just have a tickbox on the SMTP settings page that says “Ignore certificate validation errors”, it might make things easier for some people.

16

The tickbox could be a good idea - but perhaps more a temporary debug option so that you can eliminate SSL from being the cause of any error. It could reset back to SSL by default after 24 hours.

And I agree - as a techie also, it can be difficult to set up SSL on many applications - the documentation for most software, even to a techie, is woeful - patchy, incomplete, non-existent or just downright wrong. How normal users are supposed to do it I don’t know!