ietf
[Top] [All Lists]

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

2014-03-29 20:02:38
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



<Prev in Thread] Current Thread [Next in Thread>