AquaMail Forum
English - Android => General Discussion => Topic started by: BigbirdPhila on June 14, 2017, 04:39:24 am
-
Does Aqua retry network errors when trying to sync folders? Sometimes I'm getting a network error when refreshing my folders. It appears at the top of the screen and says "Error checking mail. Error connecting." It stays visible for about 4 seconds and then disappears. It is not an error notification (the kind you can configure with a sound and/or vibration via AppSettings->ErrorNotifications). It doesn't produce error text in red under the account name, but it does turn the time of the last access red. The error text appears at the top of the screen briefly (about 4 seconds) and then automatically disappears.
It appears to me that once this happens, Aqua doesn't try again at the next sync interval (I have mine set to 10 minutes). I let it sit for over an hour this evening and the time of the last access never changed. I had to manually force a refresh. When I did, new emails came in.
Do I have something misconfigured? I would like it to retry or else I won't know if I have new emails unless I do manual fetches. I prefer hearing notifications. The account is configured IMAP, no PUSH. 10 minute sync interval. I am using AquaMail Pro, version 1.10.0-403.
-
For push it does retry "soon".
For scheduled checks, it will retry on next mail check - not sure why it didn't, maybe there was no network connection or maybe you swiped the app "away" from "recent apps"? (some Android versions / devices will "freeze" any "swiped" apps).
-
I wasn't waiting long enough. Yes, AquaMail does retry on the next scheduled mail check. It turns the last access time to red, but doesn't update the time. So, the time you see is the time of the last *successful* account access. The fact that the time is red indicates there have been one (or more) errors since that time. Knowing the current time and the sync frequency (10 minutes in my case), you can calculate how many consecutive errors there have been.
The errors I am seeing are occurring with the server imap.aol.com. It fails randomly, but sometimes consecutively for 10 or more sync checks. It works 100% reliably over WiFi (Verizon is my ISP), but fails randomly over cellular (AT&T Wireless). I have my AT&T wireless service through TracFone, who buys access from AT&T. Here's the kicker: I have configured my account on two friends' phones who have wireless service directly with AT&T and it *works* 100% of the time.
This would indicate that it's a TracFone/AT&T problem provisioning me on the AT&T network. But my wireless access works 100% of the time for gmail servers, Yahoo email servers, and Comcast email servers (other accounts I have). Also, I can surf all over the web with no errors. It's just when accessing AOL servers. This would indicate it's an AOL problem.
I can exclude email from the scenario by using a low-level TCP client to open port 143 on imap.aol.com. When it works, the port stays open for 60 seconds before the server times me out. When it fails, I see the port open and then immediately close (the server opens the port and then terminates the connection for some reason). Gmail, Yahoo, and Comcast always stay open until the timeout period elapses. Again, indicating somehow AOL doesn't like my connection via Tracfone/AT&T. But how and why??
So far Tracfone, AT&T, and AOL "technical support" have been useless. They each blame the other. There seems to be a lot of knowledgeable people on this Forum, so I figured I'd elaborate on my problem to see if anyone here has some ideas.
I forgot to say that I *love* AquaMail.
-
There have been some reports of problems accessing an IMAP server for a particular mail provider via specific mobile network, - but all I've seen were from Europe.
My understanding is that in most cases the culprit is unclear.
I remember, in one case (about 1-2 months ago) Kostya suggested that in some cases the (sort of low-level) mobile-network configuration option for the network can make a difference. If I remember correctly, that was "Authentication type" PAP vs CHAP (under APN properties). But you might not even have that configured on the US 4G (and probably 3G?) networks. -- I have Verizon Wireless, and neither of the APNs has that configured.
And it is not surprising that the tech-support people send you around and blame it on each other. The low-level (low-skilled, low-paid) support people do not have a clue: it is not in their script. You might have a chance of getting someone reasonable if your request to escalate your problem to the next level of tech.support (at AOL and at Tracfone).
-
Thanks for your suggestions. I had tried PAP before but not CHAP. Just tried CHAP -- same result (intermittent access).
This is a very nasty problem. And it only happens accessing AOL servers. pop.verizon.net fails 100% of the time. pop.aol.com fails less. And imap.aol.com fails the least, but still can fail for an extended period of time (during which time I don't get email).
The problem supposedly has been escalated to AOL's Level 2 support, but they have not been effective. When you call in a problem, you get a call center in the Philippines. Those people try to transcribe the problem in a problem report, but they have limited knowledge of what you are trying to describe (especially with this problem). So, the Level 2 people get a fractured version of what's going on and I get back a ridiculous "solution".
I am sure that if I could talk to the right technical person at AOL they would be able to identify the problem pretty quickly. I have given them a wealth of information (but I don't know how much of that was successfully transcribed). Unfortunately, given their support structure, that doesn't look possible.
I might mention that on other boards I have heard from other people who are having the same problem. One person has Cricket service. Another has Consumer Cellular. Both AT&T MVNO's. I'm surprised it hasn't affected more people, but I think when it does people just look for a work-around (like using the AOL email app) or switch to Gmail.
What/how AOL is disliking something coming in from an AT&T MVNO totally has me stymied. I was totally shocked when I configured my email account on two phones with direct AT&T service and it worked fine. This problem is nasty.
Since the migration, AOL charges for technical support. So far, it has been a waste of money for me.
-
The following question is probably best answered by Kostya, if he has the time:
When Aqua displays the error bubble ""Error checking mail. Error connecting.", is there some way I can display more information about the error? Something that would help me direct AOL Level 2 technical support to a cause & possible solution? Set some kind of developer mode flag -- or download (temporarily) a developer version of Aqua?
-
AOL support costs money? - Ouch!... I wouldn't pay for that if they haven't resolved a bit.
While Kostya is getting to it, - I'll try to give you one possibility of what you can try yourself: enable the debug log (as described in Kostya's postings signature), try to connect (to recreate the error), disable debug log and take a look at it, it will show you what is happening. It's a bit "cryptic" but you can figure out at which stage the error occurs. You might want to compare to the debug log taken during the period when a successful connection is made.
-
While Kostya is getting to it, - I'll try to give you one possibility of what you can try yourself: enable the debug log (as described in Kostya's postings signature), try to connect (to recreate the error), disable debug log and take a look at it, it will show you what is happening.
Thanks again.
Wow, what level of detail in the log file. I looked at a single sync attempt for one folder in one account. Probably 400 events (11 pages of text), logged to the thousandth of a second. Makes one appreciate Aqua's internal complexity.
I'm scanning a "good" sync attempt now to get an idea of what a successful one looks like. Then I'll scan a bad one. Ironically, I can't seem to cause the problem now. I've synced the accounts 100+ times and they've all worked. I know it's just a matter of time, though, and they'll start to fail again ...
-
Re: Then I'll scan a bad one. Ironically, I can't seem to cause the problem now.
On a bad one, since the app will be trying to connect, you should see some sort of "Exception" (a Java Exception call stack) with a fairly detailed low level message coming from deep inside Android's networking libraries.
Roughly - roughly - similar to this:
https://stackoverflow.com/questions/3988788
-
On a bad one, since the app will be trying to connect, you should see some sort of "Exception" (a Java Exception call stack) with a fairly detailed low level message coming from deep inside Android's networking libraries.
Studying the "good" one, the log appears to have enough info for this problem that I should not have to enable "Log raw data" (I don't have it enabled now).
Is that true, or should I enable it before trying to catch a "bad" one?
-
What a goldmine! I have to find a way to get this info directly to AOL Level 2. No more trying to transcribe the problem.
For some reason, today I'm having a hard time creating the problem. But I had noticed in the past that I could almost never set up the accounts via my wireless connection. Of course, if I switched immediately to WiFi *without changing anything*, the setup would go through fine.
So, I called up Aqua's "Account Setup" screen, pressed "manual", and just paged through the screens (without changing anything). When Aqua tried to verify the settings, I got:
"Incoming mail server (IMAP): Error connecting. Unexpected end of network stream. Please make sure the data is correct."
Did I mention that I *love* Aqua's error detection and reporting? An obvious step way above other applications I have used.
Anyway, here's a snapshot of the attempt to verify the account settings:
[org.kman.AquaMail.mail.MailAccount@42ea6158: id = 10002, username = Lee, email = XXXX@verizon.net, name = XXXX - Verizon (IMAP)]]
2017.06.23 15:23:31.048 -0400 [NETWRK.415] Request for connection content://org.kman.AquaMail.data/accounts/10002/test/imap to [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
2017.06.23 15:23:31.049 -0400 [POWER.415] >>>>> Acquiring wake lock for MailConnectionManager
2017.06.23 15:23:31.051 -0400 [POWER.415] Acquired wake lock flag 0x01000000, result 0x05000000
2017.06.23 15:23:31.055 -0400 LockManager ... Wake lock already held
2017.06.23 15:23:31.063 -0400 [NETWRK.415] Semaphore acquire for [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
2017.06.23 15:23:31.064 -0400 [NETWRK.415] Connecting to [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
2017.06.23 15:23:31.067 -0400 [NETWRK.415] Resolving address for imap.aol.com
2017.06.23 15:23:31.139 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.0.98
2017.06.23 15:23:31.140 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.3.65
2017.06.23 15:23:31.144 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.3.66
2017.06.23 15:23:31.155 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.0.65
2017.06.23 15:23:31.155 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.0.97
2017.06.23 15:23:31.156 -0400 [NETWRK.415] IPv4: imap.aol.com/152.163.0.66
2017.06.23 15:23:31.159 -0400 [NETWRK.415] Trying: imap.aol.com/152.163.0.98:143
2017.06.23 15:23:31.216 -0400 [NETWRK.415] Socket connection completed
2017.06.23 15:23:31.217 -0400 [NETWRK.415] Connection to [imap.aol.com:143, tlsStrict, login = 0, pass present = true] completed: imap.aol.com/152.163.0.98:143, time = 0.15 sec
2017.06.23 15:23:31.218 -0400 [NETWRK.415] Buffer sizes: 1048576 send, 1048576 receive
2017.06.23 15:23:31.306 -0400 [NETWRK.415] ***** ERROR: Error in onConnected [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
java.io.EOFException: Unexpected end of network stream
at org.kman.AquaMail.e.k.c(SourceFile:300)
at org.kman.AquaMail.e.k.h(SourceFile:305)
at org.kman.AquaMail.e.k.c(SourceFile:84)
at org.kman.AquaMail.e.k.a(SourceFile:59)
at org.kman.AquaMail.mail.imap.aw.a(SourceFile:153)
at org.kman.AquaMail.net.o.a(SourceFile:219)
at org.kman.AquaMail.net.j.a(SourceFile:280)
at org.kman.AquaMail.mail.imap.bq.c(SourceFile:69)
at org.kman.AquaMail.core.t.a(SourceFile:76)
at org.kman.AquaMail.core.w.run(SourceFile:621)
at java.lang.Thread.run(Thread.java:841)
Last data:
kman6 LOGOUT
Result for kman6: 0 LOGOUT completed
Thread id:
415
2017.06.23 15:23:31.314 -0400 [NETWRK.415] Closing socket Socket[address=imap.aol.com/152.163.0.98,port=143,localPort=42143]
2017.06.23 15:23:31.316 -0400 [NETWRK.415] Semaphore release for [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
2017.06.23 15:23:31.324 -0400 [NETWRK.415] ***** ERROR: Unable to connect to [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
java.io.EOFException: Unexpected end of network stream
at org.kman.AquaMail.e.k.c(SourceFile:300)
at org.kman.AquaMail.e.k.h(SourceFile:305)
at org.kman.AquaMail.e.k.c(SourceFile:84)
at org.kman.AquaMail.e.k.a(SourceFile:59)
at org.kman.AquaMail.mail.imap.aw.a(SourceFile:153)
at org.kman.AquaMail.net.o.a(SourceFile:219)
at org.kman.AquaMail.net.j.a(SourceFile:280)
at org.kman.AquaMail.mail.imap.bq.c(SourceFile:69)
at org.kman.AquaMail.core.t.a(SourceFile:76)
at org.kman.AquaMail.core.w.run(SourceFile:621)
at java.lang.Thread.run(Thread.java:841)
Last data:
kman6 LOGOUT
Result for kman6: 0 LOGOUT completed
Thread id:
415
2017.06.23 15:23:31.332 -0400 [POWER.415] >>>>> Releasing wake lock for MailConnectionManager
2017.06.23 15:23:31.333 -0400 [POWER.415] Released wake lock flag 0x01000000, result 0x04000000
2017.06.23 15:23:31.335 -0400 [NETWRK.415] Error connecting for account check imap.aol.com:143 - java.io.EOFException: Unexpected end of network stream
2017.06.23 15:23:31.341 -0400 MailStateWatcher Service state change uri: content://org.kman.AquaMail.data/accounts/10002/test/imap, what: 101, aux = 0xfffffffe
2017.06.23 15:23:31.347 -0400 [TASKS.415] Task [org.kman.AquaMail.mail.imap.bq@427933b0, u = content://org.kman.AquaMail.data/accounts/10002/test/imap, t = 276698, a = [org.kman.AquaMail.mail.MailAccount@42ea6158: id = 10002, username = Lee, email = XXXX@verizon.net, name = XXXX - Verizon (IMAP)]] took 0.30 seconds to process
2017.06.23 15:23:31.348 -0400 [NETWRK.415] Network usage: 0/0 bytes read/written
2017.06.23 15:23:31.352 -0400 [LOCKS.415] release for 10002
2017.06.23 15:23:31.356 -0400 [POWER.415] Can't release wake lock because of: [org.kman.AquaMail.mail.e.s@42921df8, u = content://org.kman.AquaMail.data/accounts/10002/test/smtp, t = 276699, a =
Immediately after that, Aqua tried to verify the SMTP settings. That looks like it worked this time, although I have seen it occasionally say it couldn't validate my account credentials:
2017.06.23 15:23:31.386 -0400 [NETWRK.415] Connecting to [smtp.aol.com:465, sslStrict, login = 256, pass present = true]
2017.06.23 15:23:31.387 -0400 [NETWRK.415] Using strict SSL/STARTTLS factory
2017.06.23 15:23:31.388 -0400 [NETWRK.415] Resolving address for smtp.aol.com
2017.06.23 15:23:31.391 -0400 [NETWRK.415] IPv4: smtp.aol.com/152.163.0.69
2017.06.23 15:23:31.396 -0400 [NETWRK.415] Trying: smtp.aol.com/152.163.0.69:465
2017.06.23 15:23:31.398 -0400 SSLHardening Setting SSL ciphers: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, TLS_ECDH_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA, TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDHE_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_RC4_128_MD5, TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_DH_anon_WITH_AES_256_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_ECDH_anon_WITH_NULL_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
2017.06.23 15:23:31.422 -0400 SSLHardening Setting SSL protocols: [TLSv1.2, TLSv1.1, TLSv1]
2017.06.23 15:23:31.504 -0400 [NETWRK.415] Socket connection completed
2017.06.23 15:23:33.879 -0400 [NETWRK.415] Connection to [smtp.aol.com:465, sslStrict, login = 256, pass present = true] completed: smtp.aol.com/152.163.0.69:465, time = 2.49 sec
2017.06.23 15:23:33.880 -0400 [NETWRK.415] Buffer sizes: 1048576 send, 1048576 receive
2017.06.23 15:23:33.894 -0400 [NETWRK.415] Encryption: protocol TLSv1, cipher TLS_RSA_WITH_AES_256_CBC_SHA
2017.06.23 15:23:33.933 -0400 [SMTP.415] Data is <417>:
220-mtaout-aan02.mx.aol.com ESMTP MUA/Third Party Client Interface
220-AOL and its affiliated companies do not
220-authorize the use of its proprietary computers and computer
220-networks to accept, transmit, or distribute unsolicited bulk
220-e-mail sent from the internet.
220-Effective immediately:
220-AOL may no longer accept connections from IP addresses
220 which no reverse-DNS (PTR record) assigned.
2017.06.23 15:23:33.934 -0400 [SMTP.415] Resp [read greeting]: 220-mtaout-aan02.mx.aol.com ESMTP MUA/Third Party Client Interface
Can I unquestionably tell (and show) AOL that it's their problem -- that AT&T got me there and that they're not the ones who unexpectedly closed the imap.aol.com connection? Any insights into the interpretation of the above data most appreciated.
-
To add more info, I tried port 993/SSL. I'm getting this intermittent error from Aqua:
"Incoming mail server (IMAP): Error connecting. Connection closed by peer. Please make sure the data is correct."
Haven't seen the "Unexpected end of network stream" error yet.
-
Thanks.
The SMTP server isn't liking your device's IP address.
The "no reverse PTR - no service" has been called flat out wrong in various places on the Internet -- on the other hand, your mobile provider *should* assign DNS names to client IPs. So this one is "mutual".
For IMAP, the server is supposed to seed a "greeting" immediately upon connecting - but it aborts the connection instead.
The "Unexpected end of network stream" and "Connection closed by peer" are pretty much the same. I suppose it you used SSL + port 993, you'd be getting "SSL handshake errors" instead. Again, same thing - the network connecting getting unexpectedly closed from AOL's side (probably same "DNS" policy, I'd guess).
And speaking of next steps --
The SMTP server sends an error message that spells everything out completely, i.e. it's deliberate on AOL's part.
But there is a good chance that they (even if you get through to the right people) will just tell you that it's a company policy and cannot be changed, and ask you to talk to your Internet provider (whether landline or mobile).
Ugly...
-
The SMTP server isn't liking your device's IP address.
Many thanks for your analysis, Kostya. I think I confused the issue, though.
The smtp server connection actually worked in this case (the connection was not prematurely terminated). I included it as an example of what a "successful" connection looks like. smtp connections have failed in the past, but not this time. The text at 15:23:33.933 is standard boilerplate they always send out, I think.
Can you analyze the first part -- the connection to imap.aol.com? That's the one that got prematurely terminated in this case. And, remember, it works *intermittently*; it doesn't fail all the time. So, it's not a blanket rejection policy.
Your help is most appreciated. This is more progress than I've made in 6 weeks talking to TracFone, AT&T, and AOL combined.
-
Oh so the SMTP worked after that "policy warning"? Sorry I missed that.
Re: IMAP
ERROR: Error in onConnected [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
java.io.EOFException: Unexpected end of network stream
That's all we know. The "basic" (non-encrypted) socket connected worked, and the app was expecting the server to send a "greeting", but that failed.
The greeting normally looks like this (the "* OK IMAP4 ready", the exact string may vary, but there has to be one).
$ telnet imap.aol.com 143
Trying 64.12.88.130...
Connected to nginx.mx.aol.com.aol.akadns.net.
Escape character is '^]'.
* OK IMAP4 ready
And it didn't even get that far.
Looking at timestamps, the connection was aborted immediately (i.e. there was no delay for a time-out), either from the server's side or by the network between the device and the server:
2017.06.23 15:23:31.217 -0400 [NETWRK.415] Connection to [imap.aol.com:143, tlsStrict, login = 0, pass present = true] completed: imap.aol.com/152.163.0.98:143, time = 0.15 sec
2017.06.23 15:23:31.218 -0400 [NETWRK.415] Buffer sizes: 1048576 send, 1048576 receive
2017.06.23 15:23:31.306 -0400 [NETWRK.415] ***** ERROR: Error in onConnected [imap.aol.com:143, tlsStrict, login = 0, pass present = true]
I'd say you could try imap.aol.com + SSL + port 993, but then it might start failing during the "SSL handshake", which would be same thing really.
-
Looking at timestamps, the connection was aborted immediately (i.e. there was no delay for a time-out), either from the server's side or by the network between the device and the server:
That's what I was afraid of: the trace doesn't show exactly who closed the connection? It could be either AT&T's or AOL's fault?
I'd say you could try imap.aol.com + SSL + port 993, but then it might start failing during the "SSL handshake", which would be same thing really.
Yes, I did try that. That's when I got:
"Incoming mail server (IMAP): Error connecting. Connection closed by peer. Please make sure the data is correct."
You're more knowledgeable in this area than I am. What's your "best guess" as to whose problem it is? Here's a high-level summary of key observations:
1. imap.aol.com/143 works 100% of the time over Verizon WiFi
2. imap.aol.com/143 works 100% of the time over AT&T Wireless (direct, no MVNO)
3. imap.aol.com/143 fails occasionally (randomly) over AT&T Wireless (TracFone MVNO)
4. We can see that the (TracFone) connection to imap.aol.com is made (AT&T is not blocking the IP address; AT&T is "getting us there"), but then occasionally (randomly) the connection is immediately terminated.
5. AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers
6. AT&T Wireless (via TracFone) works 100% of the time to Amazon, Ebay, YouTube, Wikipedia, etc.
And, here's something I just tried:
7. If I use a low-level utility (like Telnet) to open port 80 on imap.aol.com (via Tracfone), the port opens successfully and times out in about 15 seconds. The connection does *not* immediately terminate on port 80!
I am hoping you see something in these observations that I am missing!
-
Re: That's what I was afraid of: the trace doesn't show exactly who closed the connection? It could be either AT&T's or AOL's fault?
I can't tell -- all I know is that it wasn't the app.
Probably the only way to tell is to run a low level network packet capture - but as it's not something I do often, I'm not in a position to provide "5 easy steps" for that. I'd just guess that it's only possible on a rooted Android device.
Re: What's your "best guess" as to whose problem it is? Here's a high-level summary of key observations:
Looking at those stats - looks like AT&T or TracFone (and I had no idea what TracFone or MVNO are... had to Google it).
And yet:
5. AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers
AOL could be doing load balancing based on "your" IP address too which may on a different subnet when using TracFone. Or a thousand other factors that I can even begin to imagine.
---
I'm actually a complete ignoramus when it comes to low level networking -- sure I know what IP addresses and just a bit about routing and such to be dangerous as they say, but...
Just to give you an example of things that happen.
Some time ago I was having issues accessing certain web sites from home. Anything Yahoo and AOL (IIRC), but no issues with any other web sites (that I've tried).
The packets would apparently not get through.
The ISP's technical support said everything was fine for them (from the call center).
The ISP's customer support said everything was fine for them too (from their office).
Two techs came into my apartment, connected their laptop to my network cable, everything was fine again.
And then - only when they used my account on their laptop, they started seeing the issue themselves.
The "bad" web sites had nothing in common, in seemed - their IP addresses varied a lot, from the first byte.
And yet...
Anyway, they were able to fix it, but "the moral of the story" is - networking issues can be weird.
-
Looking at those stats - looks like AT&T or TracFone (and I had no idea what TracFone or MVNO are... had to Google it).
And yet:
5. AT&T Wireless (via TracFone) works 100% of the time to Gmail, Yahoo, and Comcast email servers
And also #7 -- changing to port 80 the connection to imap.aol.com works! To me, that smells like it's not AT&T, but rather AOL (disliking something on port 143).
A collection of conflicting observations. Nasty!
This has still been more progress than 6 weeks of vendor turmoil. I'm going to try to get this trace sent to AOL. If you or anyone else thinks of something I would be most appreciative.
-
And also #7 -- changing to port 80 the connection to imap.aol.com works! To me, that smells like it's not AT&T, but rather AOL (disliking something on port 143).
Am I correct in saying that AT&T would have no knowledge/sensitivity to what port the user (me) was trying to open? That is, to AT&T the important thing is the destination IP address. It's oblivious to the fact that, in the packet's data, port 80 is being opened rather than 143?
The destination machine (imap.aol.com) would be the only one sensitive to the port #, extract it from the packet, and take "appropriate" action?
-
Re: And also #7 -- changing to port 80 the connection to imap.aol.com works!
It would be very unusual for an IMAP server to listen on a port # that's used for HTTP.
And personally I can't get a connection to imap.aol.com : 80 here (using telnet).
Am I correct in saying that AT&T would have no knowledge/sensitivity to what port the user (me) was trying to open? That is, to AT&T the important thing is the destination IP address. It's oblivious to the fact that, in the packet's data, port 80 is being opened rather than 143?
In theory, no difference. In practice ... there could be anything anything at all going on in the intermediate network (as there was something in my story above).
-
ISPs can easily see/distinguish which port you are connecting to.
It is a frequent practice these days for some home and mobile ISPs to close access to certain ports from their networks (e.g. port 25 for outgoing connections, port 80 for incoming, etc.).
I haven't heard any ISPs that would block port 143 for outgoing connections.
Still, if you have problems with that, - I'd consider using port 993 (+SSL).
Regarding specifically AOL, imap.aol.com does not seem to accept connections on port 80. (And why would it? It is not a webserver, and it is a huge organization, so their server functionality (IMAP and Web-servers) is separated.
And I checked that port 80 on amapl.aol.com doesn't accept connections, the same way as for Kostya. Port 143 responds without any problem.
-
Re: And also #7 -- changing to port 80 the connection to imap.aol.com works!
It would be very unusual for an IMAP server to listen on a port # that's used for HTTP.
And personally I can't get a connection to imap.aol.com : 80 here (using telnet).
Thanks, guys. I agree: I couldn't understand why port 80 would be open on a mail server, but I didn't want to argue with what my testing tools were telling me. After your input, I went back and did more testing. The plot thickens ...
I have a tool on my Android phone called PingTools. It has a PortsScanner utility which scans 1000 of the "most common" ports on a server to check if they're open. I just ran it for imap.aol.com and it shows 21, 80, 110, 143, 993, 995, and 8080 as being open. I have another tool on my iPhone (something like Telnet) which tries to open a specified port on a specified server. I tried all those ports on imap.aol.com and *they all opened*. Some closed immediately, and some timed out in 15 seconds or so, but they all opened. Specifically, port 80 timed out in 15 seconds. This was done over wireless AT&T (TracFone).
So, I wondered, why was I seeing something different from you two? I enabled my (Verizon) WiFi and disabled wireless (I had been doing all my testing on my wireless connection since that was how my email had been failing). PortsScanner now reports only *4* ports open: 110, 143, 993, and 995. The iPhone tool successfully opens them all. The tool now (over WiFi) *can't* open 21, 80, and 8080.
Million dollar question: What the heck is going on? How could two different tools, on two different phones, agree that they see 3 more ports open (for FTP, HTTP, and HTTP) on the AT&T (TracFone) wireless connection than on the Verizon WiFi connection?
StR: Just so I follow you, what server did you mean by "amapl.aol.com"?
-
Sorry, that was the work of the automatic spelling corrector. IMAP.aol.com.
On different networks you have different DNS servers. If you cam, find out what IP addresss you are connecting to while on Tracfone/att network. It sounds like tracfone SMS redirects your connection to a different server.
BTW, what prompts/server responses are you getting for that suspicious host while opening ports in telnet?
In the mean time,in Aquq.Sol, you can try configuring the server manually, using its IP address.
-
If you cam, find out what IP addresss you are connecting to while on Tracfone/att network. It sounds like tracfone SMS redirects your connection to a different server.
BTW, what prompts/server responses are you getting for that suspicious host while opening ports in telnet?
It looks like imap.aol.com can translate into 12 (or possibly more) IP addresses due to load balancing. Here are the ones I've found so far:
64.12.88.129 - 4,7
64.12.88.130 - 4
64.12.88.161 - 4
64.12.88.162 - 4,7
64.12.91.193 - 4,7
64.12.91.194 - 4,5,7
152.163.0.65 - 4,6
152.163.0.66 - 4,7
152.163.0.97 - 4,7
152.163.0.98 - 4,7
152.163.3.65 - 4
152.163.3.66 - 4,7
The numbers following the IP addresses are the # of ports the PortScanner found open on that machine when accessing it over WiFi (first number) and AT&T (TracFone) Wireless (second number(s)).
Note that both WiFi and Wireless could translate to addresses in either the 64.12.x.x or 152.163.x.x range. It's not like one always translated to 64.12.x.x and the other to 152.163.x.x. I think if I tested long enough, I could have gotten each connection method to access all the servers (it just got too tedious & time consuming for me).
Note that, over WiFi, only 4 ports are consistently found open: 110, 143, 993, and 995. Over cellular I always get them and possibly more -- usually 7 but sometimes (rarely -- it could be a bug in the app) only 5 or 6. The extra ports are always 21, 80, or 8080.
And, with my TCP client, I can open those bogus (21, 80, or 8080) ports on that machine. The app thinks the "open" is succeeding (and then the server times out and closes the port). But only when using AT&T (TracFone) wireless. When using WiFi, the app hangs trying to open the port and I have to cancel the "open" manually.
OK, assuming we *know* that ports 21, 80, and 8080 are not really open on a real imap.aol.com machine, how is AT&T (TracFone) making it look like the ports really are there??
BTW, what prompts/server responses are you getting for that suspicious host while opening ports in telnet?
I don't use Telnet; I use a utility that only knows how to open a specified port on a specified server. It doesn't know any protocol. It displays anything the server sends. If I want to send anything, I have to key it in (which I never do -- I'm only using this tool to see if I can open a port on a specific machine). For example, when I open port 143 on imap.aol.com, I get "OK IMAP4 ready" and then I manually close the connection.
I just tried to open ports 21, 80, and 8080 on imap.aol.com using AT&T (TracFone) wireless. I get "Connection Success" from the app, but nothing from the server. Strange. Do you know what I should I get from a "real" server for each of those ports?
-
More interesting info for this nasty problem:
I just installed a VPN app. I haven't seen a failure since I started it. As soon as I stop it, the intermittent errors return. Does this tell us anything about where the "fault" may lie?
A very interesting observation is that as I watch the app (TunnelBear) start up, if I have WiFi enabled it seems to connect to its server pretty quickly. If I have wireless enabled, it churns for a while, says "Can't connect. Trying another way.", and then successfully connects. It doesn't say what the "other way" is that it's trying, but it does successfully connect. If I switch back to WiFi while it is connected via wireless, it complains again, tries "another way", and successfully connects. It doesn't matter for the purpose of solving this problem, but I figured I'd document it for anyone who may read this thread in the future.
So, knowing that using a VPN gets around this problem, does that cast more suspicion on AT&T or on AOL?
-
Based on what you wrote - seems that a TracFone issue is more likely.
Especially with your data points re: VPN and "extra" port numbers (weird! port 21 is FTP!) - those ports must be a side effect of "something" they're doing (proxying all connections?).
I'd also try to replace imap.aol.com with one of those IP addresses above - maybe the issue only happens for 64.* and not for 152.* or vice versa?
-
I'd also try to replace imap.aol.com with one of those IP addresses above - maybe the issue only happens for 64.* and not for 152.* or vice versa?
Thanks, will try. How do I do that? Directly on the Account Setup screen? StR mentioned "Aquq.Sol" in a previous post, but I don't know how to access that.
-
I have 2 accounts configured in Aqua. Tried a 64.* address in one account and a 152.* address in the other. Both failed on the first try (at least I didn't have to retry them many times!). Picked two more addresses and tried them. Again, failed on first try.
I'm leaning towards that it's an AT&T problem, too. Not TracFone, but AT&T. TracFone is just a "front-end" billing service. They have no technical expertise or technical responsibilities to speak of (and basically no detailed technical support, unfortunately). They just pre-buy time from AT&T and enable the account with AT&T. AT&T, however, does know who is an MVNO customer. They read my APN file, which must have an "APN name" field of "reseller". I know that if I change it to anything else I get no internet access at all. So, they know who is a reseller (MVNO) customer and who is a direct AT&T customer. The confusing part is why it happens only with AOL servers (Gmail and Yahoo servers work fine) and why it's intermittent. I've concentrated on imap.aol.com to keep things simple in this thread, but it also happens (more frequently) with pop.aol.com and pop.verizon.net.
When we saw the connection close immediately in Aqua's debug trace, I'm not sure we were really talking to an imap.aol.com machine. We might have been talking to some kind of "bogus" machine with those phantom 7 ports open. Some kind of DNS/routing error on the part of AT&T? Confusing part there: Aqua never had the chance to log in. Some machine definitely allowed Aqua to open the port but then the connection evaporated before the login.
I have never seen PortScanner report only 4 imap.aol.com ports open over Wireless. It's always 7. And, yet, Aqua does successfully fetch email (intermittently). That would indicate it really is imap.aol.com we're talking to.
What a nasty, nasty problem.
-
More testing:
I have Alto loaded on my phone. That's AOL's "slimmed down" email app. Their email app does news, too. I just want email.
Alto does not make visible to what servers & ports it's connecting and what authentication methods it's using. It uses PUSH, but everything after that is a mystery (at least to me).
I hit an extended period of failures tonight and decided to check how long it would take an email to get to Alto. Sending it from my computer, it was immediate. I then enabled PUSH in Aqua on one of my accounts and sent another email. Immediate to both Aqua and Alto. I then tried polling for email on both accounts (to try to verify that they were still stalled) and both failed. So, PUSHed email has no trouble coming down even when polling in the other direction fails.
I then tried to send two emails out of my phone. Alto sent its out, but Aqua couldn't. There is a window there -- betweeen the time Alto tried it and when Aqua tried it. Alto could have gotten "lucky" with its connection attempt. Does anyone happen to know how Alto (or probably the email app, too) configures its outbound email? I could try that in Aqua if I knew.
Two questions:
1. I see Aqua has a "Push mail session duration" parameter. It defaults to 1 hour. What benefit would I get if I set it to 2 hours?
2. How much more does PUSH drain the battery compared to a 10-minute polling cycle? Should I keep polling enabled, too? If I used it, I would use it only on one account. The other account would stay exclusively polled.
-
As I wrote in my previous post, "Aquq.Sol" was a typo... it was meant to be "Aquamail".
Well, you've tried configuring IP address directly, as I (and then Kostya) was suggesting.
So, it doesn't look like Tracfone modifies DNS resolution of the addresses. However, it appears that it (or AT&T for Tracfone users) might be using some type of proxy (and a weird one). And that proxy is what likely creates the problem.
-
However, it appears that it (or AT&T for Tracfone users) might be using some type of proxy (and a weird one). And that proxy is what likely creates the problem.
+1 to that.
And -- at this point I don't think I can be any more helpful.
( but wait, with what little help I did give -- I can't be any *less* helpful either! )
-
( but wait, with what little help I did give -- I can't be any *less* helpful either! )
On the contrary, you and StR have been most helpful. The most progress I've made on this problem in 7 weeks. AOL and TracFone "technical support" are the ones who haven't been helpful.
I have been studying the behavior of AOL's email app named "Alto". It uses PUSH for inbound email and doesn't seem to fail. I have enabled PUSH for Aqua, and it hasn't failed either.
For outbound email, I haven't seen Alto fail. I think it's more than "luck" (avoiding the intermittent connection error) because I can get Aqua to fail (sending) fairly often. That means Alto is setting up the account differently than I have things configured in Aqua (smtp.aol.com/465/SSL -- I've also tried smtp.aol.com/587/STARTTLS). If I could figure out what Alto is doing, I could configure Aqua the same way. Of course, they have things "buried" in Alto and not displayable. I've Googled for the answer, but no luck. Do either of you two have some suggestions on how Alto might be configured for outbound email?
-
A mail provider's own mail app *could* use entirely different network protocols (i.e. not IMAP / SMTP) and entirely different servers.
Its network traffic also *could* be based on HTTP(s) so it's more compatible with that weird proxy. Its push *could* be based on GCM (Google Cloud Messaging) and not maintaining a persistent IMAP connection (Aqua).
-
A mail provider's own mail app *could* use entirely different network protocols (i.e. not IMAP / SMTP) and entirely different servers.
Its network traffic also *could* be based on HTTP(s) so it's more compatible with that weird proxy. Its push *could* be based on GCM (Google Cloud Messaging) and not maintaining a persistent IMAP connection (Aqua).
You, sir, are an email guru. I have been telling my friends in Philadelphia how good Aqua is and how knowledgeable you are. Plus, generous of your time to spend so much of it on the Forum. You have confirmed my opinions.
I have exercised Aqua's error detection, reporting, and recovery probably more than any of your other users have. Exceptional. I recognized from the start that it was a (super) quality product. Congratulations. I could go on, but I have probably embarrassed you enough already.
Now, back to your post. I think you have hit the nail on the head. I installed a sniffer on my phone yesterday and watched one small outbound email. I couldn't see everything because some of it was encrypted, but there was enough clear text to get an idea of what was going on.
They are sending packets to the following sites:
1. amazonaws.com (yes, you read that right, Amazon Web Services. It's not GCM, but same services.)
2. omtrdc.net (Adobe Marketing Cloud)
3. 192.229.162.144 (MCI/Verizon!)
4. akamaitechnologies.com (Akamai Technologies)
And, all of these packets are directed to port 443 (HTTPS), as you suggested they might. The access to Adobe Marketing Cloud concerns me. I don't remember allowing them to do that when installing Alto.
They are also accessing the following sites within those packets. The text in quotes is from the web site:
1. crashlytics.com (app crash analysis)
2. b.aol.com
3. s.sa.aol.com
4. rpc.mail.aol.com
5. urbanairship.com ("individualized messaging to any marketing channel")
6. fiksu.com ("target and retain high-quality mobile audiences")
7. demdex.net ("store and make sense of behavioral data")
Nowhere in the trace did I see "smtp.aol.com". So, you are right, they are using a completely different mechanism in Alto. So much for trying to configure Aqua to mimic it!
-
These are probably the real servers (and they're not IMAP / SMTP...)
amazonaws.com
Maybe used for image / attachment storage?
rpc.mail.aol.com
RPC - Remote Procedure Call? The actual email API?
Resolves to mail.aol.com which is their web mail but the APIs could be routed by using distinct HTTP methods and/or URLs.
And this:
urbanairship.com
Is a cross-platform push technology provider (on Android - probably layered on top of GCM or Firebase Messaging).
So back to the issue at hand - AOL's mail app is not a meaningful comparison, since it's built on an entirely different tech. stack.
-
These are probably the real servers (and they're not IMAP / SMTP...)
amazonaws.com
Maybe used for image / attachment storage?
There were no images or attachments in my test email. The aws.amazon.com web site lists a whole page of web services, including "Network & Content Delivery" and "Mobile Services". Could be one of those, or something else. It was by far the most frequently-accessed site. Out of 19 outbound packets, it was the target 13 times.
So back to the issue at hand - AOL's mail app is not a meaningful comparison, since it's built on an entirely different tech. stack.
Agreed. I'm going to uninstall Alto and live with the intermittent connection failures using Aqua. Can't learn anything more from Alto.
An important observation about Alto: unlike Aqua, it grows without bounds. Aqua stores a "sync size" window of emails, but Alto stores your whole inbox. Unless you delete emails, it continues to grow. And, if you delete emails to clean up, Alto deletes them back on the server (because it's IMAP). You lose your email history.
As of last Friday (6/30/17) AOL has declared it's "definitely not our problem". Supposedly they analyzed the Aqua trace I sent them, but I don't believe it. I think they found a phone which had direct (non-MVNO) AT&T wireless service, configured my account in it, and saw that it worked (same test I had performed weeks ago). Once they saw that, "it's not our problem".
My challenge now is to get TracFone to forward to AT&T Level 2 a written (by me) description of the problem. A transcription of the problem would be rife with errors. This is not going to get solved by TracFone or any other MVNO. It's not their network and they don't have the technical expertise.
-
I think I have come up with a solution to this problem. I wanted to post it here for completeness sake, so that in one thread there is an exhaustive analysis and documented final solution.
I came to the conclusion that it is definitely an AT&T problem. And a problem that only manifests itself when using AT&T cellular services via an MVNO (I located confirmed problem reports from users of TracFone, Cricket, and Consumer Cellular. There may be others. The problem does not occur when using AT&T directly). Achieving a solution was very difficult because AT&T Tech Support will not talk to anyone with service through any of their MVNOs and those MVNOs have abysmal technical support staffs of their own. I had TracFone Corporate Technical Support people in Miami tell me that it was *impossible* for them to send my detailed written description of the problem to AT&T. Hard to believe. They insisted it was Verizon/AOL's problem. But, such is the situation when you have multiple vendors. It's always "the other guy's fault".
I have switched my cellular service from TracFone to the $30/month Metro PCS plan. For me it was a cost-effective solution because I was already paying $20/month (including taxes) for a Verizon land line (which I wanted to terminate). So, for $10 extra per month (most of which I was already paying TracFone anyhow), I got unlimited talk, texts, and 1 GB of high-speed LTE data (3G after that). But, more importantly, my cellular email access problem went away.
Metro PCS uses T-Mobile towers. And, they are significantly more closely integrated with T-Mobile than TracFone (and the others) are "integrated" with AT&T. MetroPCS was taken over by T-Mobile in 2013, so they are actually a subsidiary. This could possibly be the reason why Metro users appear to be provisioned on the T-Mobile network closer to the way actual T-Mobile customers are. I don't know. But the end result is that the Metro->T-Mobile->AOL cellular connection works reliably -- both for POP and IMAP -- and has solved my problem.
Thanks to everyone who has helped me analyze this problem, especially Kostya.
-
Glad you worked it out - and thanks for the detailed write-up, who knows, it might help someone else.
-
Glad you worked it out - and thanks for the detailed write-up, who knows, it might help someone else.
That's why I wanted to complete the thread. Before I hit this problem, I didn't know Aqua Mail existed. To look for work-arounds, I was trying different email clients. No client had the error detection, reporting, and recovery that Aqua did. Or its configurability. Or a debug trace. Aqua helped me zero in on what was going on. I know other people are having this problem. If they discover Aqua and this Forum like I did, they will have an exhaustive description of the problem and the solution I decided on.