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

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

--On Sunday, March 30, 2014 17:31 -0400 Phillip Hallam-Baker
<[e-mail]> wrote:

> On Sun, Mar 30, 2014 at 2:09 PM, John C Klensin
> <[e-mail]> wrote:
> 
>> 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.
>> 
> 
> I still don't accept mere debugging as a rationale for MUST.

Whether one accepts it or not, "been here already" tests are not
about debugging.  They are about loop detection and DoS attacks.

> But I can extend the case to MUST: Attacker subscribes two
> mailing lists to each other. Thus setting off a spam loop.

Yes.

>> (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.
> 
> It depends in part as to whether SUBMIT and SMTP are treated
> as separate protocols. I think they should be since mail can
> only cross once from the SUBMIT port to the SMTP port. And the
> acceptance of the SUBMIT mail should be authenticated in any
> case.

While I don't think SUBMIT has anything to do with whatever a
final delivery does, while they share a command structure, they
are as much separate protocols as the IETF can typically
arrange: different conformance rules, some differences in
command structures, different ports, etc.

> If we assume the mail traffic is all over TLS, 

It is not clear to me that discussing models based on obviously
counterfactual assumptions is a good use of time.

> for non mailing
> list mail, there are three spans at issue:
> 
> 1) User's mail client to outbound email server via SUBMIT.
> 
> 2) From the user's outbound mail server to the inbound mail
> server specified in the destination address. (ignoring
> outbound mail forwarding for the mo).

Please read the part of my note that argued for preserving the
multi-hop model.  You are not only assuming TLS, you are
assuming TLS in a "no relay" environment.  Sorry, but that
discards enough of SMTP's capability's and model to make your
discussion uninteresting.
>...
  
>> <rant>
>> 
>> 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.
>> 
> 
> There are certainly governments trying and at least some will
> succeed.
> 
> I don't think we can stop them but the people who they are
> trying to control can.

The point was intended to be that we have a mail system
(critically including, but not limited to, SMTP in all of its
sometimes-inconvenient MX-as-gateway, multiple hop, glory) that
has proven very successful in getting messages past and around
government-imposed and technological blockages.  Models and
systems that assume or force having only one hop between what
you describe as the user's outbound mail server and inbound mail
server considerably weaken the potential of that model.  That,
in turn, makes it much easier for governments and the like to
block email traffic along with anything else they might block.
I don't think we should hand them that victory just because it
is easier to think about SMTP in the sort of model you describe
above.

Folks, if we really need to continue this conversation (I hope
we don't), can we move it to the SMTP list?

   john