Andreas Kähäri <andreas.kahari@abc.se> writes:

> [...]
>> > stupid "external message" headers added by malicious^Wcorporate mail
>> > servers, etc...
>> 
>> Headers would not "muddy the waters" since they are headers. In my mind,
>> the hash would be over the body only.
>
> Hi, I'm not really part of the discussion, but I can add a quick thought
> and a suggestion.
>
> There are corporate mail servers that add a boilerplate "header" to the
> body of outgoing email messages.  The more common practice is to add a
> "footer" to the message.  I have seen these footers being added both
> before and after the user's signature.  You can not use a hash that
> contains the body of the message to identify the message as unique.

Thanks for pointing out. You're right, of course; I have seen such
things myself, too.

It thus seems to me that the body hash idea is officially not working. I
rest my case.

> Using the earliest Received header (the one furtherst down) as a unique
> identifier would possibly be a better approach.  Since this likely
> contains the identity of the originating mail server, some mail queue
> ID, and a timestamp, it should be unique enough to identify the message,
> even if the message is received via multiple routes and has a non-unique
> Message ID.
> [...]

I would strongly advise against using any "early" Received (or any
other) header for any heuristics. In spam traffic most headers will all
but certainly be fake. The only ones to trust is the very last Received
header added by your own (or your provider's) mail system.

Trying to control your code's behaviour based on maliciously crafted
data would hence mean intentionally exposing an attack surface. Parsing
these data for display to the user (as is the case now) is as far as I
would suggest going with that; but no further.


Cheers,

  --alexander
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org