1. Title : Email client does not support POP3 account 2. Precondition : 3. Tester's Action : Configure a new email account, No option to select POP3 Detailed Symptom (ENG.) : Email client doesnt support configuring POP3 account 5. Expected : Email Client should support configuring a POP3 account 6.Reproducibility: Y 1)Frequency Rate : 100% 7.Gaia Revision: a03f7b532e9998e646d55f93a0fc03a04d7ca7d9

POP3 is intentionally not supported. From an e-mail I sent about this subject: === We made a decision to not implement POP for what amounts to product reasons: - There is no capability to synchronize metadata, nor is there any concept of folders. This is bad if there are any other ways to interact with e-mail, such as other devices or webmail interfaces. - It's an inefficient protocol that does not scale unless we are pulling the messages off the server so that they no longer exist on the server (or no longer appear to exist on the server; this is how gmail can be used, but truly only in support of a single device.) === These statements still hold. Even if there is a service provider that only provides POP3 and supports neither IMAP nor ActiveSync, it seems like our efforts are better spent making it easier for the user to create an account with a provider that does support those comparably far superior protocols. I would suggest this be leo-'d and then I would like to WONTFIX this and we can dupe future requests to this bug.

Product and partner decision to not support in 1.1 release.

Not supported in V1.1

marking WONTFIX because this is currently a fairly permanent decision to not support it

Reopening; partners have indicated that POP3 still has significant usage in various markets devices are planned for where IMAP adoption is low because free mail accounts only provide POP3 or for other reasons. (It's very possible that hipsters are using POP3 ironically, for an example I just made up.) This is likely to be a v1.3 thing unless someone wants to pick it up before then. Prior art to keep in mind is Android's POP3 implementation at https://android.googlesource.com/platform/packages/apps/Email/+/master/src/com/android/email/mail/store/Pop3Store.java Key bits there are (remembering that message numbers are only valid for the lifetime of the connection and the spec does not guarantee anything about messaging ordering, although some servers may try to keep the ordering stable because of rogue POP3 clients out there): - The implementation at a low level only implements leave-on-server semantics. (It's conceivable there might be some higher level retention setting?) Contast with Thunderbird which supports deleting messages off the server as it pulls them off. Deletion, however, will be performed when the user intentionally deletes the messages from the client. - Optimizations are performed to use the single-argument form of LIST and UIDL where there are serious savings expected from not receiving the entire result lists.

We also want to try and make sure we take important cues from the Thunderbird implementation (lives in here: http://mxr.mozilla.org/comm-central/source/mailnews/local/src/): - Specialized error code hints: http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3Protocol.cpp#1228 - XTND XLST support so we can grab specific headers without getting all the headers. See http://tools.ietf.org/html/draft-hansen-pop3-xtndext-00 for details We'll want to consider: - GURL support. This lets the server tell us a URL associated with the account. We could probably chuck this in the settings page so we could let the user launch the browser to display the URL in case there's something useful there. We'll want to ignore: - XSENDER support (Thunderbird WONTFIXed additional support in bug 27191) - XTND XMIT: This would be an alternative to using SMTP for submission. Thunderbird doesn't support this, and I suspect it's probably not really supported by any servers. Definitely not required if Thunderbird doesn't support it.

Key design decisions for our implementation would be: - Do we allow local mail folders to be created and messages moved among them? For efficiency, we'll probably want something like Thunderbird's pop3state.dat that is a compact representation of what we have/haven't synced, so our sync mechanism will be more like an 'incorporate' step like Thunderbird uses for POP3 or movemail, so there would be no need to require the messages to stay in the inbox.

Here's the initial pass at POP3. You'll also need the mail-fakeservers patch from bug 918192 to run the tests -- as of this writing all of the POP3 tests should pass. There's a couple activesync tests that don't when you run the whole test suite but it was like that before. I would have liked to break this into a few smaller chunks, or at least a few well-reasoned commits, but I revised the code over the course of development so much that I think a bunch of non-squashed commits would have just been confusing. As mentioned on IRC, downloading large messages is still an issue. I expect we'll want more unit tests as well; if you see things that are particularly deficient in that area feel free to ask me to write more. I think I'm getting a good handle on the slice and job manager aspects, but those are the areas I'm the least comfortable with and would benefit from a second pair of eyes to make sure I got the flags/params right (particularly in the case of local/remote ops or synchronization gotchas that I might have missed).

Database version talk. I don't think we need to bump the DB version for this, although we may want to do so for the overload case follow-up bug. Notable changes that affect key reps and why they don't require a DB rev. bytesToDownloadForBodyDisplay: The getter provides undefined/falsey => 0 conversion at the MailAPI layer, so the worst-case is that a large IMAP body will not trigger the warning. But it wouldn't have triggered it before either, so this seems fine. new bodyRep type, 'fake': New, only impacts POP3, should be retracted/replaced on full download. Doesn't get rendered thanks to upgrades of assuming-else's to guarded else's. new account type, related composite account refactoring: mcav updated the migration code to assume missing data indicates IMAP and all new account defs provide the data. All other changes were to just support loading either account type or were brand new POP3 stuff; no new IMAP stuff. changeType => changeDetail: This is a runtime thing only.

Gaia unit test failures to address. 1) [email] IMAP protocol dropdown IMAP port selection should change upon selecting STARTTLS: TypeError: port is undefined at (anonymous) (http://email.gaiamobile.org:8080/test/unit/setup_manual_config_protocol_dropdown_test.js:33) at wrapper (http://test-agent.gaiamobile.org:8080/common/test/mocha_generators.js:62) at run (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3709) at runTest (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4081) at (anonymous) (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4127) at next (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4007) at (anonymous) (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4016) at next (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3964) at (anonymous) (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:3984) at (anonymous) (http://test-agent.gaiamobile.org:8080/common/vendor/mocha/mocha.js:4932) Gaia integration test failures all look like this: NoSuchElement: (7) Unable to locate element: .sup-manual-form .sup-manual-imap-username Remote Stack: <none> at Error.MarionetteError (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/error.js:67:13) at Object.Client._handleCallback (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:474:19) at /home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:508:21 at TcpSync.send (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/drivers/tcp-sync.js:94:10) at Object.send (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:455:36) at Object.Client._sendCommand (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:501:19) at Object._findElement (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:1283:19) at Object.findElement (/home/travis/build/mozilla-b2g/gaia/node_modules/marionette-client/lib/marionette/client.js:1332:32) at Object.Email._manualSetupTypeImapUsername (/home/travis/build/mozilla-b2g/gaia/apps/email/test/marionette/lib/email.js:504:7) at Object.Email.manualSetupImapEmail (/home/travis/build/mozilla-b2g/gaia/apps/email/test/marionette/lib/email.js:88:10) at Context.<anonymous> (/home/travis/build/mozilla-b2g/gaia/apps/email/test/marionette/activity_create_email_account_complete_test.js:55:9) at Test.Runnable.run (/home/travis/build/mozilla-

Comment on attachment 828414 [details] GELAM Pull Request.html Ready to land. Woooooooooooooooooooooooooooo! Tests are locally green without hangs for me with the fix on bug 940781. I think we can land them in either order.

Comment on attachment 828416 [details] Gaia Pull Request.html Almost ready to land! Just fix those trivial unit/integration test failures and then let's unleash the horror of POP3 on an unsuspecting populous!

Landed in GELAM, travis looks green: https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/da544eb9c5e7a28c8cccb4d49cc57d8ee548b05a Landed in Gaia, travis also looks green: https://github.com/mozilla-b2g/gaia/commit/093922c5ffc0e051d0d30067238208222725a09d To the future!