--On Sunday, January 25, 2009 16:27 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
John C Klensin wrote:
(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.
Away from me pushing for that! Although it may seem easier to
manage reputation in a world with only a few providers, that
would make it hard for each of them to manage their users'
reputations.
Previous experience in other areas is that some of them would
equate "good reputation" with "pays our bills on time" and that
a free service, if forced to take any significant responsibility
for their users (like knowing who they are), would cease being
free.
Roughly, I'd say there should be an optimum when
the number of global ESPs more or less equals the number of
users per single ESP.
Hmm. I don't know what the current hotmail/Live, Yahoo, AOL, or
Gmail numbers are, but it one took an average of them to get a
target for total number of email providers... :-). And it is
not at all clear to me that one should equate an SMTP server
that supports a handful of closely-related people/accounts or a
small enterprise should be equated with an ESP for all purposes.
As with the DNS, there is a huge administrative and
policy-responsibility difference between a zone/registry
operator or administrator who maintains a domain in which
substantially all of the records are delegated to entities over
which they have little control or responsibility other than
through registration contracts and a zone/registry operator that
serves a single enterprise (even if there are delegations to
departments or other entities within that enterprise). In both
cases, the same DNS protocols are used, just as the same SMTP
protocol is used in ours. Another similarity is that the big,
highly-delegated registries tend to need extensive and
specialized registration and registry-maintenance tools (while
small and homogeneous zones are still often managed with text
editors) and a large ESP tends to need to worry about
sophisticated internal mail-management strategies, machine
clusters, separate sending and receiving machines, mailstores
that are not on the immediate receiving machine, etc. Writing
a comprehensive set of rules that would apply to both groups
--for either the DNS or mail case-- is probably not possible,
even without a lot of special cases.
I think there is actually another lesson about reputations tied
to identifiers in the DNS situation. In theory, one could have
a DNS regime in which obtaining a registration from an entity
outside one's household or enterprise zone would require
convincing proof of identity, guarantees (through credentials,
established external reputation, bonding, evidence of insurance,
or equivalent) of good behavior, and even showing of a natural
relationship between one's personal or enterprise identity and
the proposed registered names.
Indeed, to differing degrees, some TLDs used to do just that.
But, in modern times, the privacy interests didn't like those
models very much and the commercial ones --especially those who
were interested in selling as many names as possible while
minimizing costs-- liked the idea even less.
Unless one involves governments in a big way (and, for some
governments, maybe not then), I'm not sure why an identity and
reputation system would not go down exactly the same path.
...
A real example: I receive "EHLO fk-out-0910.google.com" rather
than "EHLO gmail.com". The latter would match the DKIM domain
in the body. The former correctly resolves to a block of 8
addresses, one of which is the one being used. That host does
not pass SPF HELO checks. Google's staff certainly have more
than moderate competence. Since they don't backscatter, they
probably assume that passing SPF MAILFROM is enough,
notwithstanding those who think SPF is better at HELO (doesn't
break forwarding.)
Another commonly used SMTP-level check is greylisting, which
also has troubles trying to match those fine grained FQDNs.
Two very general observations:
(1) You have just explained --whether you intended to or not--
why it is much better to tie policy information to the domain in
the MAIL command than to the one in the EHLO/HELO command. In
your example above, Google is behaving in an exactly correct
way, consistent with the spec: EHLO identifies the transmitting
host, not the address of the mail sender. If that fouls up some
verification protocol, that is a deficiency in the latter.
(2) Even more generally, the various efforts to design and
specify verification and validation procedures for email really
need to start, IMO, with an understanding that the current specs
and installed base are a given and that a combination of the
robustness principle and operation experience prohibits action
based on a possible protocol-lawyer's reading of those specs.
As soon as one goes down the path of wanting to change,
restrict, or reinterpret what the specs say about particular
fields, you are restricting the applicability of your method to
a select group of friends at best or falling into one of the
more obvious "Anti-spam Kook" traps of requiring universal
deployment of your "improvement". You have the perfect right to
reject any mail that doesn't conform to your ideas of what an
envelope should look like (with or without support from the
specs), just as you have the perfect right to reject any message
with Chinese content on the grounds that you don't read Chinese
so it couldn't possibly be for you and is therefore probably
either malware or just unwanted. But either path is going to
reject legitimate messages from folks who, through no fault of
their own, don't conform to your expectations. Personally, I
don't think that is a good idea. On that subject, YMMD. But
making significant changes in the standards, changes that would
invalidate many or most existing conforming implementations, to
reflect your ideas of how things would work in a better world...
well, probably isn't going to happen.
...
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.
That's after that prohibition in 4.1.4. I don't know _when_ it
will be savvy to reverse it.
Nope. The prohibition is designed to protect a lot of
legitimate cases and is consistent with the semantics of that
field in 2821, 5321, and 1123's interpretation of 1123. It
appears to me that what you are asking for is that we change the
semantics of the field and, having made that change, remove the
prohibition in order to make the changed semantics more useful.
See above.
Since we're talking about banning HELO for relays, I suggest
it may be a good occasion to also modify its argument
slightly. As someone pointed out, we would need a way to
verify it. For global Internet, that implies looking up the
identifier in the DNS, in order to match the connecting IP
address. SPF is an example of an alternative to an A record.
I'm not trying to push SPF here, really. I'm suggesting that
the requirement that "the argument clause contains the
fully-qualified domain name of the SMTP client" could be
relaxed by only requiring that the name matches the address of
the client in some standard way. It should consistently
identify all hosts of an ADMD when they connect to external
hosts. Semantically, that is equivalent to overloading the
Standardized-tag, that I already proposed.
As I said, big change in semantics (we differ about "slightly"),
especially since, while it is convenient to talk about ADMDs for
some purposes, SMTP has no such concept (and, if you don't
understand the policy implications of the X.400 definition of
ADMD, you probably should, because it is very much tied up with
my comments about types of ESPs above).
But the big problem is, again, transition, since a server would
have no way to tell whether a client was legitimately and
appropriately providing a name under the old rules or under your
new ones. And that takes me back to my earlier suggestion: if
you want this information, define a new extension or keyword for
doing it, one whose argument semantics you really can control
and one whose use would explicitly invoke your rules and
interpretations. Although I'd predict that you'd have trouble
getting it off the ground, another possibility would be to
propose to replace EHLO with a validated-hello command, VHLO,
which would be just like EHLO except for support for a different
argument architecture. It would take me about ten minutes to
write an I-D specifying that. Of course, it would take me even
less time to shoot the idea down on the basis of deployment
costs, etc., but, again, your mileage, and assumptions, may
differ.
john