5.8 showing as sent, but not always arriving at destination

Hi,

This is a fresh thread, originally started on another, it was suggested there to make a fresh one.

First in all my years of using K9, I am not aware of this ever happening to me before.

People on K9 5.8 might need to check all their email is actually, not only sending properly, but actually getting to destination.

Since the very day of putting the new K9 5.8 version on, it turns out now that some emails, even though they show as having been sent, and are in the sent folder, have not arrived at destination(s).

This only happens to some recipients more than others. Perhaps people on shared hosting? I cant be sure.

I have also logged into a web interface for my account, and I can successfully send emails to everyone and anyone I’m testing for, some of whom have not got my K9 5.8 sent emails recently.

Plus all the K9 sent ones are showing in my sent folder, on the web interface (Horde), and in Thunderbird on my laptop, as well, even the ones that have not been received at the other end(s).

I checked the K9 5.8 Send SMTP server settings all passed ok.

Three of us sat arround in a lounge, and using my K9 5.8, sending email to two people on the To line, then one in the to the other in the CC, and then viseversa, one person always got them all, and the other man never.
They were using older un-updated K9s on Hostgator accounts, and also Gmail trough the browser, and the Gmail app on Android.

— But the man, call him Joe, who never got my K9 5.8 sent emails, could get them both in his K9 (Hostgator based account) and his gmail, if I sent them from Horde Web interface from my very same account.

Joe could send me emails successfully, but my K9 5.8 replies to him are never received either, but when I replied from Horde or Thunderbird on PC he could.

I have also gone on to successfully send email to him from Thunderbird on my laptop, from and to, the same identical accounts.

I’ve uninstalled K9 5.8, and followed the github link provided on another thread here, for downloading the 5.6 .apk and installed it for now.

Sent some trial emails, and they all went straight to their destinations no problems at all.

(It turns out that from the date I put K9 5.8 on, Joe had not received a single email from me until I took K9 5.8 off and put K9 5.6 on instead!
And now all is fine.)

It also turns out K9 5.8 was not always getting through to all the people I thought were mostly ok.
Found out about other missing emails, that still show as sent in my sent box, which were actually mission critical – very sad K9 5.8 did that.

So the K9 5.8 sending problem is fickle.

I’m sticking away from K9 5.8 for now.

I’m on K9 5.6 at the monent, was K9 5.7 stable and safe to use?
Should I use K9 5.7 until K9 5.8 is fixed?

Kindest regards,

Paul

2 Likes

K-9 Mail is sending messages using your outgoing mail server. As soon as the mail server accepts the message, K-9 Mail will upload the message to the Sent folder. It’s then up to the mail server to make sure the message is delivered. If there’s a temporary error, the server usually retries for a couple of days before giving up and sending you an email about the failed delivery.

It’s possible that K-9 Mail 5.800 is creating messages that are slightly different than those created by 5.600. And it’s also possible that some mail servers don’t like something about the “new” messages. However, without a detailed error report from a server rejecting such a message, there’s not much we can do.

I’m encountering the same problem with HostGator email problems and version 5.8*. I can send mail from k9 on my phone to other accounts on my server. My emails outside, to Gmail or my work or my wife’s work, are not arriving. Emails sent from my HostGator account using the Windows Thunderbird app go through to my work and gmail. I’ve downgraded to version 5.6 of K9 and that is working to send to work and gmail as well.

There’s only very little difference in the messages generated by K-9 Mail 5.600 and those generated by K-9 Mail 5.800. Please test the APK linked in this comment, it might fix the issue:

1 Like

Hi,

Ok so that is confirmed now.

Looking around this forum, I believe that some other earlier versions of K9 had the same problems.

I’ve obtained access to the relevant mail logs for the period of time I had problems with K9 5.8*, and will post what ever might be relevant once I have downloaded them and had time to sort them out.

Paul

Thanks for that I’ll process the mail logs through later on, first, incase you can spot something relevant before I try another .apk as it may be inconclusive or indeterminate overall, and I don’t want my mail potentially mucked up at the moment please.

Ok, here are a couple of samples …

IP addresses / domains obstrifucated = dah.dah.

Un-sucessful from K9 5.8*

