Hi Hilarie,
Typo in 2.2 "to some extend" should be "to some extent".
Thanks.
In 2.5, "not longer delivered" should be "no longer delivered".
Thanks.
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.
The headers mentioned in this section are email headers that are
in the SMTP payload, i.e. not SMTP dialog information (from RFC 2821)
that is discarded but header data that comes with the message
body (RFC 2822); most clients preserve that info. Often not displayed
by default but an option in the email programs to read those.
I don't say that all recipients will be able to see those headers
but the chance is indeed much higher than in the HTTP case, where
we have added trace info to the HTTP header which is not visible
for the vast majority of web users.
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 stated explicitly.
What I was trying to write about is a case such as this:
The OPES callout server has a bug, was hacked or has another
malfunction that results in misconfigured email recipient data,
could be syntax errors in the email address, replacement of
the original address by non-existing domains/addresses, etc.
The OPES processor (SMTP gateway) will then not be able to
deliver that message, even if it does not check for "deliverability"
because either the destination cannot be reached or the
destination will reject the message.
In these cases the OPES processor is required to send a NDR.
In 3.1, note that if the administrators aren't sending NDRs
for ordinary email, they certainly can block OPES NDRs.
Sure. There is no guarantee that OPES trace info makes it way
to recipient or sender.(Similar to HTTP where an intermediate
could delete all trace data).
We are not able to solve these issues.
The issues surrounding receiver preferences and policies is
addressed in RFC3838. That, and RFC3835, should be
referenced in this document.
Can do.
3.3 is about encryption but mentions signing as well. The
key management issues are completely different for signing.
Agree. Encrypting an email for a receiver only requires that
person's public key, signing requires the sender's private key.
Still important to mention as a good way to detect/prevent that
an intermediate (OPES or something else) changed the message.
I can try to make this a little more clear and adjust the
section title to include signing.
I don't understand how encryption could be used for approval.
If an email is encrypted only those with access to the decryption
key can apply content filters. Users that make their OPES system
the decryption key available give an explicit approval to those
systems.
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, etc.).
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 don't understand what you are commenting here. What have the
crypto options and the bypass SMTP dialog extension in common and what
is the issue here?
I was surprised to see this requirement:
OPES/SMTP MUST define a bypass request option as an extension for
SMTP dialogs
Should it be requirement, given that it probably won't work?
The requirement is for the SMTP adaptation draft to define such an
extension. Bypass will often not work and we cannot require that all
systems (OPES and non-OPES) must support this.
But in order to handle the IAB considerations properly, I think, we
must define the bypass options so that they work at least in an
optimal environment.
Anyway, the bypass request seems to be only thing required of
the sending side.
How about other considerations, like misdelivery due to OPES
modifications,
could be mentioned. If the message can be delivered but reaches
not the correct recipient, the trace info will help to resolve
(hoping that the incorrect recipient tells the sender).
the possibility of disclosure of private
information through OPES notations (tracing, NDR, bypass
requests, etc.),
A general issue with OPES tracing. Application agnostic. Didn't
we discuss that elsewhere.
or DoS attacks that a lot of NDR or trace
info going back to the victim?
DoS attacks are possible in general and discussed in RFC 3837.
Trace info and NDR can only be one per original message.
Martin