HELO "localhost" rejected (smtp and submission port)

[ctheune]

• Operating System (Linux/Mac/Windows/iOS/Android): ios
• Delta Chat Version: 1.12.0
• Expected behavior: can send messages
• Actual behavior: can't send message
• Steps to reproduce the problem:
• Screenshots:

• Logs:

[gerryfrancis]

Could be related to chatmail/async-smtp#27 .

[ctheune]

Yeah, that's what @hpk42 already suspected.

[Hocuri]

@ctheune what's your email provider?
Can you receive messages? (you said you can't send)
Did this start to happen when you updated?

[ctheune]

I didn't use DeltaChat on iOS for a while because I messed up my accounts in between, but I know it worked previously.

The server is one of our own (somewhat aged) mailservers (running for other customers as well) which is a Postfix + Cyrus.

Incoming email is fine, this is purely an SMTP HELO issue.

[gerryfrancis]

There was an issue reported on support.delta.chat, maybe it helps:

https://support.delta.chat/t/smtp-helo-command-rejected-need-fully-qualified-hostname-solved/817

[ctheune]

Interesting. I'll check whether authentication succeeds.

[Hocuri]

@gerryfrancis thanks for the link! This is a little surprising because this was reported in February, long before chatmail/async-smtp#27.

@ctheune do you know what the hostname of your device is? Because, the hostname often is just some random string that the user or the device vendor chose.

Maybe your server is just surprised by the string "localhost" because it thinks that the connection comes from the server itself. It would be interesting to see if the connection succeeds when the hostname is just some random string, but I do not have any idea how to test this.

Or maybe there is an easy possibility to get me a test account on your mail server? Then I test this (and more) by myself.

[link2xt]

This is a little surprising because this was reported in February

This was on C core probably.

[Hocuri]

@ctheune

• maybe there is an easy possibility to get me a test account on your mail server?
• do you know what the hostname of your device is? Because, the hostname often is just some random string that the user or the device vendor chose.

[link2xt]

A report on the forum: https://support.delta.chat/t/send-a-fully-qualified-ehlo-host/1178

[link2xt]

According to https://tools.ietf.org/html/rfc5321#section-4.1.1.1 if FQDN is not available (which is the case for Delta Chat, otherwise it may just send mail directly to recipient server), an address literal SHOULD be sent. Looks like it is what Thunderbird does: https://support.mozilla.org/en-US/questions/989683

Maybe sending 127.0.0.1 instead of localhost helps? I do not want to send interface address, because it will introduce the same problem of leaking IP address through VPN that WebRTC and BitTorrent protocols have: if user is not behind the NAT, but uses VPN, this will leak user location to the server. At least sending 127.0.0.1 does not seem to violate RFC, which states an FQDN or address literal should be sent, while not fully qualified domains are specifically not allowed.

Edit: I just tried, smtp.yandex.ru rejects 127.0.0.1, but accepts 127.0.0.2.

[ctheune]

I'd be happy to give you a demo account. I just need to figure out a domain to give you ...

[link2xt]

@jocutajar You said on the forum that some clients send domain part of the address, such as for address user@example.com they send example.com? Which clients do it? This also seems to be against the standard, because domain name is supposed to identify the user, and the server clearly knows that it is example.com, not the client. But if some other MUA does this and it works, we can try it of course.

[ctheune]

@Hocuri can you DM me? I can give you access to the mailserver in question.

[link2xt]

@ctheune
Could you try connecting to your server with openssl s_client -connect <your.server>:587 -starttls smtp and sending:

• EHLO localhost
• EHLO 127.0.0.1
• EHLO <your.server>
• EHLO mail.example.com (this is what s_client sends in unencrypted connection)
  Same for ncat --crlf your.server 587 to test EHLO outside encrypted connection.

There is no need to login to the server to test these things, as EHLO is sent before authentication.