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