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

[[e-mail]]

> Hi,

> draft-josefsson-email-received-privacy-00 has been submitted, see
> https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/

> I'd be interested in hearing what people on the perpass list think of
> this.

It looks to me like the IETF is belatedly coming up to speed on a problem that
the email community - the large scale providers at least - is already in the
process of solving. And while it would be nice to write down some best
practices here so everyone knows what to do, the method described  in this
draft is *not* that best practice in any way, shape or form.

In fact its adoption would cause widespread damage to the email infrastructure.

Getting down to specifics: This proposal effectively makes the addition of
Received: fields optional: You only do it when you feel like it. The
obstensible purpose of this change is to prevent exposure of the sender's IP
address in the context of pervasive  surveillance.

However, this removal, were it to occur, is not terribly effective in achieving
this specific goal. Why? Because this does nothing prevent the IP address from
being logged elsewhere. And those logs often enjoy far less legal protection -
in some cases no protection at all - than actual message content. And good luck
convincing ISPs and MSPs not to collect this information.

If anything the removal of this information from messages for this claimed
result may create a false sense of security in regards to persuasive
surveilance.

All that said, there is a real privacy gain in not including this information
in messages. State actors with subpeona powers may have easy access to ISP/MSP
logs, but other players, including legitimate message recipients, do not. And
my location at the time I send a piece of mail really isn't the concern of any
of the message's recipients unless I choose to reveal it.

So where is the information stored and how can eliminate it safely? It's in the
from clause of the Receved: field generated by the SUBMIT server. The from
clause is mandatory, but there's noting that says the clause has to actualy
contain anything meaninful. So the obvious solution is to dummy information.
(My personal preference would be to define a well known name or names for this
purpose and use that without any IP address information at all, which the ABNF
in RFC 5321 explicitly allows.)

And this approach has already been deployed, successfully AFAICT. (To be fair,
gmail appears to have done it by dropping from clauses entirely - a syntax
violation.) We added an option to override the from clause to our product a few
months ago. (And I'm told we're fairly late to this particular party.)

Now, received fields are, as the draft notes, generated at other times, and the
name/address information in them can reveal internal network topology to some
extent. This concern is, IMNSHO, considerably overblown, but sanitizing from
clauses generated by internal relay steps may make sense in some specific cases.

And what about other aspects of the Received: field? The remainder of the (all
optional) clauses that Received: fields support also reveal information to some
extent and a detailed security analysis of all of them should be undertaken as
part of any work undertaken in this area.

That leaves the presence of the Received: field itself and the timestamp. The
former is critical to the proper functioning of the email transport
infrastructure: Received: field counting is the primary mechanism used to
prevent mail loops. And there's ample operational experience in the field with
the bad things that happen when the requirement to add Received: fields is
ignored or agents remove them willy-nilly.

The timestamp is quite useful in tracking routing delays after the fact. It
also doesn't reveal all that much given how it's going to be brackted by the
Date: field and the IMAP internaldate.

In summary, the present proposal as presently written is a nonstarter because
it breaks critical email functionality: The ability to detect and block mail
loops. In also unnecessarily causes the removal of highly useful timing and
trace information. An approach based on current inductry practices should be
considered instead and specific guidance on when the mechanism should be
employed needs to be given.

				Ned