Does Aqua Retry Network Errors?

[Kostya Vasilyev]

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! )

[BigbirdPhila]

( 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?

[Kostya Vasilyev]

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).

[BigbirdPhila]

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!

[Kostya Vasilyev]

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.

[BigbirdPhila]

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. 

[BigbirdPhila]

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.

[Kostya Vasilyev]

Glad you worked it out - and thanks for the detailed write-up, who knows, it might help someone else.

[BigbirdPhila]

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.