old-www/LDP/LG/issue45/stumpel.html

279 lines
14 KiB
HTML

<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<title>Experiments with SMTP LG #45</title>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
ALINK="#FF0000">
<!--endcut ============================================================-->
<H4>
"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <HR> <P>
<!--===================================================================-->
<center>
<font color="maroon">
<H1>Experiments with SMTP</H1>
<h4>(or: Mail for a Home Network, continued..)</h4>
</font>
<H4>By <a href="mailto:JW.Stumpel@inter.NL.net">Jan Stumpel</a></H4>
</center>
<P> <HR> <P>
<h4>
1. Introduction</h4>
I got a lot of reactions to '<a href="../issue43/stumpel.html">Setting
Up Mail for a Home Network Using Exim'</a> in LG 43. Most of them said
two things:
<ul>
<li>
your article was most welcome. I have been struggling with the same problem
myself.</li>
<li>
but I did what you said, and it does not work!</li>
</ul>
So I went 'back to the drawing board' and had a good look at what happens
when e-mail is sent. As a result, this article explains what you must do
to make the setup in the LG 43 article <i>really</i> work (I think) ..
and also why.
<h4>
2. SMTP</h4>
SMTP, as you probably know, stands for 'Simple Mail Transfer Protocol'.
It is the method by means of which mail is exchanged between computers
on the Internet. Basic <i>communication</i> between computers (exchange
of single packets and of streams of information) is provided for by TCP/IP.&nbsp;
SMTP is a protocol 'on top of' TCP/IP for exchanging <i>messages</i> between
computers. Let's do a few experiments to see how SMTP works.
<p>A basic tool for making TCP/IP connections is telnet. If you type
<p><tt>telnet <i>host port</i></tt>
<p>your computer makes a connection to a computer named <i><tt>host</tt></i>
on port <i><tt>port</tt></i>. It is like making a telephone call to the
office of a company called 'host' and asking to speak to Mr. Port. Only
if Mr. Port is in and willing to talk to you, will the call succeed.
Similarly, a program ('daemon') must be active on the other computer, 'listening'
for connections on the specified port, otherwise you will get the message
'connection refused'.
<p><i><tt>port</tt></i> is a (16-bit) number. Certain port numbers have
been pre-assigned to certain services. Electronic mail (SMTP) uses port
25, and the daemon listening to port 25 is the MTA (the Mail Transport
Agent: sendmail, exim, qmail, etc.). If your Linux box is called <tt>heaven</tt>,
you call its SMTP service by typing
<p><tt>telnet heaven 25</tt>
<p>You can do this from another computer through a network (LAN or Internet),
but you don't need a network: you can test it also by running telnet from
the same computer that the MTA runs on. You can even type
<p><tt>telnet heaven smtp</tt>
<p>because telnet finds out what the port number of SMTP is by looking
it up in <tt>/etc/services</tt>. The result will be something like:
<p><tt>Trying 192.168.1.1...</tt>
<br><tt>Connected to heaven.home.</tt>
<br><tt>Escape character is '^]'.</tt>
<br><tt>220 heaven.home ESMTP Exim 3.03 #1 Sun, 8 Aug 1999 12:47:24 +0200</tt>
<p>This shows that I am running exim 3.03 (I recently upgraded from 2.05
for a good reason, see section 5 below). If I telnet in the same way to
the mail server of my ISP, I see that they run Sendmail 8.8.8/1.19.
<p>After the line beginning with 220 you see no prompt or anything; the
MTA awaits your instructions. What to do next? Try typing <tt>help</tt>.
The reaction is:
<p><tt>help</tt>
<br><tt>214-Commands supported:</tt>
<br><tt>214-&nbsp;&nbsp;&nbsp; HELO EHLO MAIL RCPT DATA</tt>
<br><tt>214&nbsp;&nbsp;&nbsp;&nbsp; NOOP QUIT RSET HELP</tt>
<p>These are the commands of the SMTP command language, or 'protocol',
that are supported by your site. Not a lot of commands! SMTP is really
a 'simple' protocol. The commands are described in the Internet standard
<a href="http://sunsite.auc.dk/RFC/rfc/rfc821.html">RFC821</a>.
Some 'extended' commands were added later, in other RFC's, for instance
<a href="http://sunsite.auc.dk/RFC/rfc/rfc1869.html">RFC1869</a>.
Systems which recognize the extended commands are said to support 'Extended
SMTP', or ESMTP. Such systems announce this in their 'welcoming line',
as Exim 3.03 did above. The differences between SMTP and ESMTP are not
great.
<p>To break the SMTP connection, send the QUIT command.
<h4>
3. Exchanging greetings: the HELO/EHLO command</h4>
After the welcoming line (beginning with 220) from the remote system, you
are supposed to send commands. The first command should be HELO, or, if
you are dealing with an ESMTP system, EHLO, the more modern version. The
command should have your domain name as argument:
<p><tt>EHLO <i>yourdomainname</i></tt>
<p>If&nbsp; you have a home system without an official domain name, what
name do you use? In fact anything is OK,&nbsp; including your own, self-chosen
domain name, such as heaven.home. Let's try it with our ISP's SMTP server
by typing <tt>telnet smtp.isp.com 25</tt> or whatever. After the welcome
message type
<p><tt>EHLO heaven.home</tt>
<p>We&nbsp; get a more or less elaborate 'greeting' message, like:
<p><tt>250-smtp.isp.com Hello customer123.dialin.isp.com [xxx.yyy.zzz.123],
pleased to meet you</tt>
<br><tt>250-EXPN</tt>
<br><tt>250-VERB</tt>
<br><tt>250-8BITMIME</tt>
<br><tt>250-SIZE</tt>
<p>The greeting begins with '250'; this is the SMTP 'OK' code. In this
case we are also greeted with our temporary domain name (<tt>customer123.dialin.isp.com</tt>)
and temporary IP address (<tt>xxx.yyy.zzz.123</tt>) that were dynamically
assigned to us when we opened the ppp connection. This information is available
to the other system from the underlying Internet transport layer (TCP/IP).
In the case of an EHLO command, the other system also sends a few '250'
lines announcing which <i>extra</i> SMTP or ESMTP commands it understands,
apart from the minimum set required by RFC821.
<p>Mail servers generally don't look at the <i>argument</i> of the EHLO
or HELO command at all ('heaven.home'). That means that in practice the
EHLO/HELO transaction always succeeds. If the other system doesn't want
to do business with you, it has already refused the <tt>telnet <i>host</i>
smtp</tt> connection.
<h4>
4. Sending the mail</h4>
By just a <tt>telnet <i>host</i> smtp</tt> connection to a mail server
you can send electronic mail 'by hand', without even using an MTA or a
mail user program like pine. Let's try this (for safety's sake) within
our own network at first; in this case of course, we must have a mail server
(MTA) running.&nbsp; User <tt>joe</tt> sends a message to user <tt>emi</tt>.
This involves three steps. First the MAIL FROM<tt>:</tt> command (SMTP
commands are not case sensitive, so you could also type <tt>mail from:</tt>).
<p><tt>MAIL FROM: joe@home</tt>
<br><tt>250 &lt;joe@home> is syntactically correct</tt>
<p>We get a '250' line as answer, so this is OK. Now the second step: the
RCPT TO: command, specifying who will get the message.
<p><tt>RCPT TO: emi@home</tt>
<br><tt>250 &lt;emi@home> is syntactically correct</tt>
<p>So this is also 250, OK. The third step: we enter the message itself,
using the DATA command:
<p><tt>DATA</tt>
<br><tt>354 Enter message, ending with "." on a line by itself</tt>
<p>The '354' reply invites us to type the message data. <i>This is not
only the text (or 'body') of&nbsp; the message!</i> The 'message data'
also include the message headers, such as Subject:, To:, Cc:, and From:.
The structure of a message is specified in another Internet standard,
<a href="http://sunsite.auc.dk/RFC/rfc/rfc822.html">RFC822</a>.
Strictly speaking that is no longer SMTP's business. SMTP is only concerned
with the <b>envelope </b>of the message, that is, the information in the
MAIL FROM: and RCPT TO: commands. So, the To: header <i>inside</i> the
message and the RCPT TO: address <i>on the envelope</i> of the message
are in principle two different things. You can actually <i>make</i> them
different (experiment only with <i>local</i> messages please!). So, for
instance, after the '354' reply we can type a message with 'fake headers':
<p><tt>To: My Daughter</tt>
<br><tt>From: Your Dad</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt>&lt;--(a
blank line separates the headers from the body of the message)
<br><tt>Happy birthday!</tt>
<br><tt>.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </tt>&lt;--(a
period at the beginning of a line ends the message)
<p>This will be promptly delivered to user <tt>emi</tt>. If she opens the
message using pine, she will see the <tt>To: My Daughter</tt> and <tt>From:
Your Dad</tt> addresses.
<p>Problems arise when she tries to <i>reply</i> to the message. Replies
by users do not go to the 'envelope from' address (SMTP's MAIL FROM:),
but to the From: address which is part of the message data. For starters,
pine will think that 'Your' and 'Dad' are two different addresses, and
complain that they should be separated by a comma, not a space! And of
course there are no mail accounts 'Your' or 'Dad' registered on this machine,
or anywhere else. Manipulating or omitting the various addresses is a fertile
field for pranksters and spammers.
<h4>
5. Mail setup for your home network</h4>
Now we get to what was wrong with my article in LG 43. Apart from the 'pine
bug' that I wrote a <a href="../issue44/stumpel.html">note</a>
about in LG 44, the two major problems encountered by readers were:
<p><i>The MTA may not be active at all</i>
<br>I said that the mail client (e.g. pine) on the Linux side can be used
'out of the box'. This is true, but the problem is that with many users
the mail client does <i>not</i> come out of the box, but is already installed
and being used. Often this means that in its configuration there will be
a setting for 'SMTP server', set to the address of the ISP's mail server.
In such a case the mail client itself will do the SMTP transaction&nbsp;
(most of them, apart from <tt>mail</tt>, can do this), and your MTA <i>will
not be used at all</i>. Therefore the transport filter will not be used,
and the From: address inside the message will not be changed. Remedy: set
'SMTP server' in the mail client to the name of your Linux box, so the
mail client will hand over messages to the MTA. If asked for 'your e-mail
address', use your <i>local</i> address; exim's transport filter will change
it for outgoing mail.
<p><i>The 'envelope from' is not changed</i>
<br>This was the really big problem. As I said, the exchange of e-mail
with an SMTP host involves three steps:
<ol>
<li>
MAIL FROM:</li>
<li>
RCPT TO:</li>
<li>
DATA</li>
</ol>
If everything goes well, the remote system will answer 'OK' (i.e., '250')
to the first two steps. But sometimes it won't! Many (probably most) mail
servers, including the one at my own ISP, do not check the MAIL FROM: address.
They always say 'OK' . But some <i>verify</i> that the domain part of the
MAIL FROM: address really exists. If not, the mail is refused. If your
own ISP checks the MAIL FROM:, the mail setup of my previous article will
simply
<i>not work</i> for outgoing mail. If your ISP doesn't check, but
you send mail to a <i>destination</i> which does, your messages will not
arrive and you will get <i>no warning of this.</i>
<p>This means that we definitely should fix not only the From: address
<i>inside</i>
the message (using the program <tt>outfilt</tt> described in my previous
article) but also the MAIL FROM: (or 'envelope from'). There are two ways
in which you can do this.
<p><b>If you have exim 2.05 or earlier</b> the only way is to add a line
in the last section, <tt>REWRITE CONFIGURATION</tt>, of exim.conf:
<p><tt>*@home joe.bloggs@isp.com F</tt>
<p>This changes all local MAIL FROM: addresses to the address at the ISP.
Unfortunately, with this method not only the outgoing mail is changed,
but the local mail also. You can live with this, because users never see
the 'envelope from' when they open a mail message. Replies will go to the
correct (message From:) address. However, if someone makes a mistake typing
a local address, so that mail is addressed to a non-existent local user,
an error message will be sent to the address at the ISP instead of locally.
<p><b>If you have exim 2.10 or later</b> you can instead add an option
to the <tt>remote_smtp</tt> subsection of the <tt>TRANSPORTS CONFIGURATION</tt>
section of exim.conf. These newer exims allow the 'envelope from' to be
changed <i>for outgoing mail only</i>. After the line <tt>driver = smtp</tt>
you insert a line
<p><tt>&nbsp; return_path = "joe.bloggs@isp.com"</tt>
<p>As this is a better method, I advise you to upgrade if you have exim
2.05. In the case of Debian, the latest version of exim (at the time of
writing, version 3.03) can be found at <a href="http://www.debian.org">www.debian.org</a>
among the 'unstable' packages (it is quite stable, don't worry). Upgrading
is pretty painless.
<p>Both methods described above produce a <i>fixed</i> 'envelope from'
address, just as the program <tt>outfilt</tt> in my previous article produced
a <i>fixed</i> 'message From:' address. I am describing a situation with
only one e-mail account. If your home users are known to the outside world
by <i>different</i> e-mail addresses, the setup becomes a little bit more
complicated, but still possible. It would take a little bit too long to
describe the various possibilities here; you might look at 'string expansion'
and possibly 'file lookup' in the exim doc's.
<center>
<p>-o-o-o-o-o-</center>
<!--===================================================================-->
<P> <hr> <P>
<center><H5>Copyright &copy; 1999, Jan Stumpel <BR>
Published in Issue 45 of <i>Linux Gazette</i>, September 1999</H5></center>
<!--===================================================================-->
<!--startcut ==========================================================-->
<P> <hr> <P>
<A HREF="index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="pollman/mail.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="twining.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
</BODY>
</HTML>
<!--endcut ============================================================-->