Hi! On Tue, 21 Apr 2026 10:28, Kevin J. McCarthy said:
> If anyone has comments about #4, I'd appreciate feedback. The email >> - **Impact**: Cross-client MIME smuggling when user forwards attacker >> email containing predicted boundary I do not see the problem here. If a mail is forwarded, the forwarding MUA needs to make sure that the boundaries are unique in the the forwarded message. Usually a random boundary is suffieent here but it does not harm to check for conflicts when generating the new boundary. The forwarding MUA may change any boundary at will and construct a different MIME tree. But that is not different from creating mail from scratch. >> - **Attack**: Monitor user's sent mail → recover PRNG state → predict >> future boundary → craft body containing it → recipient sees fake MIME This is not a faked MIME structure but a MIME structure created by the sender - what's the problem? There is one place which may need attention: The case of forwading a signed mail - the MUA may not change the bondary of the signed mail parts. Detection of duplicated boundaries is thus needed - or an unpredictable RNG. Note that tehre is no problem at all with encrypted mails - because you get a new mime tree after decryption. I see no attack here. However, mutt_random_bytes is also used to construct message ids. I would suggest to make them less predictable. But do not use new crypto algorithms for that. All systems come with proper random number generators these days. Something like /* Create an unpredicable nonce of LENGTH bytes in BUFFER. */ void gcry_create_nonce (void *buffer, size_t length); if you anyway link to Libgcrypt, or use the respective functions from the other crypto libs. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein
openpgp-digital-signature.asc
Description: PGP signature
