> Is this applicable?  I'm using cable, not dial-up.

a lot of the same principles may apply; since you don't have a fixed IP. You
just don't have the long wait for the modem to dial. :)

don't worry about not understanding how mail works with mutt, sendmail,
postfix, exim, qmail, procmail, fetchmail, etc. took me a while to figure it
out too; since there really wasn't a good, newbie explanation out there at
the time.

so I'm going to shoot off at the mouth and waste some bandwith here by
restating my understanding of how it works:

in the classic university/corporate scenario; where these tools were first
developed:
1. mail comes to your university/corp multi-user computer, which is where
everyone was doing their work already.
2. it is recieved by your Mail Transport Agent (MTA). often this was
Sendmail. 
3. the MTA hands it off to a Mail Delivery Agent (MDA); like procmail. (what
people used before procmail, I don't know... how far back does procmail go?
I missed the presentation.)
4. the MDA puts it in the user's mailbox.
5. the user's shell checks the mailbox on a regular basis, set by the
$MAILCHECK variable; and when there's mail, it notifies the user. (if the
user has it set up that way).
6. the user opens a Mail User Agent (MUA) such as Pine; or for us more
austere folks; whatever the equivalent of /bin/mail was. (since it was about
3x faster than Pine; which becomes noticeable when 150 users are competing
for the resources of a VAX 4000).
7. user writes mail in their preferred text editor
8. user sends mail from the MUA.
9. MUA hands mail off to the MTA (again, often sendmail); which sends it out
to the rest of the Internet.

here's how it usually works under Windows; or with Mozilla Mail (since it's
a the same concept running under Linux):
1. mail comes to your ISP
2. the MTA at your ISP (sendmail, exchange, exim, qmail, postfix) recieves
the mail
3. the MDA at your ISP (procmail, or exchange) delivers the mail to your
mailbox.
4. you dial your ISP with a modem (or have a constant connection via DSL or
cable).
5. your mail client (Agent, Eudora, Pegasus Mail, Netscape Mail, Outlook)
contacts the ISP via POP3, and downloads the mail (the MTA part of your
computer's transaction).
6. since there's only one mailbox (usually) the MDA part is pretty simple.
7. your mail client shows you the mail. (the MUA part of the scheme).
8. you write your mail with whatever crappy text editor they built into your
mailer. 
9. you send your mail, using the MTA part of your mail program again.

the difference with linux/mutt is that all the parts are still separated
into components for MTA/MDA/MUA; and not often well-integrated.
so what you have to do is set up your computer like a small multiuser
system. 
1. your linux system dials your ISP via modem, DSL, cable, wireless
2. fetchmail goes and gets your mail from the ISP via POP3. (in ancient
times I belive the equivalent was sendmail using UUCP; but for some reason
no one ever taught sendmail to speak POP2/POP3... this may be for the
better).
3. fetchmail hands it off to procmail for delivery (it can also deliver to
your MTA; but the downside of this is that you need an MTA listening for
requests, instead of just sending; so that has some security implications.
also, I never got it to work. ;> ).
4. procmail puts it in your mailbox (after filtering it, if you like).
5. you read your mail with your preferred MUA (mutt, pine, or any of the GUI
clients that can read mbox format).
6. you write your mail with your preferred editor.
7. your MUA sends mail by handing it off to an MTA. in mutt, this is done
with lines like:
my_hdr From: user at yourdomain.com
set sendmail="usr/lib/sendmail -oi -oem -f user at yourdomain.com"
in your .muttrc
8. your MTA sends the mail out to the internet, possibly after rewriting
your address so it seems to come from your ISP's mail server (in sendmail,
this is done with the 'DMyourdomain.com' line in sendmail.cf and the '-f
user at yourdomain.com' option mutt passes to sendmail. mind you, some
recipients' MUAs will complain about the -f option [forcing the name to be
something other than what it otherwise would be]).

the tricky bit comes when you don't have a constant IP address. sendmail
will balk if it can't reverse-name-lookup it's own IP address (an ISP worth
their salt should have reverse name lookups for each of their IPs, even for
dialup ones). also, you need to tell your tools when they can send/check for
mail, and when they can't.

what I ended up doing, was writing some scripts to control this behavior.
when I ran the script; it would dial, check to see that I got a good modem
speed, redial if it was only 14.400, flush the mail queue (sendmail -q),
and start fetchmail in daemon mode (so it would keep checking for mail every few
minutes). I'll attach one to this mail (yes, it's not great; if you have
suggestions, speak up).

when I closed the connection, I killed fetchmail, and shut down the ppp
interface. if I sent mail at this point, it would just be spooled up in the
sendmail outbound queue (/var/spool/mqueue), until the next time I dialed up
and flushed it out to the Internet.
I have to admit; it sucked. ;> lots more hassle to configure and use than
the idiot-interfaces Windows mail clients had. but there weren't any good
GUI MUAs at the time (RH 6.0 days).
fortunately for myself; I got a job at Real-Time not long after, and now I
get to SSH to the mail server and read it directly there, as god clearly
intended. :) (tho I have to admit it's slow typing when downloading MP3s at
the same time, even over 128K ISDN). I'm told that mutt+IMAP works better;
but I haven't taken the time to learn it yet.

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700
-------------- next part --------------
A non-text attachment was scrubbed...
Name: online.sh
Type: application/x-sh
Size: 582 bytes
Desc: not available
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20011008/2c1a22ac/online.sh