Space after colon violates RFC 5321 (and RFC 821): "Since it has been a common
source of errors, it is worth noting that spaces are not permitted on either
side of the colon following FROM in the MAIL command or TO in the RCPT command"
Change-Id: Ie5330bf2bd01cd8f734134dadd742cf16df70d7a
Signed-off-by: Jack Bates <jack@nottheoilrig.com>
cherry-pick of https://android-review.googlesource.com/#/c/32640/
We seemed to not properly fallback to querying the database if the cache
did not contain a mailbox of a specific type. We may want to consider
caching mailboxes related to PIM data, but for now this is a quick fix.
Also fixes unit tests.
Bug: 5019661
Change-Id: Idcac0a6f15aa7f174890ae586f478fbb8f6e05b7
* No code was harmed, er, changed in the making of this CL
* All that's happened is that code that is needed by both Email and
Exchange have been moved into emailcommon
* This required import changes to many files, which explains the
length of the CL
Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
- Now ProviderContextSetupHelper.getProviderContext() invalidates DB cache
* MailboxAccountLoaderTestCase
- Save hostauth properly
- (ProviderContextSetupHelper invalidates cache before each test)
Bug 3280911
* SmtpSenderUnitTests
- Use ProviderContextSetupHelper to create isolated context,
which now also invalidates DB cache
Bug 3280913
* MailboxFinderTest
- When kicking Controller.Result methods directly from tests,
call the raw callback, rather than the one wrapped with
ControllerResultUiThreadWrapper, to make it synchronous.
Bug 3280898
* MessageViewTest
- Disable testOpenMessage()
This test doesn't work because it sets up test data in an isolated
context but the activity/fragment don't see them because they
use the real context.
I have no idea why it worked before... Maybe because there were
accounts/mailbox/message with the same ID in the DB by chance.
Bug 3280905
Change-Id: I6beb08c58fff102e90bebd2c35f70820268b9e62
* Write MIME-Version: 1.0 in all outbound messages, not just those
with multiparts. This is required by RFC 2045.
* Unit tests
Bug: 1678296
Change-Id: Icf37d93b8b0150f490791792499865a60744adea
When receiving the EHLO response from the SMTP server, the multiline
answer has "-" prefix in all lines except the last line, where the
prefix is a blank. This is according to RFC 2821 section 4.2.1. This has
also been reported as issue 2309 at code.google.com.
Bug: 1744768
Change-Id: I3feccabed30767d2fa5b06352cd7d1c803e8d59c
* Add "Accept all certificates" modes to incoming/outgoing secure choices
* Change URI scheme slightly to make "trust" a flag, not part of the
protocol.
* Change Stores to know about new URI scheme
* Slightly rework Transport API to make "trust" an independent flag
* Adapt HostAuth to handle new Uri scheme
* Remove the old ambiguous "optional" code, which was allowing
some unsigned certificates, but was *also* allowing TLS to
optionally start (though not SSL, despite the UI strings.)
* Add a few unit tests to EmailContent
* Add logging and a bunch of comments to TrustManagerFactory, and a bit
of simple cleanup to make it more readable.
* Add missing conversion of SSLException->CertificateValidationException
in TLS so we get the correct certificate errors from TLS too.
* Re-enable TLS for mac.com accounts (which had a certificate problem)
Fixes bug http://b/2119755, http://b/1374780, and probably a raft of
earlier and/or external bugs about certificate problems.
Change-Id: Iaf99a8da3eaadaa4cdeec224737838b5d6813e55
* Change Sender definition (remove old Message from API) and update
any existing calls through that API
* Rewrite SMTPSender to use provider messages
* Add attachments to RFC822Output
* Minor bugfixes in RFC822Output
* Unit tests