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

[John C Klensin <[e-mail]>]

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