Typo in 2.2 "to some extend" should be "to some extent".
In 2.5, "not longer delivered" should be "no longer delivered".
In 2.5, the assumption that the recipient can read all email headers
is false, because many email systems terminate SMTP and discard header
information before the addressee can read the messages.
I do not understand how a system administrator can configure email
handlers to detect that some messages cannot be delivered because of a
"compromised" (or even just plain broken) OPES system. I suppose that
all email could be checked for "deliverability" before and after OPES
modifications, but if that is the requirement, then it should be
In 3.1, note that if the administrators aren't sending NDRs for
ordinary email, they certainly can block OPES NDRs.
The issues surrounding receiver preferences and policies is addressed
in RFC3838. That, and RFC3835, should be referenced in this document.
3.3 is about encryption but mentions signing as well. The key management
issues are completely different for signing.
I don't understand how encryption could be used for approval.
Besides, there are many facets to the use of cryptography with email.
OPES itself might be doing the encryption or signing, messages might
be encapsulated or might have a mixture of parts (ala S/MIME, Secure XML,
Because of this:
Bypass request data sent at the beginning of a SMTP dialog may not
reach the OPES system if intermediate SMTP relays do not support
those bypass request commands and don't forward that information
I was surprised to see this requirement:
OPES/SMTP MUST define a bypass request option as an extension for
Should it be requirement, given that it probably won't work?
Anyway, the bypass request seems to be only thing required of
the sending side.
How about other considerations, like misdelivery due to OPES modifications,
the possibility of disclosure of private information through OPES
notations (tracing, NDR, bypass requests, etc.), or DoS attacks that
a lot of NDR or trace info going back to the victim?