DKIM-ID is incompatible with stdin mode archiving

The DKIM-ID generator has diminished functionality when `archiver.py` is used in stdin mode because the DKIM-ID generator relies on headers such as `List-Id` which are added by the mailing list manager. If `archiver.py` is used in stdin mode then it typically receives an email before the mailing list manager has added the `List-Id` and other such headers, and before it may have made any of the other DKIM changes listed in [RFC 6377 § 3.3](https://datatracker.ietf.org/doc/html/rfc6377#section-3.3).

In consequence, `archiver.py` is only compatible with the Mailman3 mailing list manager. If it is used with any other mailing list manager then it has to be used in stdin mode, which means that messages sent out by the mailing list manager will not match the DKIM-ID of the message as stored in the mailing list archive. Though DKIM-ID will still function as a deduplicator in this case, it will not be possible to use it to search for existing messages or to recover lost messages.

Possible actions that could be taken include either removing the ability to archive using stdin mode, or noting in the documentation the loss of functionality when using DKIM-ID in conjunction with stdin mode. It may also be possible to set up some mailing list managers to send their outgoing messages through an MTA filter which sends a copy to the archiver in stdin mode. If so, this could be documented as another potential option.

Start by inspecting archiver.py and the documentation covering stdin mode and DKIM-ID, then compare the behavior with the RFC 6377 § 3.3 context described here. The issue leaves the resolution open; done would require a decided approach, such as documenting the limitation and any MTA-filter option or removing stdin support, with corresponding verification.

Written by the indexing model from the issue text.