Message security #4251
Replies: 27 comments 34 replies
-
|
I haven't addressed *01 and *02, since I'm not sure we want them. The following issues / PRs address
The following issues / PRs address The following issues / PRs address the weeding of protected header fields:
The following issues / PRs address
The following issues / PRs address
The following issues / PRs address The following issues / PRs address The following issues / PRs address
The following issues / PRs implement |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
Lovely, thanks. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
I'm not deep into this topic, sorry if this is a stupid question. This two are mostly useful for the sender right? Or why would I, as recipient, care if some other recipient can't verify/decrypt a message? |
Beta Was this translation helpful? Give feedback.
-
|
I wrote those points before writing |
Beta Was this translation helpful? Give feedback.
-
|
With my limited knowledge:
Regarding the warning in But what I really wanted to ask: what happened to |
Beta Was this translation helpful? Give feedback.
-
|
:D |
Beta Was this translation helpful? Give feedback.
-
|
I would do this:
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
I had been thinking about this one. I very much prefer to keep it intact, for the user to examine. (This is the behavior with |
Beta Was this translation helpful? Give feedback.
-
I never understood why (neo)mutt(1) uses the "envelope" term. The envelope is a different thing. What (neo)mutt(1) calls the envelope is actually the header, isn't it? See also: And see also:
|
Beta Was this translation helpful? Give feedback.
-
I think these two are unlikely to be feasible and useful. Some times we'll receive messages that are encrypted to recipients whose key we don't have, so we don't know if the recipient can decrypt or not. Or maybe we have the key, but the recipient added another ID to that key recently, and we didn't know about it. I'd leave these two for future investigation (as in, at least a few years from now), but discard them for now. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
Maybe we could use colors:
However, I would do this in a second round of improvements to message security. I.e., not in the first release. I'd like to give it some more thought. *: Message header is what (neo)mutt(1) calls the envelope. In RFCeese, the term message header refers to the "main" header of the email. See https://datatracker.ietf.org/doc/html/rfc1521#section-7.2. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Round 1.I think in a first release we could limit ourselves to the following, which are the most basic enhancements:
The rest are either more difficult to implement, or may need more discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @alejandro-colomar , I have a couple of questions regarding protected headers. They are general questions, not related to what we already do or what you suggest we do:
|
Beta Was this translation helpful? Give feedback.
-
|
Re: 1.: It's specified in https://www.rfc-editor.org/rfc/rfc2045#section-2.4. Which I read as "you can put whatever you want there". Then it continues with Which is of course, they have a meaning for us. They just don't have a meaning for MIME. |
Beta Was this translation helpful? Give feedback.
-
|
Re: 2.: It's not crazy. I think that's similar (maybe the same?) to what https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ calls a"wrapped message". It would work, I guess. They mention that it's more likely to be incompatible with existing MUAs, since they will have a harder time parsing that. And it will probably be harder to implement. But it protects as much as my proposal, so regarding the protection it provides, I'm okay with it. However, consider the work of implementing that thing. (Is that already implemented for S/MIME? Maybe we can reuse code and it's not that bad.) |
Beta Was this translation helpful? Give feedback.
-
|
Re 3.:
I would go further. Almost-nobody cared about protecting headers. Standard or non-standard. My opinion... I guess the feedback from some mutt(1) developers is a good example. Most probably never stopped to think if they are really vulnerable. I got several replies saying things like you need to be doing stupid things to fall into such an attack. It's only after I insisted a few times that they stopped to consider it, and found that the attack was actually possible. Also, the ones that could consider it a viable attack, probably didn't consider themselves as viable targets, and so they didn't bother to fix it, since that would be work. And for the very few that considered it a viable attack, and considered themselves viable targets, and were capable of patching their MUA to add this security, and were capable of convincing MUA maintainers of merging their patches... (and I assume there are very very few people that meet all these conditions)... they probably workarounded it by being stricter about their communications, which is a simpler solution (compared to convincing MUA maintainers of merging patches). If you talk to your recipients, better offline, and everyone knows that nobody else should be listening, then if an attacker tries to add itself to CC, they won't be tricked. It someone should be added, mention it in the message, saying "CC += someone". Being disciplined works for small groups, which are the usual target. But none of those reasons strikes me as a good reason to not improve the status quo. |
Beta Was this translation helpful? Give feedback.
-
|
I have the impression that protected headers should be proposed as part of an extension of a PGP-MIME RFC, to maximize interoperability. Putting headers in the MIME header is a no-brainer, but reporting mismatches between the email and the MIME headers and everything that follows could be codified in a standard. |
Beta Was this translation helpful? Give feedback.
-
This assumes a certain interpretation of the headers of the encrypted MIME part, which - as of today - only exists marginally. This is part of why I think this would be best put in an RFC. I think it's a stretch to say that if I find a From: header in the encrypted MIME header, it should be taken as the sender instead of the From header in the email. There's nothing to say how to interpret those headers, and different MUAs might implement their on semantics. |
Beta Was this translation helpful? Give feedback.
-
it's even more a stretch to suppose that the sending MUA meant anything else when it put the header there. sure, you can effectively kill the effort by insisting on (even more) a-priori standardization, which will most likely meet the same destiny as the previous attempts. or you just accept that this is objectively a quality improvement with no obvious downsides, and go with it. |
Beta Was this translation helpful? Give feedback.
-
It might mean a nickname, not a formally valid email address. It might not even be a MUA that generates the part. It might be a journalists software that uses From to put the source of some news, and To to mean the name of the journalist. I don't have the context of how everyone in the world uses PGP MIME parts. That's why we need standardization.
It's a quality improvement only for NeoMutt<->NeoMutt communication, as long as nobody else is doing it - so very marginal. And it has no obvious downsides as long as nobody else is doing it differently. My suggestion, if we want to pursue this, is to use X-NeoMutt-* headers. |
Beta Was this translation helpful? Give feedback.
-
|
My intention is that other MUAs follow. However, the security teams of Debian and Redhat didn't respond to my request for a CVE. I'll try CCing some people that are involved in thunderbird(1) (from what I can see in the Mozilla comm-central github mirror). |
Beta Was this translation helpful? Give feedback.
-
|
The interpretation of a received message has been documented in a draft for a RFC: It basically says what I suggested doing: if the MUA finds at least one protected address list, consider that the sending MUA protected all address lists, and so anything that differes from the protected headers in any way, should be considered tampered. They propose two alternative behaviors: either completely ignoring the exposed headers, or consider the PGP signature invalid. I think we can do a little better: show both the exposed and the protected headers, allowing the user to inspect what really arrived; ignore the exposed headers for the purposes of replying; and instead of invalidating the signature, just adding tampering warnings, since the signature is still valid. FWIW, I'll also CC people that contributed to that file. |
Beta Was this translation helpful? Give feedback.
-
|
(I added those CCs as an edit; I'm not sure if GH notifies them; I'll repeat the CCs in a new comment.) |
Beta Was this translation helpful? Give feedback.
-
the level of malicious idiocy to actually do that would be astonishing. re-using existing rfc5322 header names in a closely related context for other purposes is obviously calling for trouble. sure, someone might do it nonetheless, but why should the world be constrained by such people? esp. given the existence of the related draft RFCs? |
Beta Was this translation helpful? Give feedback.
-
|
Ok - so you're saying you're going to implement https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-20? |
Beta Was this translation helpful? Give feedback.
-
|
Not all of it, and my implementation was completely independent of it (I didn't know that document when I wrote the code), but after checking the document it very closely matches my implementation. And I'd say that where we differ from it is only in small aspects, and our difference could be considered quality-of-implementation details. |
Beta Was this translation helpful? Give feedback.
-
|
I'd say that https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-20#name-receiving-side clears my concerns: as long as there's a way to determine that protected headers were used by the sender according to some standard (or draft), it's ok to interpret them as such. I don't think your implementation does that (yet), though? |
Beta Was this translation helpful? Give feedback.
-
|
My current implementation does:
I propose discussing further what to do with those headers after those changes have been merged, at least to devel/security. I think sending and rendering the headers is a separate discussion of how to behave when they have been tampered. For the discussion on tampering, my proposal is to:
We could do this in a v2, or we could ship it all together, I don't mind. |
Beta Was this translation helpful? Give feedback.
-
|
sounds reasonable to me. i'd do everything in one go, because a complete solution is always more convincing, and avoids churn. i'd go with a space-saving presentation in the default weeded mode, i.e. cull the duplicated headers that match (after FWS normalization). maybe mark them as signed by using a separate color for them (in practice, i'd use the same color but with underline, i think). |
Beta Was this translation helpful? Give feedback.
-
Sounds reasonable.
I'll still do it in many small commits, even if we do it in one release, though.
My idea for this is slightly different: Use colors for the exposed headers:
I'd do that in the third round of patches. After we already have the tampering warnings ( |
Beta Was this translation helpful? Give feedback.
-
often enough, things are standardized post-fact after they have proven themselves. the deprecation of the X- prefix explicitly encourages this, although at the micro level. |
Beta Was this translation helpful? Give feedback.
-
Can you please say more clearly on which of the various aspects discussed you're seeking feedback? |
Beta Was this translation helpful? Give feedback.
-
|
Heh, any feedback that you want to give would be great, on any aspect. I just wanted to let thunderbird(1) know of our plans, to make sure we are compatible, if you want to implement this (and I wish that you do). |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to comment on this late. The feature looks generally useful and it's good to see that standardization on secure headers is proceeding (though mainly on the S/MIME side at the moment?), but have you checked how current versions of widely-used MUA integrations display headers other than Subject from inside the secure envelope? For example:
If "extra" headers hit the user with load of warnings or cause other problems, it may prompt complaints from users and maintainers. On the other hand if clients don't display the secure headers at all, this may prompt complaints from security hawks that this represents an invisible salamanders kind of vulnerability (different recipients see different content). Appendix A of draft-ietf-lamps-header-protection linked above has a good list of problems to look out for as well as test vectors. The results may affect how quickly the features discussed here could be enabled by default if relevant PR(s) get merged. IIRC some EU governments (e.g. Germany) have recently adopted PGP for secure messaging so interop issues with GUI clients running on Windows may be something that people care about at the moment. (It may also be something of a meta-problem that some people involved with ietf-lamps-header-protection are also involved in the ietf-openpgp-crypto-refresh WG, which is currently in a pretty much all-out standardization war with GnuPG developers). |
Beta Was this translation helpful? Give feedback.
-
No, I won't touch that even with a stick.
Similarly.
I used that until half a year ago. I received messages from recipients using mutt(1), which has been protecting these headers for a long time, and never noticed any of the protected headers. I guess it simply ignores them. However, back when I used thunderbird(1), it didn't read correctly the subject sent by mutt(1), so I guess they've improved that. I talked to @ikerexxe today, and we found that thunderbird(1) now is compatible with mutt(1)'s protected subject. However, I guess they still ignore the rest of the header fields. Maybe a thunderbird(1) contributor can comment on this. @kaie , any comments? |
Beta Was this translation helpful? Give feedback.
-
|
As gahr mentioned below and I forgot earlier, there's also the question of clearsigned messages that will presumably have the in-envelope secure headers. These messages' content will typically be viewable also in clients that can't verify the signature. That adds to the list for lighter verification major MUAs such as:
In general, someone is going to have to put in the hours to do the interop testing, because a lot of people use the clients listed regardless of the opinions of this discussion's participants. While I do personally like the feature, it seems to me that without a clear and tested idea of its effect on the larger user base, the send side could at best be merged as an opt-in (disabled-by-default) feature. Users of terminal mail clients, let alone those who regularly sign their mails, surely already get enough grumbling from less technically-minded GUI/webmail users about "weird and ugly" mails—bringing about more of the same without a testing-based evaluation of the costs and benefits is unlikely to happen. The alternative to doing this testing here would be to wait for the I-D mentioned earlier to go forward and hope some well-resourced organization (Mozilla? Proton?) implements it and handles the heavy lifting wrt interop. |
Beta Was this translation helpful? Give feedback.
-
|
For the wide testing, we can at least say that it doesn't significantly break any major client, without having seen any of them. How can I do that claim without having used any of those? mutt(1) has been protecting the following headers for several years already, and the night sky didn't fall so far. in mutt_protect(): if (option (OPTCRYPTPROTHDRSWRITE))
{
BUFFER *date = NULL;
protected_headers = mutt_new_envelope ();
protected_headers->subject = safe_strdup (msg->env->subject);
/* Note that we set sctx->date_header too so the values match */
date = mutt_buffer_pool_get ();
mutt_make_date (date);
mutt_str_replace (&sctx->date_header, mutt_b2s (date));
protected_headers->date = safe_strdup (mutt_b2s (date));
mutt_buffer_pool_release (&date);
protected_headers->from = rfc822_cpy_adr (msg->env->from, 0);
protected_headers->to = rfc822_cpy_adr (msg->env->to, 0);
protected_headers->cc = rfc822_cpy_adr (msg->env->cc, 0);
protected_headers->reply_to = rfc822_cpy_adr (msg->env->reply_to, 0);
mutt_prepare_envelope (protected_headers, 0);
mutt_env_to_intl (protected_headers, NULL, NULL);
mutt_free_envelope (&msg->content->mime_headers);
msg->content->mime_headers = protected_headers;
mutt_set_parameter ("protected-headers", "v1", &msg->content->parameter);
}We can assume that mutt(1) users have interacted at least a meaningful number of times with users of those mail clients. |
Beta Was this translation helpful? Give feedback.
-
|
How about more widely-used MUAs? I'm thinking of GMail and Outlook. You can't probably easily decrypt encrypted messages, but you can probably display signed messages. I guess they'll ignore protected headers altogether. |
Beta Was this translation helpful? Give feedback.
-
|
gmail ignores the signature, last time I checked (a few weeks ago). I can confirm again in a few hours after talking to someone who uses it. (But maybe there's a hidden way in gmail that I don't know.) (Edit: there seems to be a web browser extension to do PGP with gmail: mailvelope; I haven't tried it) I don't know of outlook. BTW, I'll CC the maintainer of a webmail I care about. I guess it also ignores the protected headers, but it won't hurt to let him/her know about our plans. @emersion, how does migadu webmail (alps) handle protected header fields in signed and/or encrypted mail? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the ping! I've opened https://todo.sr.ht/~migadu/alps/181 to track this. We don't handle any of this at the moment, but it would be a nice improvement. |
Beta Was this translation helpful? Give feedback.
-
|
I'm really glad to see this work, @alejandro-colomar . thanks for doing it! If you have any feedback about draft-ietf-lamps-protected-headers, including about any potential divergence, please don't hesitate to raise issues, either on the LAMPS mailinglist or in the issue-tracker. Please note that we have a change pending to the draft related to how a recipient of an encrypted message can tell whether the sender removed or obscured any of the headers that were directly protected. The change should clean up one obscure corner case where it might be difficult to tell what the sender of the message actually did. I suspect the safest route to deployment here when generating messages is to use a default Header Confidentiality Policy of @vuori the header protection (and its partner document, As for the risk of conflict with the GnuPG team, if there's a war, it's entirely one-sided, as i have no interest in being in a war. Indeed, i'm a longtime supporter of GnuPG, and have helped to maintain it in Debian for many years. I don't oppose GnuPG, but i am intimately aware of the ways that it can fail users, and i don't think the ecosystem is healthy if it all just entirely follows the whim of a single implementation. I want standardization (whether in OpenPGP or in e-mail standards, or elsewhere) to advance across multiple implementations, with something like the proverbial rough consensus and running code. I would certainly hope that whatever animus the GnuPG team bears toward me wouldn't translate into a rejection of anything i happen to have touched, but that's also not something i can control. ☹ |
Beta Was this translation helpful? Give feedback.
-
the thing is that while this keeps the implementation simple and the result easy to verify, usually this is just visual clutter which steals screen estate and adds unnecessary cognitive load to the user. you can still show the whole thing when the user turns off header weeding. |
Beta Was this translation helpful? Give feedback.
-
|
When I add colors to the exposed header (green confirming that the field matches a protected one, red otherwise + a [-- ... --] warning), the user will be able to simply hide all protected headers ( To me, the clutter isn't that big, so I'd read mail with the protected header enabled, but that would be an option for the minimalist. |
Beta Was this translation helpful? Give feedback.
-
|
i haven't followed everything closely enough to have a coherent view, so i'll just braindump here:
|
Beta Was this translation helpful? Give feedback.
-
|
I think we only slightly disagree on the defaults. Let's discuss the defaults again after we have most of the features implemented, so we can test different configurations. |
Beta Was this translation helpful? Give feedback.
-
|
in the course of writing this document, we were focused on trying to provide as close to a "normal e-mail" experience as possible for both the sender and the recipient of the message. That's why we emphasize only showing one set of headers. We don't want to make this usable only by e-mail experts, cryptography experts, or (worse) people who happen to be experts in both e-mail and cryptography :P I agree with @alejandro-colomar that it's reasonable to do the implementation with both modes available and choose the default mode later (certainly experts will want to be able to see both sets for debugging purposes). And i agree with @ossilator that the reasonable default for normal users (which is what should be the default for the software when otherwise unconfigured) is the minimalist setting, where only the protected set is what's shown. |
Beta Was this translation helpful? Give feedback.
-
|
cc @the-djmaze Given that snappymail supports PGP, you might be interested in this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I don't think i will implement any of the ideas. By encrypting/hiding headers we have to fight more against Microsoft mail servers and i already think they should be shot/killed/bankrupt due to the already daily task to fight against their void. Not to mention the issue they had a week ago where their customers sending mail were also send to the void and everyone had to resend them again after the fix. So, until everything works as expected, i will wait. As for tampering: DKIM can protect against that already. |
Beta Was this translation helpful? Give feedback.
-
|
This protocol design work has been done deliberately with the knowledge of real-world deliverability problems in mind. we definitely don't want messages to be dropped by any major providers if they follow this guidance, and we've done a fair amount of testing and have not seen any deliverability problems for the default settings recommended in the draft as compared with e-mail messages with end-to-end encryption but no header protections. If you do see differential deliverability problems due to header protection, please report! As for using DKIM to protect against tampering: DKIM signatures are typically applied at the domain level, or at least with the cooperation of the domain controller. End-to-end encrypted e-mail messages deliberately consider the domain controller as a possible adversary, so DKIM doesn't provide end-to-end protection against tampering. Furthermore, DKIM signatures are only guaranteed to be verifiable and relevant around delivery time (as DKIM keys themselves might be rotated or unpublished), whereas e2e protections are intended to stick with the message as long as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Mailing lists add some address lists to the message. For example, linux-man@vger.kernel.org added the following to one mail from me: It also modified the Date (4 seconds earlier than my original message!). I guess we can add variables to trigger/not trigger tampering warnings when certain address lists are tampered. The above would silence the The red/green colors for tampered fields would still apply, so that these fields would appear in red in the exposed header, since they are not signed. (Assuming I find a way to modify the color of those fields.) |
Beta Was this translation helpful? Give feedback.
-
|
Now that we've merged the basic functionality, let's discuss what should go next. I think your suggestion about punycodes could be the first improvement. And after it, we could try to address more of this. BTW, while using the devel/security branch, I noticed that thunderbird(1) protects more headers than just the Subject: https://marc.info/?l=mutt-dev&m=171516909330110&w=2. So, we're not alone in this. I'm not sure how they use them on the reading side, though. Maybe @kaie can comment on that? |
Beta Was this translation helpful? Give feedback.
-
Yes, please.
Ah! Good to know. |
Beta Was this translation helpful? Give feedback.
-
Overview
This is a list of existing security features of NeoMutt and a large number of proposed improvements.
NeoMutt can sign and/or encrypt emails.
While this adds security to the message, the headers could be tampered with.
Many of the ideas below help to protect against this, or highlight when it happens.
Developers: Some of them already have proofs-of-concept that you can try out.
There's a lot to take in.
Feel free to ask lots of questions and let us know your thoughts.
Thanks! ❤️
Existing Feature
*17Hidden SubjectWhen NeoMutt encrypts an email, it has a feature to hide the
Subject:.The headers will contain, say:
Subject: ...and the real subject will be put in the encrypted body.This makes it harder for eavesdroppers to follow a conversation.
See also
*08This feature is controlled by the config:
*05Toggle showing protected fieldsWhen NeoMutt receives a message with protected headers, it has a configuration variable to hide them.
This helps reduce the noise of duplicated header fields, since in most cases, messages will be legitimate.
This feature is controlled by the config:
Proposed Features
*19Encryption Info BlockPull Request: #4221
Add a block of information to the Pager showing all the encryption recipients.
Currently, this shows a list of encryption sub-keys.
These sub-keys are unique and can be used to look up the user's main key, but they aren't immediately recognisable.
Future improvements:
(these steps haven't been tested)
This feature is controlled by the config:
set crypt_encryption_info = no*01Encryption Key/Recipient CheckThis would depend on
*19and looking up the user's email addressWarn the user when an encryption recipient isn't in one of the address fields.
Looking up the user's real name / email address could be slow (untested).
*02Encryption Recipient/Key CheckThis would depend on
*19and looking up the user's email addressWarn the user when a recipient of the email doesn't have a matching encryption key.
Looking up the user's real name / email address could be slow (untested).
*03Remove Padding LinesConfirmed: See devel/security #4243, #4255
Don't display padding around the message, in the Pager.
NeoMutt prints a blank line before and after the message body.
Remove them, so that what's displayed matches what's signed/encrypted.
*04Force Blank Line After Mime HeaderConfirmed: See devel/security #4247, #4255
The Mime header block can contain zero or more fields.
However many fields there are (even zero), they are always followed by a blank line.
This means the user can distinguish between fields that are hidden and zero fields.
*20Weeding the Crypto HeadersOptionally hide some of the protected headers.
NeoMutt performs "weeding" (filtering) on the email headers.
The
ignoreandunignorecommands tell NeoMutt which to hide or show.These currently affect protected headers as well.
We could add a configuration variable to not do that by default, while still allowing to weed them.
This feature would be controlled by,
set crypt_protected_headers_weed = yes*07Hide BccEncrypting to a
Bccshould use a "hidden recipient".When
gpgencrypts, it can embed the key fingerprint in the text.Anyone who has the encrypted text, can tell who it's encrypted to.
If you send an email
To: JimandBcc: Bob, then Jim can infer that Bob received the email too.By telling
gpgto use 'hidden recipients', then key isn't visible.This is an improvement, but Jim will still know that there's another recipient.
A more thorough solution, and much more work, would be to have NeoMutt send a separate email to each of the
Bcc:list.See also:
*19Encryption Info Block*08Protect Address ListsPresent in mutt(1) since 2.0.0:
See http://mutt.org/relnotes/2.0/
See https://gitlab.com/muttmua/mutt/raw/stable/UPDATING
See https://gitlab.com/muttmua/mutt/-/commit/82b5c697e935ffe40b833e150aa79fd3cb27a20c
See https://marc.info/?l=mutt-dev&m=171349491914691&w=2
See https://marc.info/?l=mutt-dev&m=171349804815814&w=2
(but mutt(1) doesn't protect all address lists; only the basic ones.)
Save a copy of any address lists, e.g.
To:,Cc:in the signed/encrypted block.The headers of an email aren't protected and could be altered by a malicious agent.
When you reply to an email, you can't be certain that everyone was really an intended recipient.
See also:
*11Warning on Tampering*20Weeding the Crypto Headers*09Protect In-Reply-ToSave a copy of any the
In-Reply-To:in the signed/encrypted block.The
In-Reply-To:field contains sensitive fields.If an attacker were to alter them, it could mislead the recipient.
See also:
*08Protect Address Lists*10Use Protected FieldsUnprotected fields shouldn't be trusted when replying.
If an email's headers have been tampered with, it should still be possible to reply to the email using the protected values.
If the user has already been warned, then the correct values of the fields should be used.
Note: Until the message has been opened, it won't be possible to check for tampering.
The Index needs to display the protected values as soon as the Pager has read them.
*11Warning on TamperingCheck the header fields against the protected copy in the signed/encrypted block.
Display a warning in the Pager:
What should we do with this info?
Should we:
Highlight the bad field in the headers?
Leave the original header intact?
(For the user to examine)
Overwrite the header?
Keep a
Subject-Orig:?(So we can warn every time the email is read)
See also:
*15Colours*13Phishing ProtectionHighlight email addresses that could be misleading.
See also: #4233 Phishing Protection
These two addresses are not the same, but in many fonts they look identical.
Mark any addresses that aren't entirely ASCII with they're PunyCode equivalent.
Users can create a list of known safe addresses.
*14Pager NavigationThese features could potentially add a lot of header information to an Email.
We want to encourage more people to use the features, but we don't want to get in the way of reading the email.
Currently, NeoMutt has functions,
<skip-headers>and<skip-quoted>.We could alter
<skip-headers>to step between Mime blocks too.The top of the screen displays:
e.g.
<skip-headers>: First Mime block<skip-headers>: Second Mime block (or no change)See also:
*16Compact Display*15ColoursUse colour to highlight errors, warnings, or correct info.
Using
gpgmeis the preferred way to handle signing/encryption.(
set crypt_use_gpgme = yes)It knows (so NeoMutt knows) when a signature is bad, etc.
Some old NeoMutt themes had regexes to match and colour "Good signature" / "Bad signature".
Should we create some colours for these common cases?
Currently, all the
[-- ... --]type headers are coloured withcolor attachment.Do we want a separate
color crypto?Vim has the ability to link colours together (NeoMutt doesn't, yet :-)
e.g.
This might allow linking
color crypto_warningtocolor warning, etc*16Compact DisplayDisplay less information, without compromising security.
Most users will never see a forged email, but we still want them to enable these safety features.
This means making the displayed information very quick to parse visually, or very compact.
For a normal email, all the protected fields will be the same as the email header fields.
In this case, it makes sense not to show one of the sets.
If we hide the protected fields, we need a way to show that the header fields have been validated.
We could define some new colours for the various states: Valid, Unknown, Invalid.
Alternatively, NeoMutt already uses quite a few
*_charsconfig options as flags.This would allow custom text markers (e.g. using NerdFonts).
Or both!
Beta Was this translation helpful? Give feedback.
All reactions