2021-08-03 07:13:22 1mAtIQ-002zkr-2s <= paul@dah.dah.info H=dah.dah..dyn.cust.vf.net.nz ([127.0.0.1]) [dah.dah.]:41276 I=[dah.dah.]:465 P=esmtpsa X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_plain:paul@dah.dah.info S=1200 id=75B12B67-8517-41D3-91F4-26D8A6418A5E@dah.dah.info T="Test from K9" from <paul@dah.dah.info> for joe@dah.dah.com record@dah.dah.com
2021-08-03 07:13:22 1mAtIQ-002zkr-2s => /dev/null <joe@dah.dah.com> F=<paul@dah.dah.info> R=fightspamHG T=**bypassed** S=0
2021-08-03 07:13:22 1mAtIQ-002zkr-2s => record <record@dah.dah.com> F=<paul@dah.dah.info> R=virtual_user T=dovecot_virtual_delivery_no_batch S=1360 C="250 2.0.0 <record@dah.dah.com> kAAeJOIyCWHwzgoA2xhqkA Saved"
2021-08-03 07:13:22 1mAtIQ-002zkr-2s Completed

Sucessful from K9 5.6*

2021-08-03 09:13:17 1mAvAS-004581-KE <= paul@dah.dah.info H=dah.dah..dyn.cust.vf.net.nz [dah.dah.]:42626 I=[dah.dah.]:465 P=esmtpsa X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_plain:paul@dah.dah.info S=1550 id=8A0E2D93-B82E-494A-90D1-E0429B94496A@dah.dah.info T="Trial from old K9 version 5.6 on phone" from <paul@dah.dah.info> for joe@dah.dah.com michael.too@dah.dah.info record@dah.dah.com
2021-08-03 09:13:17 1mAvAS-004581-KE Sender identification U=pauloinf D=dah.dah.info S=paul@dah.dah.info
2021-08-03 09:13:17 1mAvAS-004581-KE SMTP connection outbound 1627999997 1mAvAS-004581-KE dah.dah.info joe@dah.dah.com
2021-08-03 09:13:17 1mAvAS-004581-KE Sender identification U=pauloinf D=dah.dah.info S=paul@dah.dah.info
2021-08-03 09:13:17 1mAvAS-004581-KE Sender identification U=pauloinf D=dah.dah.info S=paul@dah.dah.info
2021-08-03 09:13:17 1mAvAS-004581-KE => michael.too <michael.too@dah.dah.info> F=<paul@dah.dah.info> R=virtual_user T=dovecot_virtual_delivery S=1725 C="250 2.0.0 <michael.too@dah.dah.info> SHfJCP1OCWEWyA4A2xhqkA Saved"
2021-08-03 09:13:17 1mAvAS-004581-KE => record <record@dah.dah.com> F=<paul@dah.dah.info> R=virtual_user T=dovecot_virtual_delivery_no_batch S=1719 C="250 2.0.0 <record@dah.dah.com> KHplDP1OCWEWyA4A2xhqkA Saved"
2021-08-03 09:13:18 1mAvAS-004581-KE => joe@dah.dah.com F=<paul@dah.dah.info> R=send_to_gateway T=remote_smtp S=2311 H=cm.websitewelcome.com [100.42.49.18] I=[dah.dah.] X=TLS1.2:AES256-GCM-SHA384:256 CV=yes DN="/CN=*.websitewelcome.com" C="250 2.0.0 AvATmpE8uMGeEAvAUm0JlB mail accepted for delivery"
2021-08-03 09:13:18 1mAvAS-004581-KE Completed

If you think that .apk you mentioned earlier has this covered then I will try it out for you.

Kindest regards,
Paul

Hi cketti,

Please test the APK linked in this comment, it might fix the issue

Ok on spec we gave that a go.

The apk froze my phone on first install attempt.

After a reboot, installed ok.

Unfortunately it did not fix the problem.

The two gmail accounts I sent to, did not receive their emails.

The troublesome Hostgator account, nor another that was working on 5.8 previously, didn’t get theirs at all.

I reverted back again to K9 5.6 for now, and successfully got through to both Hostgator accounts and the two gmail.com accounts using 5.6 again.

