Request for assistance

[John Chambers]

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.)