I want to add the Information that the same issue happens to gmx accounts.
I had to revert to 5.6 to send Emails successfully again.
I assume Web.de and 1und1.de are also affected in the same way, as they share the same server backbone.
Hi Thomas,
Yes there will be people having it happen to them on a number of server frameworks around the world, and possibly not even know/ realise it yet.
Either through only having recently updated to K9 5.8*, or they have a low volume of email traffic, or for whatever reason not noticing theyâve not had email replies or heard back as expected from people they think theyâve emailed yet.
Only a certain percentage of K9 5.8 app Users will ever find their way to this Forum though.
And there are those yet to be in the process of updating to K9 5.8* who are yet to discover this peculiar âimprovementâ to what was previously a universally useful, and excellent app.
Itâs all so far an unnecessary trouble, and an shameful waste of peopleâs time really.
I cannot confirm that for GMX.net, just tested with my GMX address and successfully sent an E-Mail to GMail via the account.
Maybe the difference is, that I newly added my GMX account?
I have a GMX.com (not .net) account. I have encountered no problems when sending from that account using K-9 v5.804
I have been using this account with K-9 going back several versions (at least early 5.7nn, and possible as far back as 5.600
1 Like
Hi, with which version did you do the test?
I started with 5.8.001 and updated till 5.8.003 without the possibility to send Mails using k9.
Then i needed a fully working Mail Client and therefore reverted back to 5.6.
Noch everything works as expected.
Maybe the Issue is noch fixed?
1 Like
Without full and accurate descriptions positive results of âtestsâ can be meaningless and misleading.
Needs to be done thoroughly as at top of this thread, and be sure itâs not on the server only being treated as a âlocalâ delivery or other such phantom situation â such will of course appear accurately as working but are only a small subset of real life situations.
I wouldnât doubt your results Thomas.
The version was 5.803 and repeated now with 5.805.
The e-mail was a mail sent from my gmx.net address to my Gmail address, also tried with another company address that I donât want to name. All emails arrived without problems.
Iâm not saying that others donât have the problem, just that itâs appearently not true that itâs not working for GMX in general.
No longer working for my domain on BlueHost either. I can send messages just fine using webmail but since the update I am hosed. Not particularly happy about switching mail providers.
Someone just needs to add a switch to K-9 and let the user of the product make their own choices.
Off to find another mail programâŚ
-Mac
I also have problems sending emails, since the upgrade to version 5.806, sent emails appear under the âSentâ folder but none of them reach their destination.
Iâm also using bluehost.com as my host. Before the version upgrade all worked well
This is a critical issue that must be resolved ASAP.
Anyone has a solution?
1 Like
If messages you are sending are showing in your âsentâ folder they have been accepted by the host you have set as your âoutgoing mail serverâ. If that host/MSP (mail service provider) isnât delivering the messages to the intended recipient(s) and isnât informing you that there is an issue keeping them from doing that, thatâs their issue. You should contact them and ask them what they are doing with the messages that you, as a customer/authenticated user, are successfully delivering to their server.
⌠Problem is not as simplistic as that, nor primarily with email service providersâŚ
More to the point tell people what the developers did to break something that has worked extremely well until K9 version 5.8?
There is no issue with the email host as when I send emails through my laptop via microsoft exchange it works using the same email credentials.
Itâs a problem with K9 new version.
It seems there is a serious bug that needs to be resolved.
1 Like
Actually, it is that simple. Thereâs no bug in K9, rather the issue is in how certain MSPs (mail service providers) are handling mail that is delivered (by their customers, through authenticated connections) to their servers.
When a mail server or client connects to a server to deliver mail it identifies itself with a HELO/EHLO. In the MTA-MTA world being able to resolve the hostname/ipnumber on that matters. In the client-MSP world most MSPs ignore that â since the IPnumber is mostly meaningless and client is authenticated. K9 (and Fairmail if you have it use an IPnumber rather than the default dummy name) issue âEHLO 127.0.0.1â rather than your clientâs ârealâ ipnumber â which is likely either a private address off your lan or something that will leak your location - both of which have privacy implications. It appears that some MSPs find the 127.0.0.1 âsuspiciousâ. While a little foolish, that is their prerogative.
This is where the problems start. If the MSP thinks that that is a spam indication (even for an authenticated connection) and arenât going to deliver out the message they would be best to reject it on the connection. If they accept the message - which is when it shows up in your âsentâ folder - and subsequently dump it (which hostgator does â 1mAtIQ-002zkr-2s => /dev/null), then they should notify you, the customer, that they didnât deliver your message out.
That they donât reject the message on the front-end or notify you of non-delivery on the back-end is well out of what are considered as âbest practicesâ.
From the postings above we have seen what Hostgator is doing. You will have to ask Bluehost why the messages they are accepting from K9 arenât being delivered since they donât seem to be informing you that there is an issue.
That these messages, that the MSP is accepting from K9, arenât being delivered out is not a bug in K9, rather itâs an issue of the internal practices of the MSP - which they need to explain to you, their customer.
4 Likes
While I completely agree that the issue is with the mailserver, I also wonder if it would not be sensible to have at least the option to restore the previous HELO/EHLO behavior for those that need it.
Most people donât care that that their local IP is leaked (and if not using a VPN, the mailserver knows it anyways, and where it is an internal NATed address, the privacy implications are minimal anyways), but that their mail is not delivered. Telling everyone to convince their mail provider to change their config out of principle for the RFCs sake, is a crusade most people wonât want to fight and in fact wonât change anything in reality except that they have to switch their email program (who seriously is going to change their email address to be able to keep using K9?).
Of course itâs the right of the maintainers to not implement this, but for the sake of a good community, I think it would be good to compromise on some things and that would seem to me to be one where it would be sensible.
1 Like
Even if the issue is at the MSPs (mail service providers) level, from my simple âend userâ point of view, currently K9 is worthless as Iâm not able to send any emails. Personally, if it wonât be resolved soon I will have no choice but to switch to another email app.
2 Likes
Itâs not to be a matter of people, the Users, being forced to choose between whether their email appâs developers, or their MSP (Mail service Provider) are ârightâ or âwrongâ.
That would be an unnecessary polarisation here in this OpenSource project, which no one really needs, or wants wouldnât you think?
There are aspects of this not straight forward for an MSP caught up in the K9 developersâ decision on the changes they decided to make to this OpenSource app.
You can argue from a âpuristâ take on the âstandardsâ, how an MSP ought to do things, but sometimes hackers work out how to exploit those âstandardsâ, and in reallife MSPs are left to make pragmatic choices limited by commercial, administrative and operational mattersâ realities, of how they can best handle real-life situations in their Users overall best interests.
It can take a while for âstandardsâ to be redrafted to reflect dealing with what hackers are up to, and meanwhile MSPs, developers, and others at the coalface of things, have to make their best effort to keep things moving, without their responses, to actual real-life situations, overflowing their Usersâ email inboxes with overwhelming numbers of notifications in the circumstances of: if or when hackers have found a way of exploiting such a conundrum.
As has happened in the past.
An MSP can be left wedged between a rock and a hard place on this one. Obviously I would like all MSPs to find better workarounds, if that were possible please?
But meanwhile a âpuristâ and unnecessarily confrontationalist argument based on âprotocolsâ is perhaps being advanced here by some of the K9 developers, that inadvertently could potentially champion the hackersâ cause as things presently stand in reality.
Iâm sure that in the public interest none of K9âs developers would want to be unintentionally found falling into a line of reasoning which presently in reality could inadvertently, in some way that the K9 developers â being good honest developers â can not conceive of, help bad or spam emailers in some way, surely not?
Put simply, reallife workarounds are sometimes needed whilst established protocols-standards, MSPs and developers, all catch up to real-life, all remembering to be operating at all times for the benefit and best of their legitimate Users of course.
Previously K9 was for years it seems, sensibly and successfully using one of those workarounds in this matter; and now needs to go forward by innovatively finding/using such a solution againânow that is a worthy dev. challenge for excellent programmers to rise to be successfully achieving in everyoneâs, especially their appâs Usersâ, best interests, isnât it!
1 Like
Iâm facing similar issue. I donât see emails even in Sent folder from 12.9.2021. My version is 5.806
I have to use MS Outlook for sending emails.
There is no issue on MSP site, only on K-9.
Also I was searching for tool to compress mail file, seems to be missing.
Quite annoying 
It appears there is a stalemate here,which is extremely disappointing.
I am absolutely not going to do battle with my provider over it, as they havenât changed anything and it works fine with every other email app (and thatâs pretty much what I expect to be told once/if I get beyond tier 1.)
Whether itâs RFC compliant or not is irrelevant. The fact is that K9 has changed to something that no longer works and is either going to fix it (change it back) or not.
In the meantime Iâll use an app that does work. There are plenty available.
I have bluehost, same issue here. Gotta shelve k9. Would be a nice setting to have to go back to 5.6 behavior. Strange that the developer changed.without an option to retain old behavior.
Using Google Gmail app now.
This feature stung as I wasnât able to continue email conversations. Thanks to all who figured it out. To all who blame the email provider, they have policies the clients should confirm to. The client should be the flexible one, and i got burned.
Once this had been figured out, the developer should have added a quick fix and then a notification. But I just got a notification to send him $100 a month so he can work on this full time.
Dear Andrew,
Totally understand how you feel.
Youâve made some excellent points.
Sad youâve had to move on, hopefully someone here will finally wonder if it is a victory for OpenSource that they are forcing people like you to be: âUsing Google Gmail app nowâ.
I keep monitoring this thread ever hopeful âŚ
Kindest regards,
Paul