On Sun, Mar 30, 2014 at 2:09 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
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/