At 4:31 PM -0500 2/7/02, James E. Agenbroad wrote:
> Thursday, February 7, 2002
>Would making the about to be misled respondent type the address of the
>intended person (with a roman 'o', not a greek omicron) and then having
>the system see if they match detect and thwart such tricks? The
>respondent is already typing so it's not a large extra burden.
Yes, that would probably work, though users would complain. Having
the outgoing SMTP server drop all messages addressed to spoofs of the
corporate domain works too on an enterprise level. And using message
authentication based on public-key certification works too.
The problem is that all of these or any other client-based solution
you come up with is only going to be implemented in some clients.
Many, and at least initially most, users are not going to have any
such protections. This needs to be cut off at the protocol level. It
is far better to prevent the spoofed messages from being sent in the
first place than to offer clients tools to stop them once they're
free in the ether.
The maintainers of the Net and the Web at all levels from local sys
admins to ISPs to spec implementers to spec writers to router vendors
are rushing from hole to hole, trying to plug them faster than the
script kiddies can exploit them. Even Microsoft is starting to
recognize their culpability for producing an insecure infrastructure.
This is a result of years of Internet development in all layers from
the physical hardware on up to the browser without a real
understanding of security.
For past protocols like HTTP and URLs, we can plead ignorance and
lack of imagination. We never knew how bad things were going to get.
Now we do. We no longer have any excuses for knowingly designing
systems that are open to spoofing, denial of service, or outright
system cracking. Mistakes will of course continue to be made, but we
have to try to make as few as possible and fix the problems where we
can as soon as we can. There are legacy problems in HTTP, DNS, URLs,
and many other systems; but when we're designing something truly new
like internationalized domain names it only makes sense to avoid
these known problems.
--+-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java news: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML news: http://www.ibiblio.org/xml/ | +----------------------------------+---------------------------------+
This archive was generated by hypermail 2.1.2 : Thu Feb 07 2002 - 22:11:48 EST