Closed Bug 858618 Opened 11 years ago Closed 11 years ago

[Email] Missing From: header makes email app crashing

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::E-Mail
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking-b2g:tef+, b2g18 verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

Status:
VERIFIED FIXED
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
b2g18 --- verified
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified

People

(Reporter: gerard-majax, Assigned: asuth)

Details

(Keywords: crash, Whiteboard: [b2g-crash]) 

Gaia master @ 5a45368, trying to retrieve an email that has no "From:" field makes the email client crashing:

I/GeckoDump(  264): ESC[32mLOG: searchargs:  NOT DELETED SINCE 4-Apr-2013ESC[0m
I/GeckoDump(  264): ESC[32mLOG: SERVER UIDS 31 50ESC[0m
I/GeckoDump(  264): ESC[32mLOG:   new fetched, header processing, INTERNALDATE:  04-Apr-2013 05:50:02 +0200ESC[0m
I/GeckoDump(  264): ESC[32mLOG:   new fetched, header processing, INTERNALDATE:  04-Apr-2013 11:09:21 +0200ESC[0m
I/GeckoDump(  264): ESC[31mERR: Explosion while processing data TypeError: msg.msg.from is undefinedESC[0m
I/GeckoDump(  264): ESC[31mERR: Stack: exports.chewHeaderAndBodyStructure@app://email.gaiamobile.org/js/ext/mailapi/chewlayer.js:1857
I/GeckoDump(  264): onNewMsgEnd@app://email.gaiamobile.org/js/ext/mailapi/imap/protocollayer.js:184
I/GeckoDump(  264): EventEmitter.prototype.emit@app://email.gaiamobile.org/js/ext/mailapi/same-frame-setup.js:5036
I/GeckoDump(  264): processData@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:2201
I/GeckoDump(  264): processData@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:2248
I/GeckoDump(  264): processData@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:2206
I/GeckoDump(  264): processData@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:2248
I/GeckoDump(  264): ImapConnection.prototype.connect/<@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:2102
I/GeckoDump(  264): EventEmitter.prototype.emit@app://email.gaiamobile.org/js/ext/mailapi/same-frame-setup.js:5036
I/GeckoDump(  264): NetSocket.prototype._ondata@app://email.gaiamobile.org/js/ext/mailapi/imap/probe.js:64
I/GeckoDump(  264): ESC[0m
E/GeckoConsole(  264): [JavaScript Error: "[Exception... "'TypeError: msg.msg.from is undefined' when calling method: [nsITCPSocketInternal::callListenerArrayBuffer]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]"]

FYI, the email is a membership renewal for the french legal law announcements, « Légifrance », and is being produced by Atos.
Also, please find the source of the buggy message:

Return-Path: <renouvellement@legifrance.gouv.fr>
X-Original-To: <recipient email>
Delivered-To: <recipient email>
Received: from massmail.mx6.atos.net (massmail.mx6.atos.net [160.92.141.150])
	by lissyx.dyndns.org (Postfix) with ESMTP id 63A3C59F186
	for <<recipient email>>; Thu,  4 Apr 2013 11:08:14 +0200 (CEST)
Received: from localhost.localdomain (opdjo01v.djo.vdm.priv.atos.fr [10.18.101.205])
	by nmail06.priv.atos.fr (Postfix) with ESMTP id ECA07244170
	for <<recipient email>>; Thu,  4 Apr 2013 04:00:13 +0200 (CEST)
To: <recipient email>
Subject: Legifrance - Renouvellement de votre abonnement
Content-Type: text/html
X-Length: 1292
X-UID: 1033605
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2

<HTML><BODY>
<br>Votre abonnement au sommaire actif du Journal Officiel sur votre messagerie, dans le cadre du service public de la diffusion du droit par l'internet, arrive prochainement à expiration. Souhaitez-vous le renouveler pour trois mois ?<BR/><BR/>Pour poursuivre cet abonnement pendant les trois prochains mois, cliquez sur le lien suivant : <BR/><BR/><a href='http://www.legifrance.gouv.fr/abonnement.do?dispatch=renouvellement&key=<recipient email>'>Lien de reabonnement : http://www.legifrance.gouv.fr/abonnement.do?dispatch=renouvellement&key=<recipient email></a>

</HTML></BODY>
qawanted to see if this happens in 1.0.1 and v1-train.
tef? because if that happens this is imho a critical blocker.
blocking-b2g: --- → tef?
Keywords: qawanted
Keywords: crash
Whiteboard: [b2g-crash]
Can you point us to a way to replicate creating an email that has no from header?
(In reply to Marcia Knous [:marcia] from comment #3)
> Can you point us to a way to replicate creating an email that has no from
> header?

Just send an email by hand using nc/telnet, and copy/paste the sample I provided. If it was not obvious, this is a mail that I received, not that has been produced by Gaia email client.
On linux, install the telnet-ssl package. Then run :

telnet-ssl -z ssl mail.mozilla.com 465

and copy paste the following text, putting your email in the "rcpt" line (keep the angle brackets):

ehlo world
mail from: <whatever@gmail.com>
rcpt to: <yourmail@mozilla.com>
data
ehlo world
.
quit

Then you should have a mail without a from header in your mozilla mail box. In my tests it wasn't filtered by postini but if you don't see it you should check there.

(note: I haven't checked if this actually triggers the bug in the email app)
Just tried again: you should copy paste first the 3 first lines, don't forget the last line feed, and only then the remaining lines.
Updated gaia a couple of minutes ago (still master branch) and it seems to be okay.
(In reply to Alexandre LISSY :gerard-majax from comment #7)
> Updated gaia a couple of minutes ago (still master branch) and it seems to
> be okay.

Yeah, I think I fixed this in the local drafts patch on bug 838012 by having us fail-over and just make up an e-mail address 'missing-address@example.com' which should fail to route.  It would be preferable if we could do something like indicate in italics that there was no e-mail address or attempt to infer from routing headers, but those were much more work and messages like this are extremely badly formed.  I also added a try/catch block so in the event that failover logic fails, we will instead just ignore the message.  (However, by ignoring it, we will always try and attempt to synchronzie it in the future, so that's still a very undesirable outcome.  But the circumstances under which we'd fail in that specific fasion are very low, and that might have been the only case.)

:gerard-majax, if you are confirming the fix, maybe we should just mark this as RESOLVED WFM?

And in case you're wondering, no, I didn't magically fix this at the same time, I saw your IRC message and this bug but was in a hurry to land so didn't stop to chat about it.
Uh, but I guess if the fix is desired for tef uplift, we can uplift just that fix.  And/or just uplift the back-end changes for drafts but not the UI.
(In reply to Andrew Sutherland (:asuth) from comment #8)
> :gerard-majax, if you are confirming the fix, maybe we should just mark this
> as RESOLVED WFM?

I was waiting for a feedback from you, I thought this was magic :)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
qawanted to check if this still happening in v1.0.1 and what happens after the e-mail crash, is e-mail still usable afterwards?
Keywords: qawanted
(In reply to Daniel Coloma:dcoloma from comment #11)
> qawanted to check if this still happening in v1.0.1 and what happens after
> the e-mail crash, is e-mail still usable afterwards?

As far as I can tell it's fixed on master. About usability, basically the folder containing the faulty mail is unusable (no sync), but the others are still usables.
(In reply to Alexandre LISSY :gerard-majax from comment #12)
> (In reply to Daniel Coloma:dcoloma from comment #11)
> > qawanted to check if this still happening in v1.0.1 and what happens after
> > the e-mail crash, is e-mail still usable afterwards?
> 
> As far as I can tell it's fixed on master. About usability, basically the
> folder containing the faulty mail is unusable (no sync), but the others are
> still usables.

If this is the case I would say we cannot launch with this bug.
(In reply to Daniel Coloma:dcoloma from comment #13)
> > As far as I can tell it's fixed on master. About usability, basically the
> > folder containing the faulty mail is unusable (no sync), but the others are
> > still usables.
> 
> If this is the case I would say we cannot launch with this bug.

Alexandre's analysis is correct.  As noted, we can uplift just the fix if tef+'d.
Reopening it as we need to fix this in 1.0.1
Status: RESOLVED → REOPENED
blocking-b2g: tef? → tef+
status-b2g18: --- → unaffected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
Resolution: WORKSFORME → ---
Assignee: nobody → bugmail
I've addressed this by uplifting the back-end fixes from the drafts implementation.  Since the v1.0.1 front-end lacks draft capabilities, the draft bits are moot, but we get some other minor fixes and operation handling changes that we are going to want to remain identical across all our branches for the sanity of any correctness uplifts that happen in the future.

landed on gaia/v1.0.1:
https://github.com/mozilla-b2g/gaia/pull/9142
https://github.com/mozilla-b2g/gaia/commit/3e7dda88950ae09166109783adea8181eb857d21
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Julien, 

It seems I am not smart enough to get telnet working quite right.  "Connect closed by foreign host."  Anyway, so I can verify this, can you just send a test email to my mozilla account. Thanks
Tracy, just sent an empty mail to your mail.
Sounds like the qawanted request was satisfied by figuring out this was 1.01 affected - clearing flag.

Feel free to still verify this works now, though.
Keywords: qawanted
Julien, thanks for the test email.

Verified on latest nightly (20130414) unagi build.
status-b2g18-v1.0.1: fixed → verified
Status: RESOLVED → VERIFIED
status-b2g18: fixed → verified
You need to log in before you can comment on or make changes to this bug.