Prevent replay attacks on the e-mail control interface

I think schleuder's e-mail control mechanism is not robust against replay attacks. If i'm wrong, please point me to how replay attacks are mitigated.

Consider Mary, an administrator of two different schleuder lists, hosted on two different schleuder instances: list@work.example and list@play.example.

Mary wants to subscribe her colleague Monster (monster@work.example) to list@work.example, so she sends a signed and encrypted e-mail to list-request@work.example:

x-subscribe: monster@work.example 0xE328D90A1C75F90F9FF1214EE4B590BFBA69D6
x-add-key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
[…]

However, Monster is in collusion with the administrators of work.example, and they all really want to know what Mary is up to with her friends on list@play.example. They take Mary's incoming message, strip off the crypto (keeping the OpenPGP signature) and wrap it in another layer of encryption to the key that belongs to list-request@play.example. Then they send this new message (with new RFC 822 headers, etc) on to the MX for play.example.

Now Monster is subscribed to Mary's play list, without her intent or permission. The same attack could be used to re-subscribe a user to a list that they've previously been ejected from.

This is a classic problem with schemes that depend on cryptographic signatures for protection, but depend on context that is not cryptographically-signed to interpret the signed material.

Typically, you'd fix this by requiring the signed message to be completely context-independent, by bundling the context directly into the message.

There are two ways to approach fixing this:

the right long-term way is probably to depend on some automated, signed header mechanism (like memoryhole, see #74 (closed)), and only accept messages that say they are To: list-request@play.example. But this is probably not particularly useful in the short term, since only enigmail offers header signing at the moment.
as a short-term fix, if there is no To:header in the signed MIME part, the play.example schleuder instance could look for a pseudo-header line (at the top of the signed body) that says To: list-request@play.example, and reject the message if it's not the right address.

Finally, there are some mitigations you could do with signature timestamps, etc, to limit the scope of possible replay attacks, but those depend on everyone having at least roughly-synced clocks, and they introduce a bunch of new possible failure modes, so i don't know how much work you want to do to entertain them.

Note that traditional mailing lists which offer command and control through e-mail are at least as vulnerable to this kind of replay attack -- moreso, since the sender can just forge a given message without needing to find one to replay. that said, schleuder should offer better guarantees, since it is in the position to do so.