From MozillaWiki
< Gaia‎ | Email
Jump to: navigation, search

This page is not comprehensive. Right now, think of it as a place where we put answers to questions that are asked when they are asked. If you know the answer to a question, or think you know, please just update this page! Just put who is answering the question and when they are answering it in parens. If you know there is a bug filed on implementing something, or even a WONTFIX bug, please update the page! Thanks!

Also note that all of these values are based on the code that is in the official Mozilla tree. Actual shipping devices may have altered some constants, although hopefully that's not the case.


The Gaia e-mail app has an 'automatic' configuration mechanism which is the default, where the user just enters their display name (what they want their name to look like when sending e-mails), their e-mail address, and their password. This mechanism is derived from Thunderbird's autoconfig mechanism but with changes to support the ActiveSync protocol, slightly stricter security restrictions (encryption is always required!), a lack of domain guessing support (bug 823640), and no current support for trying multiple configurations from the XML configuration file.

See Gaia/Email/Autoconfig for details.

Sending Attachments

  • Maximum aggregate size of all attachments:
    • Future: bug 1040861 will raise the sending limit to 25 MiB. This should probably happen in v2.1 but is not guaranteed.
    • v1.4+: 5 megabytes. bug 982779 fixed the memory-backed blob issues (and other blob issues), so this should all work quite well.
    • v1.3, v1.3t: 5 megabytes. Memory usage should be reduced from this version onwards because bug 871897 implemented send streaming. Because of bug 982779 large memory-backed (as opposed to Device-Storage/IndexedDB file-storage-backed) Blobs may pose a problem, but the Camera app has been fixed in these releases so no built-in apps have this problem.
    • v1.1-v1.2: 5 megabytes, memory usage will be high.
    • v1.0.1: No size limit, likely to crash on 256MB devices if aggregate attachment size exceeds 5 megabytes.
  • Attachment types supported
    • Images (image/*): YES, All versions
    • Audio (audio/*): YES, v1.2 onwards (landed in bug 838008)
    • Video (video/*): YES, v1.2 onwards (landed in bug 838008)
    • PDF: No, although it is just a question of modifying our webapp.manifest
    • Other type: No, although it is just a question of modifying our webapp.manifest

Received Attachments

  • Attachment types supported.
    • note: in v1.0.1, we hard-code the supported type to be image/*, but in v1.1 onwards we let mime_mapper.js decide what we are allowed to download. That is the file to change, but keep in mind that letting us download a file type does not mean we are able to open the file correctly.
    • Images (image/*): YES, v1.0.1 onwards
    • Audio files (audio/*): YES, v1.1 onwards.
    • Video files (video/*): YES, v1.1 onwards
    • PDF files, other file types: NO
  • Maximum allowed size of a single attachment to be downloaded. Note that per the next point, large message downloads may still crash the email app, depending on device memory!
    • v2.0+: 20 MiB. This is nearly no limit. Most mail providers limit mail sizes to 25 MB. We will raise this when we raise the send limit.
    • v1.4: no limit
    • v1.3t: 1 MiB
    • v1.0.1-v1.3: no limit
  • Downloading large attachments
    • v1.3+: A single huge download may crash the app depending on available device memory. bug 871897 improved our cache management of downloaded attachments, but bug 943798 which is dependent on platform improvements means that single attachment downloads may still cause problems.
    • v1.0.1-v1.2: A single huge download or multiple downloads of any size across multiple messages in succession may crash the app if the user does not switch folders or scroll the message list sufficiently to cause the cache to flush the downloaded message.
  • Caveats
    • ActiveSync does not provide the MIME-type for attachments, just the file name. So we need to infer the file type from the file extension.


Sharing URLs from the browser app is supported.

Sent Mail Metadata

  • Mail priority
    • NO In the internet at large, this has primarily only been used by spammers, although it has been known to be used within an organization.
  • Return Receipt / Delivery Status Notification
    • NO.

Received Mail Metadata

  • Return Receipt / Delivery Status Notification
    • NO.

Periodic Mail Synchronization / Push Notification

From version 1.2 onwards you can have the e-mail app automatically wake up and synchronize your e-mail message at various intervals, the lowest of which is every 5 minutes. Currently, we will not turn on wi-fi if it is not already on, so we will use a phone's data-plan if we have it. bug 907028 is about improving this situation. If the device is charging/on wall power, it will not power off wi-fi when the screen goes off, and so wi-fi will be used for periodic sync.

There is currently no support for push notification. What is commonly referred to for ActiveSync purposes for 'push' is effectively the same as what IMAP IDLE/NOTIFY does; they require you to keep a connection alive for a long time, which is not something our devices are capable of doing in their current markets (and with the logic they use about turning off wi-fi when the screen comes off.) In the post-v1.3 time-frame we are going to try and work to establish a standard for allowing IMAP servers to use the simple push notification API by providing plugin implementations, etc.


ActiveSync is supported since v1.0. Our primary test targets are and Microsoft-hosted Exchange servers. If you are using a third-party ActiveSync implementation. Specific third-party server implemenations we know about:

  • Specific Third-party server support:
    • Yes, v1.1 onwards.
    • It works, but do not use it! gmail's ActiveSync implementation has various issues and we do not support using it. See bug 810031 for more information.
  • Mail Sync Process
    • Push notifications per the ActiveSync spec (as opposed to the FxOS push notification support): NO. We want to support it, but be aware that on cellular networks we are unlikely to be able to reliably maintain the persistent connection. (asuth, 2013/05/15).


  • Connection Security
    • STARTTLS: YES, v1.1 onwards. (StartTLS support was uplifted from v1.2 to v1.1 late in the v1.1 cycle.)
  • Mail Sync Process
    • IDLE-based push notifications: NO. In versions 1.0.1 and v1.1 we used IDLE as a means of keeping the connection alive but ignored any information provided to us. In version 1.2 onward we no longer issue the IDLE (or NOP) commands. We do intend to eventually use IDLE/NOTIFY to inform synchronization.


POP3 support is implemented and landed as of v1.3. The server must support UIDL and TOP. These are probed for at account creation time and an error will be reported if they are not supported. See Gaia/Email/Implementation/MailSynchronization#POP3 for important details on our implementation, such as the fact that we always leave messages on the server and never delete them.

On servers where IMAP is freely available to the user, we do not support use of POP3. This is especially true on GMail which uses windowing logic for performance reasons that are not compatible with our always-leave-messages-on-the-server implementation. The reason for this is that IMAP is a much better protocol for the user, the server, and the Firefox OS device. We have a very finite amount of developer resources for the e-mail client, and we think our efforts are best spent improving our IMAP protocol support (or any successor to the IMAP protocol that improves on it.)


  • Connection Security
    • Encrypted connections: YES. Only encrypted connections are supported. See the next point.
    • Unencrypted connections: NO. We require either "SSL" (initially encrypted TLS connections using port 993 for IMAP, port 995 for POP3, https/port 443 for ActiveSync) or "startTLS" (upgrade-to-encrypted connections where we fail if we don't upgrade the connection) to be used. Note that our unit/automated tests do allow unencrypted connections to be created because we do not yet have the capability to easily wrap our fake servers that we use for testing in connections that appear to have valid certificates.
    • Self-signed certificates: NO, unless the certificate is explicitly trusted by gecko or has had an exception created some other way (such as via the web browser). In the past, it was very common to use self-signed certificates because getting a real certificate cost money, and potentially a lot of it. Now, you can get free SSL certificates; at least StartCom provides them here. I discussed a strategy for supporting self-signed certificates with Brian Smith early on in the e-mail app development cycle. Our conclusion was that it's reasonable to support certificate exceptions, but that adding a certificate should be a very deliberate operation and not something a user should just click through. An especially important factor was that mobile devices are much more likely to be on sketchy wi-fi where man-in-the-middle attacks are much more likely than traditional desktop-computer-from-a-trusted-home-network situation that Thunderbird traditionally has been used for. We also determined that certificate exceptions should be added from the settings app. This makes it more deliberate, and also allows the very dangerous API operation of adding certificate exceptions is only accessed from one certified app, rather than exposing it to apps like e-mail which are intended to only be privileged. Since that discussion, the browser app is now capable of adding exceptions, but it is also one of the most privileged (certified) apps around or likely to ever be around. (asuth, 2013/05/21)

PGP and S/MIME support

  • PGP: NO, but being prototyped. There is an effort to prototype support for PGP in Firefox OS and the e-mail app. This effort is being discussed at and the general tracking bug is bug 894817. Note that there is no guarantee the prototype will be completed or integrated into the e-mail app directly.
  • S/MIME: NO. Also tracked by bug 894817.

Message Encodings

  • All sent messages are utf-8 encoded.
  • Received encodings / encoding names are:
    • Anything supported by the WHATWG Encoding Standard's list of encodings
    • A number of aliases we have added that have been observed to exist in the wild either directly by us or which are inherited from other open source code (see revision history and code comments):
      • Our regex transforms can be found here in faux-encoding.js currently. The current list (July 2, 2013) is:
        • The prefixes: "latin", "latin-", and "latin_" are mapped to "iso-8859-".
        • The prefixes, which may be optionally followed by "-" or "_": "windows", "win", "ms" are mapped to "windows-"
        • The prefixes: "utf", "utf-", "utf_" are mapped to "utf-"
        • The values: "usascii", "us_ascii" are mapped to "ascii"
      • Our unit tests of the above file's mapping can be found in test_intl_unit.js