K-9: Change HELO greeting

[HeresJonny]

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue

Expected behavior

I would like to suggest to change the current HELO greeting from "127.0.0.1" to something else, maybe the software name/version or the name of the smartphone. Smartphone name would probably require additional permissions to read it. Another option could be to use the LAN IP while connected to a WIFI network and use public IP in other cases.

Actual behavior

Currently, when sending email from the smartphone, K-Mail may identify as "127.0.0.1". This kind of greeting is also used by malicious software like SPAM software. Therefore this kind of HELO is currently being recommended to be blocked on connection by some mail server software like hmailserver, (cf http://www.hmailserver.com/forum/viewtopic.php?f=9&t=34659 ).

Steps to reproduce

1. Send email from K9-Mail to your mail server software
2. Check HELO greeting in logfile
   3.

Environment

K-9 Mail version: 5.703

Android version: 9

Account type (IMAP, POP3, WebDAV/Exchange):
SMTP

Please take some time to retrieve logs and attach them here:

[yoshimo]

You don't want your device name in there and neither your mail client. What is both accepted and generic enough to not reveal anything that can be fingerprinted?

[HeresJonny]

You could always use something like "local.domain". You could also try to read a domain qualifier from the network. When used in LAN, the router will often add a domain qualifier like ".local" or ".fritz.box".

[SorenRR]

RFC's are made for a reason. Rightly ANY HELO/EHLO greeting not being a FQDN or an address-literal should be rejected by the server.

"localhost" or "127.0.0.1" is a clear winner in almost all SPAM/BOT databases, so have fun.

https://tools.ietf.org/html/rfc5321#section-4.1.1.1

[yoshimo]

I am not familiar enough with ALL rfcs so i do not know how to satisfy a both requirements rfc&privacy at the same time. Maybe there is something better that doesn't leak my network internals and device info, therefore i asked.

[SorenRR]

Privacy? You should greet with your FQDN or your address-literal, none of the two contain information that cannot be obtained elsewhere.

If you want privacy, stay off the 'net !

I joined "The Internet" before it was called "The Internet" and I'm still here - and nobody still don't know who I am besides the people I trust ;-)

[HeresJonny]

@SorenRR Are you the same Søren from the hmailserver forum who provides those great scripts? I'm sure you'll agree that on Github we should all work together towards solutions. While your opinion is certainly valid it would be even better if you could help us with suggestions. Thanks :-)

[SorenRR]

One and the same.

Well, my best suggestion is to follow the RFC's to the letter. Someone a lot smarter than any of us wrote them for a reason. ;-)
Also when people question compatibility, you can shut them up by stating RFC compliance.

[cketti]

SMTP (the protocol) is in the unfortunate situation that it is used for two very different use cases. Often the services are referred to as SMTP (MTA to MTA communication) and SUBMISSION (MUA to MSA communication).
K-9 Mail is an email client (MUA) and its communication therefore falls into the second category. In my opinion a well-configured submission server should…

• require transport encryption to be used (TLS)
• require authentication
• not use the EHLO argument for spam checking purposes.

This is also how many email providers work.

To make this easy to implement SMTP and SUBMISSION operate on different ports. SMTP uses port 25, SUBMISSION uses port 587 or 465 (see RFC 8314).

RFC 5321 states this about the EHLO parameter:

The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name.

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes. Note that this prohibition applies to the matching of the parameter to its IP address only; see Section 7.9 for a more extensive discussion of rejecting incoming connections or mail messages.

Most mobile devices don't have a domain name that resolve to their IP address. Since NAT gateways are still very common it's also not easy to find out a device's public IP address without using a third-party service. Getting the IP address of the network interface used to connect to the submission server will most likely reveal an internal IP address. We therefore opted to always send EHLO [127.0.0.1] or EHLO [IPv6:::1]. These are syntactically valid address literals.

To summarize: do whatever voodoo you want to detect spam on SMTP. But SUBMISSION is there to serve authenticated users of you service. Requiring anything from EHLO arguments besides using the correct syntax is unreasonable because of the environment (mobile) clients work in.

[SorenRR]

Perhaps someone need to re-read the relevant RFC's. And... People really need to look into their network settings as I believe both the unix and windows world have the ability to build a FQDN from local hostname and domain.

