Keith and Hadmut both have valid points. It is futile to expect Keith to
change his POP configuration. However Hadmunt is correct in stating that a
DNS name owner should have the right to be able to control the manner in
which email is sent from their zone.
I have a particular sympathy for Keith's issue since it is actually one that
affects many VeriSign (Network Solutions) customers. These customers buy a
hosted mail service with their domain name. In many cases they take their
incomming mail via the NetSol service but relay their outgoing mail through
the mail servers of their ISP. In many cases they have no choice about this
as the ISP blocks outgoing port 25.
Let us assunme for a moment that the Internet community will accept such a
disruptive change that provides no value until widely deployed. How long
would such a change take to deploy?
In an earlier message someone said changing the infrastructure would 'take
years without Microsoft and Qualcom'. I have news for folk who believe that,
it will take years WITH Microsoft, Lotus, AOL, Qualcomm and the rest.
Without it will take decades. Transition strategies are key.
The key to any authentication based approach in an environment where there
are many parties with no authentication capability at all is to have a
mechanism to exzpress and distribute the authentication policy of a
particular party.
The limitation to the RMX approach and the various lightweight
authentication mechanisms is that they only support one means of
authentication at one level of the protocol stack. It should be possible for
a zone to choose any authentication mechanism that suits their
configuration. Hedmund directs all his mail through one central server and
so can use a transport or packet layer authentication mechanism. Keith does
not send his mail through a particular mail server and so any authentication
mechanism he chose to use would have to be message based. He could use PGP
or S/MIME.
This same problem is biting us when we try to deploy IPSEC on an Internet
wide basis. Most nodes are insecure. So how do you know whether an apprently
insecure site is actually a secure site that has been the victim of a
downgrade attack.
I am currently writing a draft that proposes a generic security policy
expression mechanism for Internet protocols. This is a logical counterpart
of work that VeriSign, IBM and Microsoft have recently published that
defines security (and other) policies for Web Services.
Clearly the most appropriate mechanism for distribution of such a mechanism
is likely to be DNS. However I believe that any proposal should be generic
enough to be compatible with other bindings.
A DNS binding is likely to benefit from DNSSEC, although not if DNSSEC can't
be deployed in dotCOM and dotNET. I do not agree that securing the DNS is a
precondition for being able to make use of DNS based security policies to
secure email transport for the purposes of spam control. The widespread DNS
spoofing scenarios proposed are theoretical not practical. And if they did
prove to be practical it would merely create the currently missing
imperative for DNSSEC deployment - not a bad thing in itself.
I intend to circulate a preliminary draft before the SF IETF, I know I have
missed the cut off but I will post to the list. I believe that such a work
item could be persued as a focused WG in the IETF without waiting for this
research group to terminate since it would only be part of the solution to
spam and would address a problem more general than spam. I intend to propose
a BOF for the Vienna meeting.
Phill
-----Original Message-----
From: abuse [mailto:abuse(_at_)aniota(_dot_)com]
Sent: Thursday, March 06, 2003 2:55 AM
To: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Deprecating plain POP accounts
... somehow, the idea of 'eliminating' "POP" accounts falls short of a
reasoned solution. if i'm mistaken, and this a viable
alternative, why
not eliminate SMTP altogether ...
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg