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

[Hector Santos <[e-mail]>]

On 3/29/2014 2:59 AM, Kevin M. Gallagher wrote:

> What do people today think of the SMTP RFC's current requirement that
> mail programs and servers must not under any circumstances change or
> delete Received: headers?

I will provide a different perspective other than the typical trace, 
debugging and technical support reasons and why they are useful for 
those moments.

There was never a requirement to retain HEADERS at the final 
destination.  The historical main reason is because of gateway 
transformations.  There are other formats that predated x822/5322 
electronic mail storage formats.

The 5321 "requirements" is more about not TAMPERING with passthru mail 
(relays), and there is legal precedence for not tampering with 
transient communications laid out in the 1986 US ECPA.  Of course, the 
mail body content SHOULD NEVER be tampered.  Mail hosting systems such 
as ours were long molded from this ethical mail hosting design model.

> Is exposing sender IP addresses to any
> attacker who can view e-mail headers, for the purposes of preserving
> trace information, really worth it when weighed against considerations
> like security and privacy?

Again, if you are relaying mail, you really have no choice here.  You 
have to keep and pass it on.  If you don't, then you are not playing 
the game right, plain and simple.  You might not be helping the 
downlinks of the message (the true final destinations) if there a 
problem.

So you are really just talking about LOCAL FINAL DESTINATION mail.  I 
think that applies for (meta) data that is created temporarily as 
well, i.e. you might add a trace meta header for your own internal 
mail routing purpose but it is finally pulled before it goes out or 
the end user gets it.   There are a few headers like that, the 
Return-Path is one of them where it is added but then POSSIBLY pulled 
by an implementation.

Historically, they helped in support but yet at the same time, you had 
a small mistrust in them as well as you are suggesting here.  You 
extracted what made possible sense and thats it.  I personally think 
the IP concerns, while possible and real, are very isolated.  The 
support needs are also isolated but I think its one of those things 
where you desire/wish for the information when the relatively few and 
increasingly rare support times comes.

Overall, I always had an strong ethical engineering position on never 
destroying information especially at the passthru (relay) level. 
There is/was legal precedence for this.   At the local level, we also 
had a need to provide mail gateways for other formats and there are 
many headers that are not part of the transformations.  The Received, 
and the potential to have many of them, was not one of them.  When a 
gate was performed, the necessary Network Control Lines, headers that 
allowed for replying and continued network communications to take 
place, where added to "meta" storage. But the the remaining overall 
was pruned.  If there was a support need, you enabled the preservation 
of the full RFC headers and told the user "try it again."

That said, as the mail systems and END-USERS evolved to include more 
multi-media information, like HTML, MIME, etc, it became increasingly 
necessary to PRESERVE the original message format. This became more 
true as users moved away from online to offline RFC reader/writer 
communications, i.e. POP3, where online it (display rendering) was 
fully controlled by the backend server, but with POP3, the backend 
lost the control of what is possibly displayed.

But with the movement or recycling back to online is taking place, you 
don't really need all the headers and there are lots of wasted 
overhead for sure. Most Users don't even know what they are anyway or 
even care.  Its all for those rare support needs and thats become so 
infrequent, who knows, maybe the next big interested I-D would be how 
to clean up all the x822/5322 mess.  Have you see the junk in those 
stuff?  Junk that could expose security related info or just plain 
nonsense that doesn't apply to you anyway.  ALL those X- headers. 
Thats information you certainly don't need 80% (pareto) of the time.


-- 
HLS