Closed Bug 1111878 Opened 10 years ago Closed 10 years ago

New "include all X-Headers in email bodies" feature doesn't apply to secure mail

Categories

(bugzilla.mozilla.org :: Extensions, defect)

Production
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: gene, Unassigned)

References

Details

See original feature Bug 1035972

Secure mail contains X-Headers with information about the bug (unencrypted). Because secure mail is not sent in HTML format (but instead in plaintext), the feature to include the X-Headers in the body for Gmail filtering doesn't apply.

Would it make sense for secure mail to include the X-Headers in the body despite the fact that the headers would be visible since the email is in plain text? Doing so would allow people's Gmail filters to apply equally to secure and insecure bugmail (as it did before the move to Gmail).
Blocks: 1035972
(In reply to Gene Wood [:gene] from comment #0)
> Secure mail contains X-Headers with information about the bug (unencrypted).
> Because secure mail is not sent in HTML format (but instead in plaintext),
> the feature to include the X-Headers in the body for Gmail filtering doesn't
> apply.

this statement doesn't reflect how things work.


in-body x-headers are injected into both html and plaintext emails/parts.  you don't need to switch to html bugmail to use them, but it's recommended because we can hide them there.

securemail isn't set as plaintext -- the entire bugmail is encrypted and that's what is sent, either as a pgp or s/mime payload.


the issue is actually due to the x-headers being present but encrypted; which means they are not visible to gmail's filters.  unfortunately this isn't something we can solve :(

i've experimented with including both encrypted and unencrypted content, however i couldn't find a way to do that which worked on all email clients.


given email decryption had to happen client-side anyhow, i suggest setting up filters on your email client to deal with encrypted bugmail.
No longer blocks: 1035972
Status: NEW → RESOLVED
Closed: 10 years ago
Depends on: 1035972
Resolution: --- → WONTFIX
Ah got it.

I was thinking of the Secure mail email with the plaintext of : "This email would have contained sensitive information, but you have not set a PGP/GPG key or SMIME certificate in the "Secure Mail" section of your user preferences."

This text however isn't sent if the user does have a GPG key configured. In that case, indeed, the body is solely the PGP ascii armored payload.

> i've experimented with including both encrypted and unencrypted content, however i couldn't find a way to do that which worked on all email clients.

Would it be possible to enable users to choose to have the X-Headers added to the body of the email outside of the PGP block, despite the fact that some mail clients won't deal with unencrypted content outside the PGP armored block? This could be rendered as an option with the existing option of whether or not to add the x-headers to the body.

I imagine users (Michal, speak up if I'm wrong), would be willing to risk not having some email clients be able to decrypt the secure mail in order to get Gmail filtering on secure mail.

I'd be happy, if it was of any use, to test out the current versions of the major email clients (Thunderbird, Evolution, Mail.App) to see how they handle this.
Flags: needinfo?(mpurzynski)
(In reply to Gene Wood [:gene] from comment #2)
> Would it be possible to enable users to choose to have the X-Headers added
> to the body of the email outside of the PGP block, despite the fact that
> some mail clients won't deal with unencrypted content outside the PGP
> armored block? This could be rendered as an option with the existing option
> of whether or not to add the x-headers to the body.

injecting the headers into the "you don't have a key/cert set" payload should be do-able.

however injecting the headers along side encrypted content is complicated, and applicable to only a tiny fraction of users.  "if you get encrypted bugmail, and you use pgp, and you use gmail's filters".  given the work around is trivial (client-side filtering post-decryption), that isn't something that i think we should consider.
Flags: needinfo?(mpurzynski)
If there are not many users that request this functionality, let's pass on it. I'd like the request to have a high positive impact, and if that's just me - I can live without it. We're getting at most a couple of encrypted emails from bugzilla per week, so that's perfectly manageable.
Component: Extensions: BMO → Extensions
You need to log in before you can comment on or make changes to this bug.