>On 27 Jan 1999 [EMAIL PROTECTED] wrote:
>
>> If you don't understand a term or phrase you read, trust me, you
>> *have* to go find its definition before you proceed.
>
>Where can I find definitions for this stuff? Are there any
>mailing lists, FAQs, RFCs I should look at? And by the way,
>what is an MX? <g>
Well, I forgot to mention some resources I found very helpful.
Along with the man pages qmail provides -- some of which are not
prefaced with "qmail-", so make sure you follow up *all* the ones
listed at the "SEE ALSO" sections!! -- make sure you check out
/usr/doc/qmail-1.03/* -- read all the stuff here, over and
over again. Especially the INTERNALS file!! :)
During roughly the same timeframe that I've been getting qmail,
serialmail, and fetchmail up and running, I've also been reading
the O'Reilly and Associates books "TCP/IP Network Administration"
"DNS and BIND", and "Stopping Spam". (I haven't really made enough
sense of the DNS stuff to change my own configuration -- /etc/hosts
and friends seem adequate for me, given that I've already got the
default cache-only configuration RedHat provides, AFAICT.)
Now, the ORA books are generally considered among the best in their
class, and I'd tend (offhand) to agree. (Disclaimer: I did a bit
of contract work for ORA around 1985, not UNIX-related though.)
But, I've found more bugs and confusing things in those books
than I've found in the qmail, serialmail, and fetchmail *software*
put together.
IMO, if the *documentation* for those products was brought up anywhere
near the quality of the software, those products would be unbeatable,
and the docs actually would exceed ORA's in quality.
I mean, rarely, if ever, is documentation for freely available software
as good as it is for qmail et al anyway, but it definitely seems like
the weak point compared to the software (okay, maybe I'm in my
"honeymoon" period wrt to the software, but it sure *seems* great).
Not having the docs be as good as the software does have its
advantages. E.g., it's easier to filter out non-technical types
by making it less likely they'll think they understand what's
going on (especially advantageous, as I found out in my own
project, for "young" software); it can give an outfit like ORA
more incentive to write a great book on the software, giving it
more legitimacy; and it might make it easier for experts to find
consulting work setting up and maintaining the software.
So, you definitely have to be very pro-active reading up on how
to set up qmail, serialmail, fetchmail, and so on. Russ Nelson
has posted an overview document on email itself (which I've
squirreled away, but haven't yet read), look for "A bit about
email" as one of the first headers in the document (this is
different from an email header :).
(Hmm, if you want to give this a try, for Russ's document, look
for Message-Id: <[EMAIL PROTECTED]>, and
it might be in the qmail database as message 26404, if I'm reading
the email headerage right.)
For me, the biggest hurdle was really just understand the Internet's
take on email -- terminology and so on. I've used email systems
of various sorts for over two decades now, and been a "surface user"
of the Internet, but haven't explored the ins and outs of email
configuration/administration since well before I got involved with
the Internet, so I had a lot to learn, and the qmail docs tend to
assume you've already got that knowledge. That's why Russ's document
might help.
tq vm, (burley)
