SMTP server connection error

[StR]

Kostya,
I've experienced the same error a few times on separate occasions (not networks-specific) while sending e-mail messages using Aquamail. (IMAP account, private server, sendmail+tls+sasl)

First of all, the error message is extremely quick, and it is hard to see/catch. After that the message sits in Drafts, and you can see no error message, which is inconvenient. The only way I was able to do that was by catching a screenshot (and that was possible only after a few tries).

Second, - I am still not sure what is actually happening. The error screenshot is attached:

"Error sending outgoing messages: Invalid security (SSL) certificate: java.security.cert.
CertPathValifatorException:
Trust anchor for certification path not found.."

Trying to resend the message was not providing anything to resolve the situation, except the opportunity to catch the error message in the screenshot.

With that, I had two (or three) guesses about what was causing the error:
1) either it is related to the change of the TLS (previously known as SSL) certificate as compared to the one seen previously, or
2) there is a problem verifying the chain of trust (either due to the connectivity issues or because of something related to the root certificates present on this phone (It is running Android 4.1.2).
(The server's TLS certficate is issued by Let's Encrypt Authority X3, whose root cert is "DST Root CA X3".)

However, yesterday (and at least once before) I was able to sent the message by the following trick: I went to the account settings, chose "manual", went through all the screen with the existing values, allowing Aquamail to connect to the servers, and finishing the "settings" without changing anything. After that, I went again to "Drafts", and was able to send the message.
I was expecting that this procedure would catch the updated certs or would offer me to review approve the change in the certs.

From this, I concluded that the culprit was 1) above.
Indeed, the server cert was renewed a couple of weeks ago, and since that, I haven't sent any message through this account from the phone (I use it primarily for reading, much less for sending messages, especially with this account.)

So, here are the questions:
1. Do you think my conclusion is correct about the underlying reason?
2. Why Aquamail (unlike in case of the IMAP server problems) does not offer the interface to accept the change in the certificate?
3. Why there is no change of certificate warning (and review) when you are going through the settings? Imagine the situation when I am going to those settings to change something rather than the server, e.g. password. At that point a MITM attack would be missed.
4. Why does the error message disappear so fast, as opposed to getting "stuck" the same way as it happens with the IMAP server.


All of this has been happening on a legacy (definitely pre-No-Zoom-On-Reflow) version of Aquamail, but I am not sure if you've changed anything in the SMTP-connection code in the past year. (Although, I remember you were changing something related to the change of TLS certificates.) So, if something that I've questioned above has been changed (fixed), - sorry for bringing it up (but I'd like to know that).

Phone: Droid Razr M running Android 4.1.2.

[StR]

I just verified that the same behavior is present in the very latest -dev. build on a Samsung Tab 3 (SM-T330) with Android 4.4.2.
The funny (and funky) part is that I was unable to take a screenshot with the error, with the system informing about DRM protected image. I wonder if that is from Samsung or from Aquamail?

[Kostya Vasilyev]

You are using a self-signed cert --

-- please long press on the account -> account setup -> manual -> next ->

you'll be looking at detailed outgoing server settings.

Please change the "security type" value from a "strict" one to an "accept any".

[StR]

You are using a self-signed cert --

(The server's TLS certficate is issued by Let's Encrypt Authority X3, whose root cert is "DST Root CA X3".)

[StR]

Additional observation:
While doing the "voodoo" steps with the "account setup" (as described above) allowed one successful sync (transmission) of the message, the subsequent outgoing message was in the same situation again.
Now, what's interesting is that the stuck message (at least at some point) seemed to have prevented the sync of the entire account: After some time I tried to do a manual sync (by clicking that wheel on the right), and it gave an error that it cannot send the message, and then stopped, and didn't sync the rest of the account.
But on a subsequent sync (scheduled), some 5 minutes later, the message went out, and the incoming box synced.

I will experiment more and look at some details later, when I get time, and will post if I find something relevant.

[StR]

Additional observation:  the outgoing messages after this are being sent just fine.

Also, I confirmed that on the second device running last week's dev version, if the outgoing message is stuck, manual refresh doesn't show new incoming messages.
The only way I oould load them was to open another (unsynched) folder, after which new messages have appeared.
PS. After that the stuck message was sent without any additional action from my side

[StR]

I have a suspicion that I might know the culprit got why the TLS certificate was not recognized. I will try to check in the next couple days, if I get time. If my guess is correct, it would be outside of Aquamail.

However, 1) the fact that the error message disappears too quickly and that 2) syncing of the mailbox afterward is stuck, and possibly even 3) that both the message and the inbox (and whatever else is configure to be synced) remain stuck even when that factor disappears, - are problems in Aquamail.

I will write more when I will get to check my hypothesis. I just didn't want you, Kostya, to waste your time trying to recreate (or understand the culprit of) the initial problem.

[Kostya Vasilyev]

Well, the usual scenario is that this would happen in the account setup "flow" and the TLS cert check failure - and all other errors - on that screen are displayed in a popup window (dialog) which does *not* go away.

So perhaps you made a change to your server config recently, and started doing "something interesting" with the server's certificates?

[StR]

First of all, - no changes have been made to either server or client/account.
Aquamail has been set to do "strict" cert checking for long time.
The only change that had happened to the server was that Let's Encrypt's certificates had been installed in early February. And I've seen this error a few times since that. Each time, I've attributed it to the change of the certificates (which happens on the server about every 2 months).

