Weird send errors

[UEAB-BL]

Hello!
Im not sure if this is a postal problem or not, but I have a couple recipients with some weird and identical problems.

First: SMTPSessionNotStarted Error
Then turns into: Enter message, ending with "."
Then turns into: ReadTmeout TCPSocket

The reccipients are on different domains with different mx servers. Does anybody know what is happening here?
It looks exactly the same on a couple different recipients.

The 192.168.200.81 address being the local address of my postal server.

[UEAB-BL]

I also checked the logs, and it doesnt really give any more useful information than is already shown.

[willpower232]

Are you sending a message to another SMTP server within your network or from Postal to Postal?

[UEAB-BL]

No, these are external third party mx servers, receiving end is not postal. Judging from the mx records I would say they are all some sort of spam filter. I am in contact with some of the recipients IT departments to try and find what the issue is. But the fact that I get the
"Enter message, ending with "."
makes me think this might be some type of postal error, not handling the SMTP language properly and therefor gets blocked by the other end. Or maybe the other end not handling SMTP language properly.

But yeah, Im no expert.

[UEAB-BL]

I have found that all of these recipients are using the same receiving mail filter, on the same IP addresses.
I have tried using telnet from the postal server to send email manually, AND THAT WORKS!
But not using postal software.
I have also noticed that historyically, sometimes it worked, sometimes it did not, to these recipients. But usually after a few tries, it went through. Now it doesnt at all. But yeah, manually through telnet from postal server works.
But the manual test is without STARTTLS, so maybe theres an issue there?

Can I somehow see the acutal SMTP commands and answers postal get? I tried capturing the traffic in the firewall but after STARTTLS its unreadable.

[willpower232]

It seems that this setting is used for Postal sending any kind of email, both for internal password resets and sending real mail it has been given

postal/doc/config/yaml.yml

Line 169 in fd3c7cc

enable_starttls_auto: true

Presumably if you set it to false then your logs will clear up.

[UEAB-BL]

I tried setting it to false, but its still using STARTTLS when sending outgoing email.

[UEAB-BL]

Im not 100% sure but I believe this is TLS related, and might be a ruby problem, in combination with whatever software is at the receiving end.
If I try to use openssl to connect I believe Im getting the same error. But they are not having any known problems with anyone else. Not that many using postal, maybe?
Seems to be some sort of renegotiating that doesnt work, but not entirely sure.

From testing openssl:

EHLO mail.ueab.se
250-in11g.electric.net Hello mydomain.com [MY_IP]
250-SIZE 268435456
250-LIMITS RCPTMAX=50000
250-8BITMIME
250-PIPELINING
250-PIPECONNECT
250 HELP
MAIL FROM:<[email protected]>
250 OK
RCPT TO:<recipient email address>
RENEGOTIATING
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = electric.net
verify return:1

And then nothing happens. Im guessing the same happens for postal/ruby and it times out because it never gets a 250 OK. But using openssl rarely works well for sending mail so...

This is what Im getting from capturing the traffic.

It could be helpful if someone could try and send a test from their postal server, to see if its a postal thing, which Im starting to think it is.
Is it possible to DM on github? I dont really wanna post their email publicly. Discord maybe? Maybe @willpower232 would be willing?

[UEAB-BL]

This is now almost solved! We did not have port 25 incoming open, due to security, and we didnt really care about bounce mails. Turns out the receiving end would not accept TLS unless port 25 is open on the sending IP. Not sure why. For now, Ive opened port 25 incoming, and thats at least a temporary solution.

EDIT: Does TLS 1.3 require this natively?

[willpower232]

I don't believe it is part of TLS 1.3, it is more likely that it is used as a validation flag to make sure that the sending email server is definitely an email server and not just blasting emails out to the internet

[UEAB-BL]

Yeah that makes sense, I found incoming SMTP traffic coming from other IPs on the same subnet as the mx server, so yeah, probably probe servers doing a check as you say. I ended up only opening port 25 to those specific subnets, so I feel the problem is resolved for now at least.
The only weird thing is that I was able to send email to them without TLS using telnet, so the check apparently only comes into play when the TLS is negotiated. That kinda threw me off.
Thanks for your time Will!

[niels-przybilla]

In our case our Port 25 is open as we accept there messages for the delivery.
I am really without ideas as we have this problem only with on receiver.