Wow. The nice thing about SMTP is that everyone has an opinion, sometimes several. 20+ messages in under two days. I'll try to avoid repeating things that others have said, but... (1) The historical reason for a list, rather than a count, is that a count does not permit a "been here already" test. At least in the past, "been here already" tests have been as or more useful than counts for loop detection, especially when gateways to systems that use SMTP-like protocols are involved. (2) As others have noted, the trace has often been a critical debugging (and finger-pointing) tool. It is also sometimes been an important legitimacy-determining tool because it allows "could a legitimate message possibly have taken that path" examination. (3) There is no SMTP requirement that trace headers (really a part of the envelope, even while stored in the headers) be transmitted from the final delivery server to the message recipient or even to whatever is used as a mail store. Whether such information suppression would be helpful for any important threat model is another issue entirely. In most of the circumstances I can think of, suppressing or discarding those header would have few practical advantages and be fairly dumb but, "don't be dumb on delivery" is not an explicit SMTP requirement either. (4) For those that believe that exposing the address of an originating client machine poses a serious privacy problem (see Christian's notes for a clear discussion), Section 8, especially Section 8.8, of RFC 6409 (Message Submission) appears to me to provide more than adequate permission to rewrite those addresses in the submission server. That issue does not appear to me to be part of the SMTP discussion. Indeed, having an intermediate SMTP system decide what information should be rewritten or disguised seems to me to violate the general prohibition about messing with messages in transit of which the "don't change or delete RECEIVED header fields" rule is one corollary among many. <rant> Our current mail system, including the various evolutionary changes to both SMTP and Message Headers, has, as Dave Crocker pointed out, served the community rather well for 30+ years and a decade more than that if one counts the email-over-FTP period. For many of those years, it was the fabric that held the people of the extended Internet together despite poor connections, connections that were at best intermittent, interconnections to alternate network technologies, and competing mail protocols (both based on voluntary standards and quite proprietary). Things are easier today because most of those competing systems and technologies have faded away and most email connections go directly from the administrative scope that is, at least in theory, under control of the sender to one that is, also at least in theory, under the control of the recipient. In those "one hop over the public network" arrangements, this type of proposal would, independent of its other properties, accomplish nothing useful in terms of information-hiding. However, as people contemplate ways to get a little more performance, a little better privacy, a little better way to deter or filter spam, malware, or bad guys, I wish we could all keep in mind that no one with adequate authority has promised that today's happy situation will prevail forever. We are seeing a large collection of proposals and actions that point to national network boundaries; new, more politically-based, address allocation strategies; national content controls and filtering; and a whole series of other things. If the advocates of any of them succeed, we could easily find ourselves back in a situation very similar to the one we had in the late 80s and early 90s. I hope that few who are reading this would advocate that situation, but wishing won't prevent it. In that environment, network protocols that are dependent on single-hop end to end connections just won't work worldwide. In such a situation, a robust, international, gateway-friendly, store and forward email system could turn out, again, to be the best we can do. Let's try to avoid weakening it. In particular, let's be very careful that proposals that would weaken it in the interest of worthwhile goals, including privacy improvements, really bring enough benefits to be worth the costs and risks. </rant> john