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

[Phillip Hallam-Baker <[e-mail]>]

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.

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


> (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.

If we assume the mail traffic is all over TLS, 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).

3) From the inbound mail server to the final destination.

Span 3 is all under the control of the recipient mail domain. Those headers
might leak information to the recipient about their provider's
infrastructure but they are not leaking information about the sender.


> (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.
>

Agreed


> <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.

-- 
Website: http://hallambaker.com/