## Environment : Unagi phone, build 2012-12-13 ## Repro : 1. set up an email account 2. compose an email with a receiptient in the to and bcc 3. type in subject and body 4. send ## Expected : 1. email gets delivered to both to and bcc ## Actual : 1. email does not get sent to either recipients ## Note : 1. does not matter if it's hotmail or gmail
5 years ago
blocking-basecamp: --- → ?
bcc not working is pretty serious, so pre-emptively assuming this gets blocking and taking. test_compose.js does not currently exercise the bcc code-path, so this would not be particularly surprising. Preliminary code inspection suggests: - Activesync should not work. The MIME message we generate does not emit the bcc information because of a privacy default in use in the mailcomposer instance. - IMAP/SMTP should work. The privacy default does the right thing, but we explicitly provide the BCC-including envelope to our SMTP code. I will update test_compose.js to include a bcc-only test case and update it to work for live (non-fake) ActiveSync as well as IMAP. Related concerns: - Do we need to do the "To: undisclosed-recipients:;" thing that Thunderbird does if the message only has bcc recipients (no to/cc)? It appears this was primarily a workaround for older versions of sendmail (allegedly pre-8.7) deciding to do crazy things. There doesn't really seem to be a down-side in doing this, but we also are unlikely to be dealing with broken servers. - General bcc leakage concerns. Forwarding is the only thing we do that deals with existing messages. We manually propagate white-listed headers over because we only support inline forwarding. The code has an explicit comment to not copy the bcc over. - Saving the BCC list to the sent folder, non-gmail and gmail cases. gmail automatically appends the message we provide to the SMTP server into the sent folder, so there's some questions there about whether gmail infers bcc's from RCPT TO when not provided in the headers and/or whether it strips the bcc from the message headers. Even if it turns out gmail currently strips bcc's from headers, I'm a bit afraid of potential regressions. It's like a test to see if someone is bulletproof by shooting at them... for non-gmail, we APPEND into the sent folder ourselves, so we can formulate a copy of the message that includes the bcc entries. We currently just reuse what we sent to the SMTP server, which means the bcc's get lost. I think this is undesirable, so I will address this. I think the best way to accomplish this is to move the mailcomposer instance creation from MailBridge._cmd_doneCompose into a more reusable function and just invoke it twice (with different args) in the non-gmail imap+smtp case. This should make it easier to convert to streaming in the future, although this does entail a net performance/garbage hit in the short-term.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
(In reply to Naoki Hirata :nhirata from comment #0) > ## Note : > 1. does not matter if it's hotmail or gmail I just ran the BCC unit test I created and apart from needing to disable the 'bcc' header check for the copy in the sent folder, it passed on both localhost dovecot/postfix IMAP/SMTP and on gmail IMAP/SMTP. The unit test only uses a single bcc with no 'to' because we only do single-account tests currently; it's a difference, but should not affect things. I'd be interested in a logcat from the IMAP failure case; it's probably more interesting than the ActiveSync problem.
provisional unit test and fixes up at: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/100 Good news: For non-gmail IMAP, this makes everything super! The sent folder includes the Bcc headers, but the received message should not regardless of how bad the SMTP server is. This is tested by unit test. gmail loses out on the sent folder information for now, although we could try and see if gmail at least currently scrubs the bcc headers. (We could also manually delete the sent message from the sent folder and then put up the one with the BCC header so we are safe from regressions.) Good news: Sending a BCC message via ActiveSync works insofar as the recipients will receive the message and there are no bcc headers leaked. Bad news: ActiveSync still has it out for us. Although the message in the sent folder gets to keep the list of bcc recipients, it appears we have no way to synchronize that information unless we download the entire MIME message and parse them out ourselves. Specifically, the codepages seem to define To and Cc tags, but no bcc tag. The internet has no additional advice, and we know from our reply header adventures that we can't just ask for the headers for a message without getting the whole thing, attachments and all. The least horrible option that comes to mind is to remember that we sent the message with a bcc and then perform a fix-up when we sync the message in the sent folder. But that's still very horrible and way out of scope for this bug. On the patch: The unit test for test_compose.js now works for the bcc case at least if you run the test with a real ActiveSync account defined via the environment variables GELAM_TEST_ACCOUNT/GELAM_TEST_PASSWORD (and ideally set GELAM_TEST_SLOW=true too). The test knows it won't get a bcc entry, which is why it is green at all. The primary compose test almost works, but it fails because of the HTML up-conversion we still compel as fall-out from gmail's problematic ActiveSync support.
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C3 (12dec-1jan)
Created attachment 693073 [details] [review] https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/100 now that we are blocking, upgrading to review request
Attachment #693073 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 693073 [details] [review] https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/100 Looks good to me!
Attachment #693073 - Flags: review?(squibblyflabbetydoo) → review+
landed on gaia-email-libs-and-more/master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/100 landed on gaia/master: https://github.com/mozilla-b2g/gaia/pull/7057
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Verified Fixed on Unagi build #20121231070201
Status: RESOLVED → VERIFIED
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.