unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Örjan Ekeberg" <ekeberg@kth.se>,
	"Ralph Seichter" <abbot@monksofcool.net>,
	notmuch@notmuchmail.org
Subject: Re: feature request: caching message arrival time
Date: Mon, 03 Jun 2019 09:17:13 -0400	[thread overview]
Message-ID: <87muiyhkpy.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87v9xnt5as.fsf@swing.csc.kth.se>

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

On Mon 2019-06-03 10:57:15 +0200, Örjan Ekeberg wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> So Autocrypt defines the "effective date" of a message as the *earliest*
>> of two dates: the date that the message is first seen, and the Date:
>> header itself.  So we want our augmented Autocrypt header ingestion
>> routine to search for all other messages we know about from the sender
>> that have both a later firstseen= property *and* a later Date: header.
>
> Would it be possible to use the earliest date seen in any of the
> Received: headers as a safeguard against future-dated messages?

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.

Technically, of course, any MTA could munge the actual Date: header as
well to perform this kind of attack, but that munging would at least
have the potential to be detected by anyone who cares to verify DKIM
headers; but Received: headers are impossible to cover with DKIM.

If there was no expense to the indexing and storage, i'd say it would be
good to just go ahead and index the earliest Received: header as well,
to have that data trivially available as a data point in evaluating
incoming messages.  But since it sounds like there's a cost (in
performance and storage) that would need to be profiled, i don't know
that i can say it's worth the tradeoff.

Since notmuch actually knows when it recieved the message, it seems like
it would be simplest (and less vulnerable to manipulation) to just
record that timestamp directly.

         --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2019-06-03 13:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01  3:29 feature request: caching message arrival time Daniel Kahn Gillmor
2019-06-01 14:13 ` David Bremner
2019-06-01 14:19 ` Ralph Seichter
2019-06-01 15:30   ` Daniel Kahn Gillmor
2019-06-03  8:57     ` Örjan Ekeberg
2019-06-03 13:17       ` Daniel Kahn Gillmor [this message]
2019-06-03 14:02         ` Ralph Seichter
2019-06-03 22:16           ` Daniel Kahn Gillmor
2019-06-03 16:02         ` Örjan Ekeberg
2019-06-03 22:21           ` Daniel Kahn Gillmor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muiyhkpy.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=abbot@monksofcool.net \
    --cc=ekeberg@kth.se \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).