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 | [EMAIL PROTECTED] | 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/ | +----------------------------------+---------------------------------+
