feature request: caching message arrival time
ekeberg at kth.se
Mon Jun 3 09:02:53 PDT 2019
Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> Sure, assuming that you trust the closest MTA in the chain of MTAs that
> handed the message off to you, since an adversarial proximal MTA could
> manipulate all the existing Received: headers as well.
> But I'm a bit uncomfortable with it: this sort of protection actually
> opens up a new attack vector that didn't exist before -- any MTA in the
> chain can now make the message seem like it was actually from the
> *past*, just by setting its own Received: header.
As far as I understand the autocrypt protocol (i.e. not much;-) ), the
vulnerability is that an incoming message with a later time-stamp than
the locally saved autocrypt status can update the stored state
(e.g. turn off encryption). Manipulating the time-stamp to make the
message appear to be *older* than it really is should only mean that it is
less likely to update the saved state?
If this is correct, using the oldest of all the time-stamps seen in the
Date-header and any of the Received-headers should be the most
More information about the notmuch