At 10:15 AM 1/24/2009 -0500, John C Klensin wrote:
--On Saturday, January 24, 2009 15:37 +0100 Alessandro Vesely wrote:
...
Keep in mind that there are things that send SMTP that don't
know their own names, may know there own addresses only in
private address space behind a NAT, and have no way to anchor
SPF information even if they wanted to.
I think the question is whether we want those things to be
able to send to any host but their configured gateways. Since
the split between submitters and relayers, time should be
mature for requiring the latter ones to behave somewhat
decently. Most of them actually do.
And that was exactly why my initial note tried to say "if there
is a sender that can't follow the rules because it doesn't have
enough information, it should be using Submit". I think our
preferences there are the same, and Randy and I didn't do RFCs
2476 and 4409 simply because we wanted to raise our RFC-count.
For better or worse, two operational realities intrude on going
very far in that direction:
(1) Many of those "configured gateways" aren't configured and
implemented to support Submit -- in the sense of either not
supporting 587 or not providing the "if you get trash, either
reject the submission or fix it so that anything you push onto
the public Internet meets the spec and intent of 5321/5322"
functionality that Submit expects.
A "gateway" (MSA) can be much simpler than this. All it takes is some way to
avoid the MSA being used as an open relay. 587 is nice, but for operators who
don't have that level of expertise, there are simpler ways.
(2) We should not forget that there are full-service SMTP
clients running on portable machines, small networks, without
unlimited resources, and/or serving small numbers of users.
Forcing all of those servers to be configured to use Giant
Provider gateways to send mail would be... well, a very
significant Internet policy change.
I would say "expecting" not "forcing", and I don't see any need for a Giant
Provider. People who operate radio transmitters are forced by law to abide by
regulations and pass tests ensuring their competence. People who operate
Internet transmitters should be expected to be honest and competent. That
expectation can and should be established by a standards group like IETF.
I understand the principle that the Internet should be free and open, but as
you say, realities intrude. I would gladly trade the freedom to operate a
transmitter from my digital camera for the benefit of getting rid of
incompetent and dishonest operators.
The EHLO name has better be unique for tracing and debugging.
OTOH, it has better be "meaningful" for filtering and
reputation management. Do these two kind of activities somehow
match the scenarios implied by that split?
Not sure. But let me suggest an orthogonal distinction. If one
assumes a sender of moderate competence acting in good
conscience and trying to make things work as well as possible,
the EHLO name, provides useful information for tracking down and
debugging, e.g., mail system failures, especially if it is used
in conjunction with other information that requires the same
assumptions. If one assumes a sender of moderate (or greater)
competence who is a Bad Guy trying to trick a recipient system
that doesn't want his traffic into processing and accepting it,
then domain names, IP addresses, etc., just aren't going to be
good enough.
I disagree. If a sender was expected to declare its identity (not a machine
name, but the identity by which the world will judge the sender's reputation),
then SMTP could say "good enough", the rest is up to others.
The reason we have such a mess right now is that everyone who could do their
part to fix things says the problem is hopeless, we can't do anything because
those others won't do their part.
Of course, if one can assume that all Bad Guys are going to be stupid and
lazy, the equation changes.
Nobody I know makes that assumption. A more reasonable assumption is that the
Bad Guys won't be able to use the identity of a Good Guy who is honest and
competent.
-- Dave