Here’s the reply I received …
Hello Paul,
Thank you for contacting HostGator. I would like to address your concerns separately.
“For their part as you will have seen, the K9 developers state that a duly authenticated user should not have to worry about all this, asking why would a logged in authenticated user be filtered as potential spam?”
The developers are only putting forth their opinion on how a mail server should operate, from their perspective as a developer (and based on how they think email should operate). Simply because a user is authenticated does not, in any way, mean they are not going to send spam. Whether or not a user is authenticated is not a viable method for determining their intent post-authentication, since spam being sent from compromised email accounts has been an issue for decades. We reject tens of thousands of spam emails everyday that are sent from authenticated email clients that have been compromised. I understand their reasoning for using a spoofed IP address during the EHLO transaction, although I believe other methods could be used in an obfuscation effort.
However, for the purpose of what is occurring in this case, the email server itself has no way of determining what you (or anyone else) will be doing after they login, so we must implement at least some spam-fighting techniques at every step of the email transaction process. Many mail providers implement IP checks during the transactional process of sending emails, that way if an IP address may be in a blacklist, the IP can be blocked from ever being able to send an email in the first place, stopping the problem before it starts.
“If authenticated - but apparently viewed as spam mail (possibly from stolen credentials) were rejected and bounced back with a message would that not warn the genuine User that something was up?”
CPanel already has this functionality built-in by default and will clearly send end users notifications if their email accounts hit certain outgoing email thresholds and still, the vast majority of users ignore these notifications entirely, despite the fact that these notifications not only tell the user something wrong is going on with their account, it includes the entire email that was sent but then blocked, as well.
We also have other measures in place that bounce verified spam back to end users, explaining why the emails were flagged as spam, however many users ignore those as well. Even when emails are bounced back from email recipients with rejections that make it very clear that spam was/is sent, we have many, many end users that completely ignore those notifications as well.
Over the last 15 years that I have worked at HostGator, I’ve seen VPS and dedicated servers where users have sent tens of millions of spam emails over the course of months – complete with literally tens thousands of bounce backs being sent back to the originating server – and users ignore those notifications entirely, and then they get mad at HostGator for allowing their emails to be blocked and/or to allow this spam to ever occur in the first place when we (HostGator) didn’t know it was occurring in the first place.
The issue is rarely with whether or not an end user received some kind of notification that their email was blocked, for any reason, the issue we frequently encounter is whether or not the end user knows what the notification is for and what to do (or not do) with that information.
“Are there any suggestions for what can be done to resolve this going forward please?”
Unfortunately, unless you decide to switch email applications away from K9, or utilize another mail provider, this issue will remain unresolved on our network, simply due to the choices the developers of K9 are making, in their fight for user privacy. While RFC5321 states that a literal address local can be substituted in place of the user’s own IP/FQDN during the EHLO process, spoofing that information to reflect 127.0.0.1 is a purposeful choice the developers are making, rather than finding other options for generating the IP/FQDN, such as creating a hash of random data as an FQDN which is based on both random data and the user’s existing hostname. Perhaps they have tried these things in the past, I fully admit that I do not know, but I do know that other mobile email clients do not have this issue