Thanks SM good points (better than mine). Cheers, S.
PS: I'm looking forward to your up-to-date (re)reviews of other old RFCs:-) On 20/05/14 13:14, S Moonesamy wrote: > 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 > > _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
