SMTP: "HELO can't be [127.0.0.1]"

[BilliAlpha]

Checklist

• [X] I have used the search function to see if someone else has already submitted the same bug report.
• [X] I will describe the problem with as much detail as possible.

App version

6.202

Where did you get the app from?

Google Play

Android version

11

Device model

No response

Steps to reproduce

Some mail providers seem to forbid SMTP connections when the HELO hostname is 127.0.0.1. I found the history to this change originating in #2793 (changed in PR #3798). The question came back in issue #4428.

I have read theses issues and understand that it has been changed so for privacy reasons, and agree that sending the actual real IP or hostname would be detrimental to privacy. However, I believe we can try to find another value that won't be blocked by mail providers. This could potentially be an opt-in option in each SMTP server settings. I'd be ready to make a PR if that is something you would be willing to accept. We could have a select option with values like 127.0.0.1, 192.168.0.1, 10.0.0.1 and a final value of "Send actual IP address (not recommended)". This way the user still is in control of what is sent and can still use the app even if the mail provider denies privacy conserving values (most providers won't be willing to change their server configuration on user requests).

Expected behavior

Being able to send mail to servers denying the 127.0.0.1 HELO hostname

Actual behavior

Connection to the SMTP server rejected due to a forbidden value of 127.0.0.1 in the HELO message

Logs

No response

[williamdes]

No update on this subject?

[mutaunt]

Yes disappointing no one is addressing this. My hosting service is one that does not allow a local host address for HELO.

Seeing an old forum post where someone was insisting K9 had it right and the rest of the world needed to change got me thinking and reading RFCs (aaahhhrrgghh). As far as I can see RFC 5321 from 2008 is still current. Quoting part 4.1.3.-Address Literals: "Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier, a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2]..."

127.0.0.1 is a local host address, not the address of the host. SMTP servers that reject this have the right to do so. But this is where it gets tricky.

Thunderbird plays by the book, it uses the IP4 address of the client. Yes that is what the RFC wanted but who wants an IP address off their local LAN subnet sent to the world, it's meaningless, and a minor security weakness. To its credit, T-bird has an advanced config setting where you can set HELO whatever you want (and I have).

My suggestion is that K9 should follow T-bird, use the local IP4 address but provide a setting to change it.

But if you are going to use a non-compliant value then either a fixed fictitious private address, e.g. 192.168.1.254, or any resolvable fqdn like k9mail.app would work better than the local host address. Given where Google/Yahoo are going with SPF and DKIM there is also a risk they too will start blocking the local host address.

The old RFC is really the problem here as in a NAT world this parameter is pointless.

[njeyaakili]

rfc 5321 is in reference to smtp -- machine-to-machine/port 25 mail transfer. a more appropriate rfc for discussion of mail submission standards is 6409 - "message submission for mail". as documented, the MTA (message transfer agent) is free to refuse a message for any number of reasons (and not liking the ipnumber on the HELO/EHLO, while not explicitly mentioned, could be one), however, rejecting or bouncing is always referenced as the subsequent handling that should take place. dropping the message on the floor/into the trash (or explicitly sending it to /dev/null as one provider does) is not a documented option in the specification.

[mutaunt]

Hi njeyaakili.

You are correct, 6409 does say how an MSA should handle message rejection, and I bet you are correct that many fail to do this as described too!

But that isn't the subject of this bug. This bug is about how k9 incorrectly populates the HELO command and the need to fix that.

6409 is based on 5321, with bits added on. Quote 3.1 "The protocol used is ESMTP [SMTP-MTA], with additional restrictions or allowances as specified here." "SMTP-MTA" is a normative reference to RFC 5321 (see references section 12.1). As HELO format is not one of these restrictions/allowances it remains as defined by 5321.

As a comparison I had a look at how FairEmail populates HELO. It uses an fqdn dummy.faircode.eu, which if you browse to it https://dummy.faircode.eu gets you a brief description of why it is used for HELO and how FairEmail has settings to modify it.
Strictly speaking this is not 5321 compliant either, not identifying the host, but it gets the job done better than a local host IP.