I do not know of any user agents that can be configured to accept only intern
message/rfc822 type, or even flag the difference to the user. Most users would
not understand the flag if it was there.
I would like to know if there is enough energy to work on a re-charter for the
SMIME working group and then produce an updated specification. If there is
enough interest, Stephen Farrell is willing to sponsor the charter.
I am willing to work on it.
Russ
On Jan 28, 2016, at 5:02 AM, Lijun Liao wrote:
Indeed there are much simple ways to get the encrypted messages by adding
some header fields like Reply-To, Sender, To, CC, etc. Since these header
fields are not cryptographically protected by the signature and encryption,
the recipient mail client is not able to detect the modification. If she
answers the email, a copy will be delivered to the attacker.
Sure the aforementioned attack can be HINDERED by the inline message type
message/rfc822 introducted in S/MIME v3.1. I use here the word HINDER instead
of PREVENT due to the fact that the specification does not prevent the
recipient client from using the outer header fields which are not protected.
By the way, not all of email clients (indeed I know none) can be configured
to accept only intern message/rfc822 type.
Lijun Liao
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime