This patch implements a functional identification and repair process
for "Mixed Up" MIME messages as described in
https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00#section-4.1
The detection test is not entirely complete, in that it does not
verify the contents of the
When showing or replying to a message that has been mangled in transit
by an MTA in the "Mixed up" way, notmuch should instead use the
repaired form of the message.
Tracking the repaired GMimeObject for the lifetime of the mime_node so
that it is cleaned up properly is probably the trickiest part
Some MTAs mangle e-mail messages in transit in ways that are
repairable.
Microsoft Exchange (in particular, the version running today on
Office365's mailservers) appears to mangle multipart/encrypted
messages in a way that makes them undecryptable by the recipient.
I've documented this in
When encountering a message that has been mangled in the "mixed up"
way by an intermediate MTA, notmuch should instead repair it and index
the repaired form.
When it does this, it also associates the index.repaired=mixedup
property with the message. If a problem is found with this repair
This is the third revision of the "Mixed up Mangling" series. Version
1 was at id:20190528225452.17550-1-...@fifthhorseman.net. Version 2
can be found at id:20190530172707.10378-1-...@fifthhorseman.net.
The main difference here is that this series now depends on the
two-part series "Setup for
This is a code reorganization that should have no functional effect,
but will make future changes simpler, because a future commit will
reuse the _mime_node_set_up_part functionality without touching
_mime_node_create.
In the course of splitting out this function, I noticed a comment in
the
This series of two commits offers no functional change, but it is a
useful basis for two outstanding series that i'd like to get merged:
* "mixed up" message mangling
* skipping legacy-display protected headers
Both of these series include code that touches lightly on notmuch's
MIME
This adds no functionality directly, but is a useful starting point
for adding new repair functionality.
Signed-off-by: Daniel Kahn Gillmor
---
doc/man7/notmuch-properties.rst | 12
lib/notmuch-private.h | 1 +
notmuch-client.h| 1 +
util/Makefile.local
Our _notmuch_message_crypto_potential_payload implementation could
only return a failure if bad arguments were passed to it. It is an
internal function, so if that happens it's an entirely internal bug
for notmuch.
It will be more useful for this function to return whether or not the
part is in
When we notice a legacy-display part during indexing, it makes more
sense to avoid indexing it as part of the message body.
Given that the protected subject will already be indexed, there is no
need to index this part at all, so we skip over it.
If this happens during indexing, we set a property
This is the second revision of the series that skips over
"legacy-display" protected header parts.
v1 can be found at id:20190531042825.27774-1-...@fifthhorseman.net
--
Now that notmuch can handle and interpret protected subject lines, it
should also avoid forcing the user to look at
Enigmail generates a "legacy-display" part when it sends encrypted
mail with a protected Subject: header. This part is intended to
display the Subject for mail user agents that are capable of
decryption, but do not know how to deal with embedded protected
headers.
This part is the first child of
Make use of the previous changes to fast-forward past any
legacy-display parts during "notmuch show" and "notmuch reply".
Signed-off-by: Daniel Kahn Gillmor
---
mime-node.c| 11 ++-
test/T356-protected-headers.sh | 2 --
2 files changed, 10 insertions(+), 3
This is a utility function designed to make it easier to
"fast-forward" past a legacy-display part associated with a
cryptographic envelope, and show the user the intended message body.
The bulk of the ugliness in here is in the test function
_notmuch_crypto_payload_has_legacy_display, which
On Fri 2019-05-31 00:41:54 -0400, Daniel Kahn Gillmor wrote:
> This particular re-organization has a slight conflict with the patch
> proposed in id:20190530172707.10378-5-...@fifthhorseman.net (patch 4/4
> from the "mixed-up mangling repair" series).
looking in more detail, i found some subtle
Xu Wang writes:
>
> xu:$ notmuch config set query.james "from:james or from:jimmy or from:jaime"
> xu:$ notmuch search "from:james" | wc -l
> 79
> xu:$ notmuch search "from:james or from:jimmy or from:jaime" | wc -l
> 91
> xu:$ notmuch search james | wc -l
> 177
>
> I was hoping above quantities
Daniel Kahn Gillmor writes:
> In certain cases of test suite failure, the summary report was not
> being printed. In particular, any failure on the parallel test suite,
> and any aborted test in the serialized test suite would end up hiding
> the summary.
pushed to master
Daniel Kahn Gillmor writes:
> Part 0 of a multipart/encrypted object is
> GMIME_MULTIPART_ENCRYPTED_VERSION; part 1 is
> GMIME_MULTIPART_ENCRYPTED_CONTENT. Using the name for what we want
> describes our intent more clearly than using a magic number in the
> code.
>
pushed to master
d
Daniel Kahn Gillmor writes:
> Have you reported this to Dell?
Not yet.
> If you'd care to forward me a zipfile containing examples of at least
> two distinct messages with the same message ID, i'd love to look through
> a copy of this sort of confusion. It's good to understand the different
>
I couldn't run the performance tests on my machines due to a hardcoded
bash path. Use env for finding bash in weird systems like NixOS.
Signed-off-by: William Casarin
---
performance-test/M00-new.sh | 2 +-
performance-test/M01-dump-restore.sh| 2 +-
performance-test/M02-show.sh
It seems our previous attempt with order-only targets was not
sufficient to avoid problems with sphinx-builds doctree cache [0].
Looking around at other people's approaches [1], using seperate
doctrees was suggested. I guess there might be a slight loss of
efficiency, but it seems more robust.
In d9800c8 we deleted the function notmuch-message-mark-replied.
Should we make a deprecated-alias for
notmuch-message-apply-queued-tag-changes?
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
On Fri 2019-05-31 12:45:46 -0300, Jorge P. de Morais Neto wrote:
> I have searched and found no copy. That's because I physically delete
> these Dell notification messages after reading and acting on them. This
> way there is always 0 or 1 such message, so Notmuch does not get
> confused. But I
23 matches
Mail list logo
