--On Sunday, March 30, 2014 17:31 -0400 Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com> wrote:
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.
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