But: 1. I don't think I've ever got a dialog for confirming a new cert for the SMTP server the same way as I've been getting that for the IMAP server.
2. This time it happened more than once (at least twice - on two subsequent days), and
3. Each time it happened, I've noticed that the stuck outgoing message was preventing Aquamail from syncing incoming messages.

As I wrote, - I am investigating something (on the phone, but outside of Aquamail) might be causing the error in the first place.
But, these 3 problems seem to be Aquamail's. Furthermore, a brief glance I had over the debug logs of the subsequent connections indicates that (1) Aquamail doesn't seem to be requesting the cert from the server [unless I do something non-regular-sync related, e.g. opening another folder], and (2) probably not even trying to establish a connection to the IMAP server for the scheduled (and likely even a manual) sync.

I suspect that if you'd look in the logic of the app of what happens once the outgoing message is stuck with a cert-related problem, you might be able to see the "block" that happens on the sync action.

Well, the usual scenario is that this would happen in the account setup "flow" and the TLS cert check failure - and all other errors - on that screen are displayed in a popup window (dialog) which does *not* go away.

In the real-world scenario (that being a MITM attack, or any other reason for a failed attempt to verify the cert), - Aquamail should do the same graceful (detailed and persistent, not disappearing after 5 seconds) notification, and the rest similar to how it does in case of the certificate change for the IMAP server.

[Kostya Vasilyev]

Re: Aquamail has been set to do "strict" cert checking for long time

And yet, as can be seen in your original screenshot - the cert is failing to validate.

Yes, you're right, the handling of this particular error scenario could be better - but something's wrong in your server setup if you expect your certs to validate against Android's CA's (which is what "strict" validation is) and yet they (the certs) fail to validate.

The "take note when a cert changes and stop and tell the user" is a separate setting, under network, "track SSL certs".

[StR]

I might not have written my description well enough. I've tried to make them detailed, but may have buried the important parts, so that you couldn't see them while glancing over the thread.
Let me repeat the facts and findings grouped and summarized by the conclusions:

Configurations:
a) Configurations in Aquamail: strict checking, detect change of certificates,
b) Certs: the same for the IMAP and SMTP servers, with correct CNAME and alternative names. Certs are NOT self-signed, but rather issued by Let's Encrypt Authority X3, whose root cert is "DST Root CA X3". (Not OCSP stapled, but that shouldn't matter)
c) Two devices were used for testing:
Device 1: Droid Razr M with 4.1.2 and "Legacy" version of Aquamail (way before "reflow-on-zoom" was removed).
Device 2: Samsung tablet Galaxy S3 with 4.4.2 and Aquamail with -dev from about 2 weeks ago,

Observations:
(All described below applies to the same server and account, without anything being changed in the configuration.)
A.1. Aquamail successfully sends outgoing messages under some conditions, and not under others.
A.2. Aquamail successfully validates the same cert via IMAP server.

Conclusion A: Certificate is correct and installed correctly on the server, or Aquamail does not checks cert's validity consistently.

(Tentatively): An outgoing message gets stuck only when there no scheduled sync per configuration:
Device 1 is configured to have a scheduled sync on Wi-Fi only (no PUSH), none on mobile networks.
Device 2 is configured to have no "automatic" syncs (scheduled or on event).

[tentative] Conclusion B: "scheduled sync" might play a role here.

Once an outgoing message is "stuck":
C.1. Manual attempts to resend it (Drafts -> open message -> send) never succeed.
C.2. Manual syncing of the account (by pressing on the wheel next to the account in the account list view) never succeeds in sending the message out.
Here is what works (either of these separately):
C.3. Going through the account setup (manual...), keeping all the values the same.
C.4. Opening a folder that is not among those configured to be synced. (Other folders -> <not-a-recent-folder>)

Might work:
C.5. A scheduled sync (if or when allowed by the configuration).

I thought a scheduled sync had "worked" (i.e. was able to send the stuck outgoing message) at some point previously (Device 1), but I just tested that with Device 2, and the outgoing message was not sent after 2 cycles of scheduled sync (I enabled it specifically for testing).

Conclusion C:
There must be some difference in the internal procedure with respect to sending outgoing messages by Aquamail (specifically the step of checking the cert's validity) under different scenarios.


Other facts:
D.1. At least in some situations (observed at least three times, possibly more, on Device 1): the inbox doesn't get to sync [when doing that manually or during scheduled or "on-event" sync]) while the outgoing message is stuck. Doing one of the special things (C.3, C.4) unblocks it.
D.2 However, at least once, I've observed (Device 2) that the Inbox did sync while the outgoing message was stuck.


Questions:
1. What happens during steps C.1 and C.2 above (different from the normal sending procedure) that would allow validating the cert?
In case the cert is not installed in Sendmail in the way compatible with Aquamail, I'd like to know what is that, as Thunderbird, and numerous test tools (including those online) validate the cert without any hiccup or even warning.

2. Why an outgoing message stuck in the queue blocks sync of the incoming messages?

[Kostya Vasilyev]

Re: correct CNAME and alternative names. Certs are NOT self-signed, but rather issued by Let's Encrypt Authority X3, whose root cert is "DST Root CA X3"

You posted a screenshot where this "absolutely perfect" certificate failed to validate on Android.

Could be a timing issue related to how these certs are refreshed on the server side, or whatever.... I don't really want to guess.

---

When there is a network error - you can see it (and not just the "flashing" toast message) in the Drafts folder.

The Drafts folder will be highlighted in red on the app's main screen.

Now the issue with *receiving* tasks getting cancelled when there is a network error while *sending* (and sending is done before receiving) - this is true, and can be made better.