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 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
- We only support sharing images right now, but that's an artificial limit in our manifest.webapp that can and should be removed.
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
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.
ActiveSync
- 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).
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)