RE: SMTP RFC: "MUST NOT" change or delete Received header

[Christian Huitema <[e-mail]>]

>> I think the privacy beach from exposing intermediate steps is small,
>> and in some cases knowledge of the routing may be required by law.
>
> That has always been my engineering understanding, and it predated the 
> IETF RFC electronic mail format.

I flagged that in the perpass draft that I wrote back in November. Exposing the *intermediate* steps is pretty much harmless, but exposing the *initial submission* step does convey some interesting information. If you use the combination of IMAP and SMTP submission, the traces convey the current IP address of your laptop, or record its successive IP addresses as you move.

When SMTP was designed, the practice was to submit your mail directly from the server. The web based servers and many corporate servers still follow that model. The first SMTP step was from a fairly well known server to the next relay. There is no particular privacy issue with the trace field in that case, since the mail server name can pretty much be inferred from the sender's address, and the IP address can be retrieved from the DNS. The same is true for intermediate relays, which are (or should be) publicly advertised in MX records. 

Now look at what happens If you use IMAP or POP3 to retrieve your mail on your laptop, or tablet, or phone. IMAP and POP3 do not enable mail submission, so you will normally use SMTP. Your laptop becomes the first step in the transmission chain. The first "Received" header carries its IP address, the laptop hostname, the time of submission, and very often other information like the type of security being used. This will be available to anyone who can observe the mail in transit. Should you send an email to a mailing list, the information becomes available to all mailing list recipients.

There is a strong case that the "SMTP submission" information should be removed from the trace fields for privacy reasons.

-- Christian Huitema