LINUX NEWS
http://www.Cramsession.com
October 3, 2002 - Issue #101TABLE OF CONTENTS
1) Sean’s Notes
2) Linux News
Red Hat 8.0 Released
Red Hat 8.0 - SNAFU #1
Behind the Name
Mandrake Releases 9.03) Linux Resources
Multiheaded X-Windows
Where Do You Set Kernel Parameters?
Solaris Security Primer
How do Hashes Work?
MD5SUM?4) App o’ the Week
~~~~~~~~~~~~~~~~~~~~~~ ADVERTISEMENT ~~~~~~~~~~~~~~~~~~~~~~~
Gain study time and enhance your learning! Hear hundreds of certification exam questions on audio CD or cassette. Learn while you commute to and from work, exercise or walk the dog. Ideal for those times when you can’t read. 90-day money back guarantee if you are not happy.
http://ad.brainbuzz.com/?RC06&AIV75
For information on how to advertise in this newsletter
please contact mailto:adsales@CramSession.com or visit
http://cramsession.com/marketing/default.asp
-------------------------
1) Sean's Notes
-------------------------
As you've probably noticed, Red Hat 8.0 came out this week. I
was planning to give you my first impressions of it this week,
but busy mirrors, broken parts in my test environment, and
general craziness prevented that. But I've got a great series
lined up on one of the oldest applications of the Internet,
email, which will hopefully tide you over until I get my act
together.
Linux makes a great email server, whether you're just doing
personal email with your custom domain, or if you're hosting for
thousands of users. Email software in Linux scales beautifully,
you could handle a light volume on a Pentium-90, or move to a
large cluster of machines handling thousands of mailboxes, with
only a few changes in configuration.
This week, we'll look at the flow of email on the Internet. In
upcoming articles, I'll cover setting up the Postfix mail
transfer agent, and how to provide POP and IMAP access to the
mailboxes.
How email gets delivered is very elegant. The first part to look
at is the communication between Mail Transfer Agents (MTAs), who
are responsible for receiving and sending email. When you put an
SMTP server in your mail client (called a Mail User Agent (MUA)),
you're specifying the MTA that will forward your email toward
its destination. SMTP, the Simple Mail Transfer Protocol,
dictates how the MTAs will speak (and how you'll speak to the
MTA). RFC 821 lays out the protocol:
http://www.isi.edu/in-notes/rfc821.txt
A quick summary of the protocol:
Sending MTA contacts receiving MTA on port 25. Receiving MTA
answers with a banner identifying itself. Each response from the
receiver has a number at the beginning of each line, called the
status code. The MTAs aren't too concerned about anything other
than the status code, it's there for humans to read if something
goes wrong.
220 poochie ESMTP Sendmail 8.11.6/8.11.2; Tue, 1 Oct 2002 20:53:09 -0500
That's the banner from one of my mail servers. The sender then
identifies himself with HELO:
HELO me
250 poochie Hello, me, pleased to meet you
The sender's address is then entered:
MAIL FROM: swalberg@cramsession.com
and the response:
250 2.1.0 swalberg@cramsession.com... Sender ok
Then, the list of recipients (if there are multiple, it's one
per line, with the RCPT TO: command repeated)
RCPT TO: swalberg@cramsession.com
250 2.1.5 swalberg@cramsession.com... Recipient ok
Then, finally, the actual message itself:
DATA
354 Enter mail, end with "." on a line by itself
From: "Sean Walberg" <swalberg@cramsession.com>
To: "Sean Walberg" <swalberg@cramsession.com>
Subject: testing
Hi, Sean!
.
When I send the last line, the "." by itself, I get back:
250 2.0.0 g921vb929510 Message accepted for delivery
So, I finish the conversation:
QUIT
221 2.0.0 poochie closing connection
Why am I showing you the protocol itself? As an email
administrator, your best troubleshooting tool is to make
yourself look like another MTA and to telnet in and send a test
message. Only then can you see where the conversation is going.
Plus, by seeing how simple SMTP really is (as opposed to SNMP,
the Simple Network Management Protocol, which isn't simple at
all), I'm hoping it dispels some of the fears you might have
about understanding email.
Why did you specify the to/from addresses both in the RCPT/MAIL
commands, and after DATA? Good question! Think of email like its
physical counterpart. You've got an envelope with a letter
inside. The envelope says who the message is to, and who it is
from. Likewise, the RCPT and MAIL commands form the envelope of
the message. Unless your MTA injects that information in the
email's headers, you'll never see it again. The message itself
(content) comes after the DATA keyword. Within that, we've got
the headers, and the text itself. Headers are for your MUA to
chew on, such as a more friendly version of the From and To
addresses, along with a subject and other fun. The first blank
line marks the end of the headers, and the beginning of the
text that the user reads.
Is this vulnerable to forgery? You bet. I could have entered
anything I wanted in the headers (or nothing at all), and the
only reliable way to trace would be to go to the MTA logs. But
SMTP dates back over 20 years, to a time where the Internet was
more friendly.
How does the sending MTA know where to find the receiving MTA?
Excellent question! SMTP doesn't cover this, so we make use of
the domain name system, DNS.
Recall that DNS is composed of various records, each specifying
information for a name within a zone. The A record for "www"
within the "cramsession.com" zone will tell me the IP address of
Cramsession's web servers. The MX record (Mail Exchange) tells
me where to deliver the mail. By stripping off everything before
the @ in the email address, your MTA knows the domain.
$ host -t mx cramsession.com
cramsession.com mail is handled by 10 mail.cramsession.com.
Using the host command, with the -t (type) mx option tells me
where to send the mail. The number before the name dictates a
priority (called the preference), with lower numbers winning.
The MTA's job is to pick the lowest one, and connect to it. If
there is a tie, pick one at random. If you can't connect, pick
the next highest MX. As we'll see later, a higher priority MX
will accept the email, but continue to try to deliver it to the
lower priority MX on its own. Nothing's set in stone about your
choice of priorities, but popular convention is to set your
preferred MX to 10, and to increase by 10 from there. If you
need, for some reason, to set up a higher priority MX somewhere,
you've got lots of room to play.
If there are no MX records, an A record will be tried. Since
your web site and mail server may not be on the same server,
it's good practice to have an MX record.
$ host cramsession.com
cramsession.com has address 63.146.189.41
Recapping, you send your message from your MUA (email client) to
your chosen MTA (email server) using the SMTP protocol, where it
is queued for delivery. The MTA then looks at the email address,
and figures out the domain name(s) of the recipient(s). MX
records are pulled for the domain(s), and the MTA contacts to
the remote MTA, speaks SMTP to deliver the message, where it is
queued again.
There are a few possible cases at the remote MTA. It could be
configured to statically send all email to another server, which
it will then do (think of the case of a mail gateway, or virus
scanner). The remote MTA might not be the lowest preference MTA
for the domain, in which case it will start trying to contact
the better MTA. Finally, the MTA could be the one responsible
for delivering the email to the destination.
This last step is fairly boring compared to what's happened so
far. When an MTA receives an email, it says "What do I do with
this?" After consulting various tables, or even DNS, it might
say "Hey, that's for one of my users!", in which case it dumps
it to a local database. This phase is called "local delivery".
Depending on your mail server, local delivery can take on
various forms. Traditional UNIX delivery agents dump the message
to /var/spool/mail/USERNAME (or sometimes /var/mail/USERNAME).
The format (called mbox format) is pretty simple, it's just the
messages smashed together with a brief header. Some mail servers
like Cyrus (or MS Exchange) store the message in a database for
faster access. Some, like qmail, store it in the user's home
directory. They're all good.
The last phase is for the recipient to get the email. This can
happen with POP, IMAP, read from the mbox directly, or
specialized applications. It's actually the easiest and least
complex part of the whole process.
Well, that's the flow of email, from sender to receiver. A
successful email administrator understands it completely, so
that any breaks in the chain can be found and fixed. In upcoming
articles, I'll cover setting up the MTA, and how to get your POP
and IMAP set up. If there is any demand, I'll walk through the
setup of a web-based mail reader too.
Long live the Penguin,
Sean
mailto:swalberg@cramsession.com
-------------------------
2) Linux News
-------------------------
---------------------
Red Hat 8.0 Released
---------------------
It's that time again. Red Hat has a new point-oh release ready
for purchase or download. Big features this time around are the
"Bluecurve" theme, which makes GNOME and KDE look similar out of
the box, and the inclusion of Open Office.
http://redhat.com/about/presscenter/2002/press_eightoh.html
-----------------------
Red Hat 8.0 - SNAFU #1
-----------------------
Over concerns about patents and royalties, XMMS in Red Hat 8 was
stripped of MP3 capabilities. When you tried to play an MP3, you
should have received a popup saying this, and where you could
get an RPM to fix it. Guess who forgot to include that? Here's a
link to the MP3 decoder.
http://soraas.student.nlh.no/~havardk/xmms/xmms-1.2.7-rh8-rpm/
----------------
Behind the Name
----------------
I've noticed some relationships between various names that Red
Hat has used for distributions, such as Valhalla->Limbo->Null,
and the choice of painters for a few releases. Someone has come
up with all the names ever used, and put together some plausible
(and not-so-plausible) linkages. Fun reading!
http://www.smoogespace.com/documents/behind_the_names.html
----------------------
Mandrake Releases 9.0
----------------------
The more desktop oriented distribution, Mandrake, has also
reached a major milestone with the release of Mandrake Linux 9.0.
The ProSuite edition is Linux Standards Base certified, which I
call a sign of a good trend.
http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2393
-------------------------
3) Linux Resources
-------------------------
----------------------
Multiheaded X-Windows
----------------------
"Multiheaded" is a term applied to a machine with more than one
monitor. Most often, the monitors are bonded together so that
you have one virtual desktop that spans both (or more than two).
Here's an article on how to do it... I've been wanting to for
some time, but one limitation is that both displays must be at
the same colour depth.
http://www.linuxgazette.com/issue82/ward.html
------------------------------------
Where Do You Set Kernel Parameters?
------------------------------------
It used to be that setting kernel parameters like ip_forward (for
firewalls and routers) was done within /etc/sysconfig/network on
Red Hat systems. It's still just as easy, but more comprehensive.
Check this link out for how you go about setting just about any
kernel parameter you need. This'll also work on any distribution,
and it goes for any kernel parameter.
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s
1-proc-sysctl.html
------------------------
Solaris Security Primer
------------------------
Here's a good primer on securing Solaris. Some examples include
the equivalent Linux command or file, where appropriate. Good
techniques and ideas here...
http://www.sunperf.com/Security.html
--------------------
How do Hashes Work?
--------------------
Maybe it's some of my computer science courses making a
comeback, but I found this article on Perl hashes quite
interesting. It explains how hashes are represented in Perl,
and how to make your use of them more efficient.
http://www.perl.com/pub/a/2002/10/01/hashes.html
--------
MD5SUM?
--------
When you download files from an FTP site, often a file called
MD5SUM is there. This file contains the MD5 hashes of the files
in the directory. By comparing their hashes to the ones you
downloaded, you can ensure the download was successful.
http://boards.cramsession.com/boards/vbm.asp?md4554
-------------------------
4) App o' the Week
-------------------------
Got a bunch of MP3s that you want to put on a CD, but they're
all at different volume levels? You want to normalize it, with
the aptly named "normalize" tool.
http://www.cs.columbia.edu/~cvaill/normalize/
-------------------------
(C) 2002 BrainBuzz.com, Inc. All Rights Reserved.
-------------------------
-------------------------
This message is from CramSession
You are currently subscribed to the following list
Hottest Linux News and Resources
as: sean@ertw.com
To un-subscribe from this newsletter by e-mail,
send a blank email message to:
mailto:leave-linuxnews-3825955Y@list.cramsession.com
To subscribe to this newsletter and many others visit
our site at:
http://newsletters.cramsession.com/signup/default.asp
-------------------------------------------------------