Ty Anderson: Export Contacts to your iPod…the free and manual way

Stopping Spam

By Larry J. Seltzer

If you look carefully at messages containing spam and e-mail worms, you see some things that aren’t right. In almost every case, the addressing information that accompanies any such e-mail message is fraudulent. (For more information see “Heading Off Spam”.) This is an important characteristic of these messages—and a big part of what allows them to spread so far and be so resistant to defensive measures. A solution is on the way, but it won’t come easily.

The solution is SMTP authentication. The idea is that when one mail server receives a message from another, there should be some mechanism for confirming the sender’s identity. That wouldn’t put an absolute end to spam and e-mail worms, but it would put considerable hurdles in their path. It would make effective blacklisting practical, and it would stop the existing, endemic population of worms from spreading.

Heading Off Spam

Why hasn’t this happened already? There are a number of proposals in various stages of development, but progress in so fundamental an area takes time. More important, perhaps, is that implementing SMTP authentication would almost certainly require every e-mail server on the Internet to be upgraded and thus would cause considerable disruption and expense—even if the implementation is free of intellectual-property entanglements and direct cost.

Many mail servers out there haven’t been upgraded in years. It may be impossible to change some, such as those in appliances, and those will need to be replaced. SMTP authentication requires nothing of the end user, though, which is one of the factors that make it so appealing.

Most SMTP authentication schemes take a somewhat similar approach: The DNS administrator of the domain where the mail server is located must publish information that allows external users to confirm the identity of the domain’s mail servers. There are a number of ways to do this. With most of them, the recipient server can confirm that a message purporting to come from user@domain.com in fact does come from domain.com. Whether the message actually came from the specified user is a matter for the domain.com administrators to enforce.

This last point is important: For SMTP authentication to work properly, SMTP software and administrators will have to tighten procedures. For instance, open relays—which are mail servers that allow anyone to connect and send mail through them—will have to be eliminated, so users will be forced to log on to the server if they want to send mail.

Other security improvements are also necessary. Trivial passwords, like password or the same value as the username, need to be banned, or worms will guess at the values. For the same reason, servers will need to disable accounts if a specified consecutive number of wrong guesses at log-on are attempted. Practices such as these are common in other network log-on scenarios.

Beyond security, we can expect other problems with SMTP authentication. Many of the proposed schemes break mail forwarding, which allows one address to forward mail to another. Instead, servers will have to remail each message.

By the same token, many roaming users will have problems, for instance with sending mail “from” their corporate accounts using separate ISP accounts. Such users will probably need to use VPNs.

SMTP authentication will also mess with those E-mail This Page links on many Web pages. Usually such features will send an e-mail from your address to someone else’s address. With authentication, the message will have to come from a domain controlled by the Web site.