I have a mixture of Linux, Windows XP, Windows 10, Windows Server 2003R2 and Windows Server 2012R2 machines in my LAN that all have FQDN's built from the domain name assigned via DHCP and the local hostname.

But again... The RFC's are made by people a lot smarter than all of us and so far I have not seen anything to contradict that.

[HeresJonny]

So this has been fixed?

[cketti]

So this has been fixed?

No. In the past K-9 Mail has done what you have suggested in the original post. But this was causing issues, too.
I maintain that every SUBMISSION server that denies clients because of the HELO/EHLO argument is misconfigured.

[SorenRR]

@cketti, You do know that the ESMTP "submission protocol" used by MSA's are based on SMTP and that the SMTP protocol dictate that the HELO/EHLO greeting must include the FQDN or address literal of the MSA/MUA/MTA?

It is not your job to dictate how a mail administrator configure his server as long as he follow the RFC's. If the administrator decide to reject non-FQDN EHLO greetings it is his right. And your loss!

Just my 5c...

[cketti]

@cketti, You do know that the ESMTP "submission protocol" used by MSA's are based on SMTP and that the SMTP protocol dictate that the HELO/EHLO greeting must include the FQDN or address literal of the MSA/MUA/MTA?

I quoted the RFC above. And if you have a closer look, you'll see that K-9 Mail is using a valid address literal.

It is not your job to dictate how a mail administrator configure his server as long as he follow the RFC's. If the administrator decide to reject non-FQDN EHLO greetings it is his right. And your loss!

Your "spam fighting measure" (which arguably is a violation of the RFC; see recent discussions on the ietf-smtp mailing list) is preventing your own (authenticated) users from using the service for no good reason.
It can't be that hard to limit the EHLO check to port 25 and not apply it to port 587. Everybody else seems to do it that way.

[SorenRR]

Ah... You do remember that the response to EHLO is the list of options offered like STARTTLS and AUTH? Users are not authenticated at the stage of rejection.

FYI: The postfix equivalent to what I do is: reject_non_fqdn_helo_hostname = yes

Can you please show exactly which RFC I violate by rejecting a non-compliant EHLO.
I know I should send back 550, I don't... I ban the sucker for a week.

Oh and I also host a webmail solution, just in case ... ;-)

[justinacolmena]

On January 25, 2020 12:10:19 PM AKST, "Søren Raagaard Rathje" [e-mail] wrote:

Ah... You do remember that the response to EHLO is the list of options
offered like STARTTLS and AUTH? Users are not authenticated at the
stage of rejection.
I should hope not.

FYI: The postfix equivalent to what I do is:
reject_non_fqdn_helo_hostname = yes

Can you please show exactly which RFC I violate by rejecting a
non-compliant EHLO.
I know I should send back 550, I don't... I ban the sucker for a
week.

https://www.linode.com/community/questions/8831/postfix-reject_non_fqdn_helo_hostname

If the mail is on port 25, as it is supposed to be from another server, then that is probably a good idea.

If on the other hand there is a client trying to log in on port 587 and use STARTTLS and AUTH for relay privileges, then the reject_non_fqdn_helo_hostname option is probably unnecessary, and will almost surely prevent authenticated clients from sending mail.

It is a little confusing to me, because the postfix configuration is somewhat "mixed" between "main.cf" and the inetd-like "master.cf" as to which options apply on which open ports.

>

Oh and I also host a webmail solution, just in case ... ;-)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[cketti]

In general it's quite simple.

Port 25 (SMTP): Do whatever you feel is necessary.

Port 587 (SUBMISSION): Only check HELO/EHLO syntax, not content. Require authentication. Optional (but advisable): only allow sender addresses associated with the authentication credentials used.

[SorenRR]

What is the problem with having k9mail use the FQDN?

Privacy is not a valid option! If your ISP know your IP Address then NSA, GRU, FSB, CIA, MSS, KGB and Mossad know it too.

[spaetz]

I know this issue is closed, but my Android is always connecting via VPN when on mobile data, so all kmail9 will ever see is a 10.0.0.1 IP address. Refusing to take mail from it would not be smart thing though. So just for the record: k9mail cannot always see a valid FQDN.