In addition to the git object_id (blob SHA-1) and Message-Id
header; it seems necessary to introduce an in-between identifier
for deduplicating which isn't as loose as Message-Id or as
strict as object_id: content_id
I think a hash of the following raw headers + raw body will
suffice:
Subject, From, Date, Message-Id, References, To, Cc,
In-Reply-To, MIME-Version, Content-Type,
Content-Disposition, Content-Transfer-Encoding
Those should be relevant to what MUAs display to users.
Fwiw, ssoma only used Subject + raw body if Message-Id matched;
and public-inbox v1 only uses Message-Id.
List-Id, X-Mailing-List should be left out so different
readers/lists can share spam removals in cross posts.
Received: headers will definitely not be taken into account
as every recipient sees a different chain(*)
The code also won't be tied to any particular hash so it should
be possible to switch to another one as weaknesses are discovered;
and it could be possible to support multiple hashes in an
"inbox"
I also took a look at Razor and DCC anti-spam stuff, but both
seem to take fuzzy matches to avoid hash busting; but IMHO the
bar needs to be higher for handling removals from the archive.
(*) I noticed the first Received: header (last hop) is missing
from the cregit sources; but the first remaining Received:
header also includes the identity of the recipient in more
recent mails...
--
unsubscribe: meta+unsubscr...@public-inbox.org
archive: https://public-inbox.org/meta/
