Gaia/Email/Features

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!

Sending Attachments

• Maximum file size
  • The maximum file size of sent attachments is 5 megabytes on v1.1, v1.2 and master. This is done because we are likely to crash if we try and send larger files. bug 871897 is about us switching to streaming for sending which would allow us to remove our send-side limitations. Receiving servers may still enforce a size limit. v1.0.1 has no size limit, but is likely to crash if files larger than 5 megabytes are sent.
• 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 fiels (video/*): YES, v1.1 onwards
  • PDF files, other file tytpes: NO

• 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

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

ActiveSync is supported since v1.0. Our primary test targets are hotmail.com/outlook.com 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:
  • 163.com: Yes, v1.1 onwards.
  • m.gmail.com: 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).

IMAP

• Connection Security
  • STARTTLS: NO, although we want to support it. bug 784816 is the platform bug which must be resolved, bug 847032 is the e-mail bug. (asuth, 2013/05/15)
• Mail Sync Process
  • IDLE-based push notifications: NO. We do use IDLE, but only as a means of keeping the connection alive. We want to support properly handling IDLE events. (asuth, 2013/05/15).

POP3

POP3 support is planned for version 1.3. It is not yet landed.

Security

• Connection Security
  • 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)

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