Hello,
I took a quick look at RFC 5068. In Section 3.1:
"For a reasonable period of time after submission, the message
SHOULD be traceable by the MSA operator to the authenticated
identity of the user who sent the message."
There is a typo in the above for NSA operator. :-)
"Such tracing MAY be based on transactional identifiers stored in
the headers (received lines, etc.) or other fields in the message,
on audit data stored elsewhere, or on any other mechanism that
supports sufficient post-submission accountability. The specific
length of time, after message submission, that traceability is
supported is not specified here. However, issues regarding transit
often occur as much as one week after submission."
The problem in the above (and the previously quoted paragraph) is
traceability and accountability. It should be possible to address
that without causing significant problems to the email infrastructure
as it does not entail protocol changes. There is already an identity
in the message header. It would be difficult to tackle
that. However, there isn't a need to disclose other identity
information (authenticated identity) in the message headers.
Section 4 mentions the following (Stephen mentioned that in his message):
"Examples include active privacy protection against third-party
content monitoring, timely processing, and being subject to the most
appropriate authentication and accountability protocols."
The problem here is that the user can be tricked into using a local
submission proxy. It is worthwhile to review that section and
provide some guidance if active privacy protection is the goal.
In Section 5:
"Mechanisms might also have to be used in combination with each other
to make a secure system. Organizations SHOULD choose the most secure
approaches that are practical."
The following does not provide much guidance to the
organization. The next paragaph in that section does mention that
"transmitting user credentials in clear text over insecure networks"
should be avoided.
The Security Considerations might not pass an Evaluation
nowadays. Note that I did review RFC 5068 previously and as I look
back I could say that I didn't do a good job. :-)
Regards,
S. Moonesamy
_______________________________________________
ietf-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
