Re: [perpass] draft-josefsson-email-received-privacy

[Jacob Appelbaum <[e-mail]>]

On 10/23/15, Simon Josefsson <[e-mail]> wrote:
> Hi Ned,
>
> Thanks for looking at the document!
>
> We are happy to make this more inline with what you and others are doing
> or suggest to do.  With the -00 we wanted to get the ball rolling, to be
> able to discuss what to do about the problem.  We don't care strongly
> what the particlar approach is as long is it does its job.  Given the
> responses so far, I believe we even have some work to do on getting the
> problem statement itself right, let alone the proposed solution.
>
> I agree with you about the problem related to loop detection (RFC 5321
> section 6.1), so agree that it is a valid argument for not making the
> header optional.
>
> Jacob Appelbaum brought up that the trace information about what
> authentication parameters were used can be interesting and does not
> appear to be a significant privacy violation.  So that's another
> argument for retaining the header.  He also mentioned that timestamp
> information are problematic due to netflow related data.
>

I think it should be possible to produce a general timing and to state
the crypto (or lack of crypto) used for transmission.

> I agree with your recommendation to retain the Received header but
> modify what to put in it.  I believe the FROM clause should be removed
> completely, or we put in a "magic" (syntactically valid but semantically
> invalid) IPv4 or IPv6 address in it.  Similarily, implementations could
> put a magic time-stamp value in the field if they don't want to reveal
> when they received a particular message.
>

Those both seem reasonable.

> When I look at the ABNF for Received in RFC 5322 I'm confused as I don't
> see how the normally used Received: headers on the Internet (i.e., with
> 'FROM', 'BY' etc clauses) actually conform to the 'received' ABNF token
> or the 'obs-received' token.  Is this a RFC 5322 bug?  The BNF in RFC
> 822 and RFC 2822 appears to work.

A feature!. ;-)

All the best,
Jacob