"future timed out" message on ios

[r10s]

got this hint from the apple review team when trying to ship 1.6; 1.6 was rejected therefore.

"We discovered one or more bugs in your app when reviewed on iPad running iOS 13.4.1 on Wi-Fi.
Specifically, an error message appeared upon logging in, we were unable to access the app. "

might be, that just the testrun address was not working and the error is a "normal" timeout error - with a bad wording.

@basti do you have an idea where the message comes from?

we should get this reproducible, before submitting again.

[cyBerta]

That's a great error message :D
I haven't seen that before. I can have a look into it, I'm pretty sure the error message doesn't come from the UI layer.

[cyBerta]

DC_EVENT_ERROR was sent by the core containing this error message and afterwards on DC_EVENT_CONFIGURE_PROGRESS this message was shown in the UI.
So either it's a core issue or the backend is sending this errormessage.

[r10s]

i think, this is where the error was created: https://github.com/async-rs/async-std/blob/master/src/io/timeout.rs#L74

[link2xt]

Probably caused by the change introduced in this PR: deltachat/deltachat-core-rust#1378
Related issue: deltachat/deltachat-core-rust#1377

[r10s]

still not working on attempting to upload 1.8.1 :/

but at least, we refined the error message in #712 - maybe this is more useful now - cc @link2xt do you have an idea?

the shown "warning" is just the last warning logged before the error, this may or may not be related. the "progress", is the last DC_EVENT_CONFIGURE_PROGRESS permille ios has received.

we could not reproduce the error on any testing device. wondering why apple allowed the same ipc as testflight release - i provided the same credentials there - either they do not test there or they are using a different environment.

seems not to be releated to the used provider btw, i switched from testrun.org to deltachat.de, same thing.

[r10s]

this is the line where DC_EVENT_CONFIGURE_PROGRESS with permille 860 is sent: https://github.com/deltachat/deltachat-core-rust/blob/master/src/configure/mod.rs#L627

but i think, the issue is already before - testrun.org also failed but is using a different port and should not fail at that line as was_autoconfig should be true in case of testrun.

EDIT: just tried over with the repl tool: here just the first smtp-try on port 465 succeeeds: https://gist.github.com/r10s/7f26335b6cd214a17a2be5d9d8182e66 - same on ios in my tests.

[link2xt]

Because of deltachat/deltachat-core-rust#1465 we can see it is SMTP error on port 25 now. Apple testers probably have port 25 filtered as it is used to send spam via open relays. So connection attempts to port 25 times out. Ports 465 and 587 failed because tester did not enter any password, as seen in the screenshot, they were probably expecting to get the error that password is wrong.

IMAP warning is not related, but it is better to check that any folder is selected before sending CLOSE command.

I think it can be reproduced by filtering out TCP port 25 using nftables and testing if repl tool times out the same way when wrong password is used.

[r10s]

Ports 465 and 587 failed because tester did not enter any password, as seen in the screenshot

the screenshot is weird - there should either the placeholder "Enter existing password" or some dots for each character entered. but we got these screenshots also in the past with issues we could solve, so, i think, they really actually entered a password. not sure, though.

i just asked this question to apple, also why testflight with the same credentials was approved.

I think it can be reproduced by filtering out TCP port 25 using nftables and testing if repl tool times out the same way when wrong password is used.

are there chances to reproduce this in the repl tool? can you have a look at that?

[link2xt]

I was able to reproduce "future timed out" by blocking port 465:

#!/usr/sbin/nft -f
...
table ip filter {
  chain OUTPUT {
    tcp dport 465 drop
    tcp dport 587 drop
    tcp dport 25 drop
...

I have started repl, configured correct addr and mail_pw, and started configure. Got this:

{Received DC_EVENT_CONFIGURE_PROGRESS(800 ‰)}
ThreadId(5) src/configure/mod.rs:642: Trying: smtp: foo@example.org@example.org:587 flags: 0x10204
> 
> [DC_EVENT_ERROR_NETWORK] msg=Could not connect to SMTP example.org:587: future timed out
[Warning] ThreadId(5) src/configure/mod.rs:658: could not connect: SMTP: failed to connect: Io(Custom { kind: TimedOut, error: "future timed out" })
ThreadId(5) src/imap/mod.rs:304: IMAP unsetup_handle step 2 (acquiring session.lock)
[Warning] ThreadId(5) src/imap/mod.rs:310: failed to close connection: Bad("code: None, info: Some(\"No mailbox selected (0.000 + 0.097 + 0.096 secs).\")")
ThreadId(5) src/imap/mod.rs:315: IMAP unsetup_handle step 3 (clearing config).
ThreadId(5) src/imap/mod.rs:318: IMAP unsetup_handle step 4 (disconnected)
{Received DC_EVENT_CONFIGURE_PROGRESS(0 ‰)}

Given that for apple testers autoconfiguration was trying SMTP already, IMAP was configured successfully, so they provided the correct password for it.

My guess is:

• They provided IMAP password in advanced settings
• They did not set SMTP password in advanced settings
• They have port 25 blocked, but ports 465 and 587 unblocked, so they got auth errors there and timeout on port 25.

How does "advanced" menu look like, could someone attach a screenshot?

[r10s]

@link2xt great that you fond a way to reproduce that! wow!

this is how the "advanced" menu look like in my iphone 11 emulator - and yes, they probably did not provide an extra smtp-password (is not needed in most cases anyway):

[link2xt]

SMTP password should be replaced with mail_pw if it is empty. I don't get why did they fail to login over ports 465 and 587 without timeout, other than providing incorrect SMTP password. And why there is no password in the original screenshot?

[r10s]

SMTP password should be replaced with mail_pw if it is empty.

i think, this is what actually happens: https://github.com/deltachat/deltachat-core-rust/blob/master/src/configure/mod.rs#L315

[r10s]

this part i do not understand:

to reproduce this blocked all smtp ports, or?

chain OUTPUT {
tcp dport 465 drop
tcp dport 587 drop
tcp dport 25 drop

so, with that, it is understandable, that smtp fails (of course, the error message is not good)

They have port 25 blocked, but ports 465 and 587 unblocked

this is the assumption for apple - but given that 465 and 587 are unblocked - why do they not work fo them=

[link2xt]

Yes, I blocked all ports, because otherwise it would succeed with port 465 or 587. To get timeout on port 25, need to block port 25 only and provide incorrect SMTP password, in addition to correct IMAP password. This is what I think apple did, can't find any other explanation.

[r10s]

but why does 465 and 587 are not working for apple then? k, this is probably the question we try to answer the whole time :)

sth. mixed up in the settings, might be.

i asked them wrt screenshort and password, let's see how responsive they are.

[r10s]

finally, 1.8.1 was approved, maybe some blocked ports that should not have been blocked, not sure at the end.