Hopefully those log entries I supplied can help?

Thanks,
paul

I’m guessing it’s a (stupid) spam filter not liking the message. What’s “fightspamHG”?

I found this (Change Helo/Ehlo address | Odoo):

I talked to hostgator about this. Apparently the Helo / Ehlo record of 127.0.0.1 is being blocked by their outgoing spam filters.

Checking the argument of the EHLO command seems to be an effective spam fighting measure when using SMTP. However, trying to do anything with this value when using authenticated SUBMIT (this is what a client like K-9 Mail is using to send messages via the user’s email provider) is quite pointless and bound to cause problems. Many mobile clients have no way of getting their (public) host name and/or IP address because they are behind NAT gateways. The SUBMIT server is in a much better position to do so (it sees the mobile device’s public IP address).

K-9 Mail 5.8xx is using the EHLO command with a “domain” value of 127.0.0.1. That seems to be the least bad option that works more often than it does not. I don’t want to make this value configurable because I consider SUBMIT servers that refuse to accept this value broken.

You seem to have the following options:
a) get your provider to fix their server
b) find another provider
c) use a different email client that works around your email provider’s broken rules

I’m not sure what “fightspamHG”, K9 5.6* doesn’t seem to trip it on Hostgator, while 5.8* does for some reason.

Seems to similarly affect inwards Gmail as well.

Thing is this could be going on and some people won’t realise it yet.

A simple web search suggests “fightspamHG” is a common cPanel setting, so it could appear on a number of different web host solutions.

Are there any new code page settings in the new K9 5.8* send mail at all (even a bad mix?), or is it all just utf8 by default?

P.S.

Your mentioning spam makes me wonder, is there anything different in the way K9 5.8* as client, is identifying itself in the headers to mail host servers, that now differs from K9 5.6* ?

Our postings seemed to cross when I replied from the phone :slight_smile:

It looks llike a simillar problem to what happened under K9 5.7* ?
A forum thread here on that pointed me to the K9 5.6* apk

What was done to fix that, or was it something different?

Cant you do it all as was working for K9 5.6? And which still works in K9 5.6* today?

Hostgator is an enormous market share …

What K-9 Mail 5.600 did wasn’t great either. See Always send IP instead of hostname in HELO/EHLO by Valodim · Pull Request #3798 · k9mail/k-9 · GitHub

Perhaps using something in the 172.16.0.0/12 range would elicit a less foolish response from poorly configured/managed servers.

Is this for mail dropped directly on gmail (as the configured “outgoing mail server”) or addressed to someone at gmail but dropped on your hostgator server?

Seems to similarly affect inwards Gmail as well.

I’m not seeing this with gmail.

“Inwards” for Gmail, in the sense that it’s being sent to it from K9 5.8* via Hostgator server sending it.

It is fickle sometimes in that mail can get through to some people, perhaps under Reseller accounts on Hostgator.

This is just flying a kite, one man I have mostly been able to send to under 5.8* is under our Reseller account, and 127.0.0.1 might actually make sense then, if that helps as a diagnostic?

I won’t be available to answer for a while – after midnight here now :slight_smile:

It appears that this is due to hostgator foolishly filtering based on the EHLO on the (authenticated) submission port. Providers do need to have things in place in case of stolen credentials, but dumping mail because of:

EHLO [127.0.0.1]

isn’t anywhere in the range of “best current practices” when handling authenticated submission.

One last from me for the night …

Is this the same issue as this one refered to earlier here and on the tracker?
https://github.com/k9mail/k-9/issues/4428

Yes, that’s a discussion of this issue. I (for what it’s worth) think that cketti’s position is correct. Do what you want in terms of filtering on smtp/25, but on the submission/587 & 465 ports, which are (intended to be) authenticated, filtering on things like the EHLO is foolish and counter productive. In addition to privacy issues, the IPnumber or name that a mobile device or desktop machine presents has a low probability of resolving correctly (forward and reverse) so should (as is the standard practice) be ignored in an authenticated context. Presenting a fixed value is a reasonable approach.

That hostgator is silently dumping this mail is not standard practice and makes matters even worse. [If for some reason you don’t want to accept mail from your authenticated customer, tell them.]

1 Like