The most mature authentication scheme is SPF (Sender Policy Framework, http://spf.pobox.com), which was published as an Internet Draft on February 11.

Put very simply, with SPF the site advertises data in its DNS server, and other mail servers can use the data to confirm that a message sent from that server actually comes from the domain it claims to come from. Quite a few systems have begun implementing this scheme. As of February 10, 6,708 domains had put SPF records in their DNSs, including aol.com, gnu.org, google.com, symantec.com, ticketmaster.com, and w3.org. Deersoft will use SPF in Version 2.70 of SpamAssassin, and Sophos plans to support SPF in upcoming releases of its antispam product PureMessage.

Since SPF works by checking the addresses of mail servers, it is subject to the problems noted above, such as breaking message forwarding and inconveniencing traveling users. There are workarounds for these problems, and even if they require changes in the mail server, that’s not a big deal, since the mail server will have to change in order to support SPF anyway. Free tools are available to help you to implement SPF on your own site, including a wizard that builds the DNS entries.

Yahoo!’s Domain Keys proposal, announced several months ago but not revealed in detail, takes the idea of authentication to the next level. Instead of working with IP addresses, Domain Keys works with public-key encryption. The sending mail server signs each message using its private key and includes the signature in a special message header. Recipient mail servers can retrieve the sender’s public key from the DNS to confirm the signature. In fact, with Domain Keys a domain can have many public/private key combinations for various purposes, such as supporting subdomains or even different keys for different users.

DNS Security Extensions (DNSSEC) also works with public-key encryption and, much like Domain Keys, allows mail servers to sign some portion of each message with a private key and allow outsiders to authenticate the signature with the public key. If the signatures match, the message’s origin is authenticated; if not, the message is suspicious. But DNSSEC itself may not be secure and may introduce other problems. It’s a controversial spec that has been in the works for over ten years, held up both by the problems it would create and by inertia.

Several other proposals are out there in various stages of development and neglect. Two of them, Remote Mail Exchange (RMX) and Designated Mailer Protocol (DMP), were scavenged to create SPF. The RMX spec creates a new RMX record type for the DNS, which in turn requires upgrades to DNS. RMX is more ambitious than SPF, in that it aims to authorize not just domains but e-mail addresses. DMP is still alive too, and claims it doesn’t break mail forwarding. Neither has a practical implementation yet.

Authenticated Mail Transfer Protocol (AMTP) is different from the others. It actually replaces SMTP by creating a secure connection between mail servers, using Transport Layer Security (TLS) and X.509 certificates. The specification is still in development.

Faced with SMTP authentication, what could a worm author do? The worm would have to send mail from the same domain as the mail server to which it connects. Then it would have to trick the user’s mail client into sending the message or sniff the log-on credentials from the network. Neither option is easy, and in both cases the worm would be sent from the actual user’s address.

We feel SMTP authentication has a reasonable chance of success only if the major mail providers—principally AOL, Microsoft, and Yahoo!—agree on one proposal and give a date beyond which they will either reject or tag unauthenticated mail. SPF is the clear candidate for that proposal. They need to move quickly before spam overwhelms us.

Packeteer – Bandwidth Management, Application Traffic Management, Network Monitoring, Network Compression

Understanding Client-Side Scripting

By Sheryl Canter

You can create an attractive, colorful Web page just using HTML. But without some scripting, the page will just sit there, unresponsive to user actions. Scripts can run either on the Web server (server-side scripting) or on the user’s computer (client-side scripting).

Server-side scripts are best suited for delivering custom or dynamic content. But what if you want a Windows-like menu bar on your Web site, or an expandable tree? You could implement these interface elements in a server-side script, but there are serious disadvantages to doing it this way: Your interface will be sluggish and you will greatly increase the bandwidth used.

A better solution is client-side scripting, which is designed to manipulate and display the content returned from the server. This method enables you to respond to user events by hiding or showing elements on the page, moving elements, or changing colors and fonts. Showing and hiding tables is the essence of how you create a pull-down menu on a Web page. Displaying a window in response to the mouse position allows a Web page to support ToolTips.

The most widely used client-side scripting language is JavaScript, which was invented by Netscape Communications and introduced with Netscape Navigator 2.0. Microsoft’s JScript was released in response to JavaScript’s success, and is essentially a clone. However, the two are not completely compatible.

JavaScript is more widely used than it is understood. Thanks to the many cut-and-paste JavaScript Web sites, Web designers can incorporate JavaScript functions without any concept of how they work. But if you want to go beyond cut-and-paste to create your own cool effects, you need to understand JavaScript.

JavaScript is an object-oriented scripting language that runs inside a Web browser. It manipulates elements on a Web page by means of a Document Object Model, or DOM, which is an API for interacting with a Web page. The elements in HTML documents are hierarchical, and are represented in the DOM as a tree structure. Each element in the tree is an object with properties and methods that are defined by the DOM. For example, a Web page is represented by a document object. Its properties and methods include the title property (document.title), which gives the title for the page, and the write method (document.write), which lets you output text. Objects can be addressed in terms of their position within the tree, or accessed directly by tag, name, or ID. The DOM also provides an interface for user events such as mouse movement or key clicks.

The DOM is separate from the language itself; different languages can implement the same DOM. Unfortunately, different versions of JavaScript can and do implement different DOMs, which hugely complicates the job of Web developers. The differences between the Netscape and Microsoft DOMs are particularly bothersome. JavaScript code of any degree of complexity must include two versions of each function. Developers end up writing an API where each function they want to call is replaced with a version that tests the browser and calls the browser-specific version.

To stem the chaos, the W3C stepped in with a DOM standard for HTML and XML. DOM Level 1, which was completed in October 1998, focuses on basic navigation and manipulation functions. Level 2, completed in November 2000, adds support for XML namespaces, Cascading Style Sheets (CSS), and user interface events. Level 3, which is still under development, will offer enhanced XML support and other advanced features.

But defining a standard is not the same as getting vendors to use it. So far Mozilla, the open-source version of Netscape Navigator (www.mozilla.org) has the most compliant DOM support, implementing most of Level 2. Microsoft did not support the W3C standard until Internet Explorer 6, which supports Level 1. Adding to developer stress is the fact that Microsoft’s current proprietary implementation has some nice features that the W3C version lacks, such as the innerHTML property, which represents all the character data between an element’s starting and ending tag.

The best tools for JavaScript development are built into Mozilla. The Mozilla DOM Inspector displays the DOM tree and flashes the selected element in the rendered Web page, which it displays in the lower window. Mozilla also has a JavaScript console and a debugger.

The learning curve is steeper for JavaScript than it is for server-based scripting, because of the complexity of the DOM and the need to learn multiple DOMs in order to support the most popular browsers. But the payoff is a unique and distinctive Web site that your visitors will enjoy exploring.

Buddy Icons, Expressions, Away Messages , Games And More

Little pc provides small pc, small computer, mini pc, micro pc systems for limited space applications.

BeingFamous.com | Funny Away Messages for AIM and Away Message Videos.

iPodlounge | All Things iPod

Aim Ad Hack 3.56 Get rid of the annoying aim ad’s.

Remove “Orphan” Internet Explorer Toolbars

By Neil J. Rubenking

I downloaded and installed the program Download Accelerator Plus. I used it for a few weeks, then I uninstalled DAP and its toolbar. I thought I had completely uninstalled them, but the toolbar name still shows up when I click on View | Toolbars. Is there any way that I can delete the name so it won’t show up next time?

Edward Chen

It’s unfortunate that DAP’s uninstall routine didn’t completely clean things up, as manually removing the remnants will be a bit tedious. Launch REGEDIT from the Start menu’s Run dialog and navigate to the key HKEY_CURRENT_USER\Software\ Microsoft\Internet Explorer \Toolbar\WebBrowser. You should find at least one value in the right-hand pane with a name that’s a GUID—a bunch of letters and digits between curly brackets, like {2318C2B1-4965-11D4-9B18-009027A5CD4F}. One such value represents the absent toolbar, but to find out which one, we’ll have to look elsewhere.

Work through the list of GUID-named values from the bottom, as the top ones usually represent IE’s own toolbars. Navigate to the subkey of HKEY_CLASSES_ROOT\CLSID whose name is the same as the name of the value; for example, HKEY_CLASSES_ROOT\CLSID\{2318C2B1-4965-11D4-9B18-009027A5CD4F}. Check the (Default) value in the right-hand pane to see which toolbar it represents. The example shown here is the Google toolbar.

When you’ve identified which one corresponds to the absent DAP toolbar, right-click on it, choose Rename, and prefix the name with a period. That’s safer than deleting the key; if you make a mistake, you can restore its name. Back in the HKEY_CURRENT_USER\ …\WebBrowser key, rename the corresponding value in the same way. After you’ve verified that the unwanted entry in the toolbar list is gone, you can go back and delete the key and value that you renamed.

Note that in Windows XP Service Pack 2, due sometime in the first half of 2004, Internet Options will include a dialog for managing add-ons such as toolbars and Browser Helper Objects. We anticipate that it will make solving problems like this one much easier.

AVG Anti-Virus Free antivirus software.