comments on directory services
One of the ideas tossed about was to implement a system that would make it easy for any MTA (Mail Transfer Agent--the programs that deliver e-mail on the Internet) to verify that a message that claims to be from email@example.com really is from a yahoo.com user.
Any MTA? Or the MTA at Yahoo?
This basically entails linking the MTA to the directory so that the contents of the RFC 821
MAIL FROM: envelope header are confirmed to be valid, deliverable addresses. This is distinctly different from confirming that the
MAIL FROM: belongs to the sender, which is one of the things the SMTP Authentication extension attempts to do — assuming that the entity with the ability to authenticate to the MTA is also the entity whose address is in the
MAIL FROM: header. However, confirming that the sender's address is valid, even for one's own domains, exposes another problem — automated scanning of the directory — while not effectively eliminating the problem of fraudelent senders.
Say someone would like to deliver mail to firstname.lastname@example.org, but wishes to not use their own address. They would merely need to use an address, not the same as the recipient address, @yahoo.com as the sender. Authentication would work to ensure that the sending entity has at least some passing relation to whom the mail says it is from, but with a free mail service there's no barrier to establishing disposible accounts for spamming purposes.
Now, the directory scanning would be made possible by collecting responses to addresses given as possible
MAIL FROM:s. This is slightly more efficient than collecting non-delivery notifications resulting from a spam.
On the other hand, we do want valid addresses, rather than fraudulent, invalid ones.
David Fletcher points out Maporama. I like this one. MapQuest used to provide the latitude and longitude for the point mapped, as part of the graphic, but stopped doing that. Maporama provides it, in text!
Paul Shane and I once discussed linking phone numbers to GPS information. Towns pay big bucks to do this for 911 implementations. Emergency services should be able to find their way to the emergency given just a phone number, if necessary. We were disappointed to find that while MapQuest provided latitude and longitude, and let you search by them, it did not provide a means to search by phone number. Nor do Maporama or Yahoo! Maps. What Google does is join the information in the telephone directory with the information in the geographic directory, mapping a phone number to a place, or a place to its phone number.
Can you imagine how joining these databases could change caller identification? Ignoring the unreliability of the Caller ID information for the moment, consider what you could do with CTI at home. Suppose your phone could speak to your computer, and you have a persistent Internet connection. A call comes in, carrying Caller ID data. Your system takes the data, maps the phone number to an address and a name, shows you where the call originated, checks your address book for more personal information, locates the web site related to the calling number, and the next thing you know you're watching the web cam of the little twit who thinks he's being funny by prank calling during dinner.
But then, that's a typical CTI fantasy.
David Weinberger [via sysrick] pointed out Google's phonebook. In combination with street maps, they can take a phone number, or a combination of attributes, and show you where someone lives — or at least what phone number is associated with which premises — if the number is listed. Maps are provided indirectly by Yahoo! Maps and MapQuest. (Google constructs the appropriate URI for finding that location on the map while you rest.)
What remains is for Google to relate "+will cox" to "william cox" and other variations of my name, and tie my domain to the telephone and map directory. The data is already there, though I could help Google along by providing a bit of text in the sidebar. Thus the tangible and virtual worlds join.
(Meanwhile, Google Cooking is helpful for those last minute refrigerator cleaning sessions.)
The federal government will not have the authority to nationalize drivers' licenses and other ID cards. Authority to design and issue these cards shall remain with the states. The use of biometric identifiers and Social Security numbers with these cards is not consistent with a free society.
— Summary: The Chairman's Mark for a Bill Establishing a Department of Homeland Security, July 18, 2002
Mr. Ellison has an absolute trust in his database management system's ability to properly manage data. But, Larry, I've got news for you: the DBMS is only as good as the data. I've been on enough database and directory integration projects to know that there is no authoritative data source. You want to take data from organizations that have trouble distinguishing between persons from two different generations who have the same name, but different birth dates and different Social Security numbers? And you want to merge this data into an authoritative source?
NeuStar's plans, if you could call them that, have struck me as having a fatal flaw from the beginning: the namespace is too small. There will be inevitable collisions at the top-level because registrations are allowed there, instead of being relegated to .com.us, or, more appropriately, considering the sites I've seen today, at .cum.us. Take, for example, me. I'd like to have a short, memorable domain name using my last name. Cox Communications would probably like the exact same one.
It entered the WHOIS database just as I finished handing over my plastic. What a farce.