1099155 - [email] Investigate whether there's a way to get CoreMail servers (ex: 163.com, 126.com) to not include http download links by using ID or other mechanisms

Status: RESOLVED WONTFIX

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

Description

[Andrew Sutherland [:asuth] (he/him)]

In bug 991489 it was discovered/encountered that when using IMAP with CoreMail, attachments will both be exposed as something we can download normally and also as an http link to a link shortener that then gets bounced to an http download/preview URL.

This is potentially undesirable for a few reasons:
- Mixed metaphors: our download mechanism plus the preview mechanism
- Server rewriting of content can lead to other issues
- It's an http link not an https link.

The verbatim example from that bug was the following link in the email:
 http://u.163.com/t/QcC2zM
which got 302 redirected to:
  http://preview.mail.163.com/xdownload?filename=Gg.vcf&mid=xtbBZhN0UlD-5dwx5gABsT&part=2&sign=400c995c76e24c4964afa006d2a1db78&time=1398130177&uid=asasqw66%40163.com

This all happened using our v2.0 code where we did not use ID to identify ourselves.  It's conceivable that in v2.1+ where we use email.js this could behave differently since the server might know we are better able to handle attachments.  Or not.

This bug is primarily about investigating/understanding what's going on more so than defeating the link generation.

Comment 1

[BMO Automation]

Firefox OS is not being worked on