In PGP and S/MIME, the ciphertext is signed. You don't encrypt a signed message, you sign an encrypted message.

You can't take a signed message that was encrypted with your public key, decrypt it, re-encrypt it with somebody elses public key, and expect it to still appear signed by the original sender when the new recipient decrypts it.

[edit] There are of course serious problems with the lack of header signing/encryption and replay attacks though I agree. Hence why I add a small note at the end of all of the pgp signed comments on my blog: "This signed text was written for https://grepular.com/ only"

Don't such systems generally encrypt first and then sign the encrypted text, specifically to avoid this?

Your points about subject lines and other assorted headers are correct.

The link I provided discusses this as well; not only are there other attacks, but those other attacks are potentially more severe. A man-in-the-middle attacker can claim credit for a message by substituting their own signature for the sender's. A naive encrypt-then-sign system will also lack non-repudiation in some cases (e.g. when using RSA signatures and encryption), and will only provide non-repudiation on the ciphertext itself (not the plaintext; this may or may not be what you want).

You're right of course but I think a straightforward way to sign, encrypt and decrypt your email would be a big step forward.

Plus (nearly) all security has trade-offs. The trade offs dont necessarily trump the added benefits of the security.

Sounds like a simple solution would to duplicate the headers in the body and encrypt them along with the message. That way, even if you resend that email, the encrypted To: field would make it obvious that it was meant only for you.