PM> No, I think it's much closer to preregistering a small,
fixed set of
PM> operators who are willing to relay your call.
Sorry, no. The relevant MTA is the point of access into the mail
distribution service. That's equivalent to a telephone handset.
Without appologies - NO! WRONG!
The equivalent of a telephone handset is the mail client. Note that
I use that term not 'MUA', the user knows it as Outlook, or Eudora.
The user is not aware of the MTA, any more than they are aware of the
'exchange' they might hypothetically be on. But exchanges have ceased
being real for many years. I have a phone line that answers a number
dialed on a different continent.
It is a ridiculous analogy in any case since junk telemarketting
calls were a serious problem before the do not call list and the
only reason do not call is practical is that every telephone call
is traceable to physical source.
The operator is a back-end process that enables the handset, just as
MTA registration schemes are back-end processes that enable the MTA.
But the access unit comparison is mta:phone.
No.
By and large, folks tend to be distracted by knowing too much about
underlying technical and economic details.
By and large folks seem to be distracted by irrelevant technical
comparisons.
My comments are trying to focus on end-user and administrator impact.
There are all sorts of technical and economic differences between
Internet mail versus the telephone system. But my point is not about
those. I am simply concerned that the real impact of our choices be
clear. Very clear.
The choice is very clear, always has been. A tiny number of geeks who
insist on sending their mail direct from the IP address they happen to
have obtained on an ad-hoc basis are going to have to 'go figure'.
This is simply not a problem that affects the vast majority of email
users whose mail connections have always been routed through a specific
set of MTAs.
PM> All this talk of analogies between the email system and
any other system,
PM> for communication or anything else, does nothing to
advance this discussion.
That's unfortunate, because implications are rather important, when
making changes to a service that is already in use by 1/2 billion
people.
Thats a billion people according to the latest estimates. But waving
scary numbers does nothing to change the facts. This problem has been
understood by several people backwards and forwards for over a year.
We absolutely get the fact that some people will find that they have
to change the way they send mail if they are to use authentication.
We absolutely get the fact that certain hacks and work-arrounds in the
mail system that allow one person to impersonate another will stop
working. That is not an accident and is not considered to be a flaw
in the design.
We absolutely get the fact that when some domains configure their
systems to use authentication, some users of that domain will find
that their mail now bounces.
The email system of RFC2821 is on life support. It will be dead
within a year.
Trying to project effects, without looking around for services that
provide some historical perspective, is a good way to project
idealized effects that will not be borne out by actual experience.
There is plenty of experience of SPF. There are plenty of spam filters
applying SPF today.
Historical analogies are not very helpful, they can provke thought
but they can also be dangerous. Almost every case where I have looked
at a security disaster it is because an inappropriate metaphor was
applied - Wired Equivalent Privacy being a great example, the name
shows why the protocol was doomed to fail, the key security issue is
not privacy, it is access control.
When you start an analogy by comparing something few mail users are
ever aware of to a telephone handset it is time to call bogus.
Phill