Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Mark J. Dulcey | Actually, none of the usual email clients normally make delivery directly to the recipient. They're all normally set up to send email to one specific SMTP server. You can, however, set that server to be whatever you want. To send directly to the recipient, you would have to reconfigure your mail client each time you sent a piece of mail, which would be a colossal pain. This isn't consistent with the behavior that I've seen on ANY unix system. The most common MTA, the /bin/mail program, always has a -v option that shows you the transaction. In most cases, what it shows you is an immediate connection to the remote system, followed by the SMTP conversation. When this finishes, the email has been delivered, and no local server was involved. If this fails for some reason (e.g., you're offline), you get a line saying that the message has been queued. This merely means that it is sitting in a directory (usually /var/spool/mail) on your disk. It has not been handed to a server of any sort. To handle queued mail, the sendmail program is invoked occasionally (by crond or your connection software), but this is not a server invocation. It's sendmail running as a MTA ("sendmail -q"). It exits as soon as it finishes the queue. The mail command also typically fires up a "sendmail -q" process if it successfully sends a message, to attempt to send queued messages while the window is open. | And there is a good reason why it's done that way. Client software usually sends mail SYNCHRONOUSLY; that is, the software, or at least the mail client portion of it, is tied up until the mail is sent. (Outlook Express and Eurora are exceptions; they send in the background.) Furthermore, the recipient isn't always available right away; his email server might be down, or there might be a problem in the Internet somewhere between point A and point B. True, but not even vaguely an answer to the question about sending mail. A synchronous mail *send* doesn't require a server on the sending end, only on the receiving end. Bouncing the mail of a local server is simply a waste of cpu time (and bandwidth if it's on a different machine). It slows down the transfer by adding an unneeded hop. (It also lets software on the server machine spy on your mail, but that's a different issue. If an ISP insists on this, then you can assume it's because they're examining your mail.) | That's the reason we have SMTP servers in the first place. It's their job to do things in the background, to keep trying if they don't succeed immediately, and (typically) to log everything they do. Having a server to do that simplifies the job of the mail client; it means that you have to write all that bulletproof code only once, instead of once for each client. No, an SMTP server's primary function is to listen for *incoming* mail. They aren't needed on the sending end. You can use them, yes, but when you do, you're wasting machine resources and time. If the server is on a local machine, you've doubled your local email traffic load. If it's on your ISP, you've doubled your ISP's email traffic load. You've unnecessarily used disk space on a server machine, and exposed your mail to examination by the ISP. | If you have a full-time Internet connection with a static IP address, run your OWN server by all means. (Every Linux distribution these days comes with sendmail, postfix, or some other SMTP server software, and makes it easy to set up, at least in the simple cases.) That keeps the extra traffic off the Internet (your LAN presumably has plenty of capacity for it), and gives you the advantage of full control over your email. But, in a previous message, I pointed out the problems of running your own server if you don't have a full-time connection. That's exactly when an SMTP server at your ISP should be making life easier instead of harder. If you don't have a full-time connection, you do need a server on some fully-connected machine for incoming mail. (The UUCP folks had a solution to this, but the SMTP gang never learned about it. ;-) You still don't need a local server for outgoing mail. And in the usual unix setup, you don't use one. Note that, if you're not connected when you want to send email, a server at your ISP doesn't help you. You're not connected. You can't talk to it. When you do connect, you could send your outgoing mail to the ISP's server, but this is still a waste of time and resources. If you're going to make a TCP connection to your ISP's server, you might as well make the connection to the recipient's server instead. Then the mail gets there in one hop instead of two. Summary: SMTP servers are needed only for recieving mail. They are not needed for sending mail. Doing so waste's time and resources. If your ISP requires using their server, you should be very suspicious, and you should consider encrypting your mail. They wouldn't want to use their hardware for this unless it was profitable. Ask yourself how they could profit from having your email stored on their disks. (A couple years back, users of msn.com learned this lesson when they found that Microsoft was extracting things - mostly images - from their users' email and using them in advertising. Their EULA stated that all messages going through their machines became the property of Microsoft. For some reason, a lot of their customers got quite upset over this.)
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |