A basic tool for making TCP/IP connections is telnet. If you type
telnet host port
your computer makes a connection to a computer named host on port port. 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'.
port 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 heaven, you call its SMTP service by typing
telnet heaven 25
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
telnet heaven smtp
because telnet finds out what the port number of SMTP is by looking it up in /etc/services. The result will be something like:
Connected to heaven.home.
Escape character is '^]'.
220 heaven.home ESMTP Exim 3.03 #1 Sun, 8 Aug 1999 12:47:24 +0200
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.
After the line beginning with 220 you see no prompt or anything; the MTA awaits your instructions. What to do next? Try typing help. The reaction is:
214- HELO EHLO MAIL RCPT DATA
214 NOOP QUIT RSET HELP
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 RFC821. Some 'extended' commands were added later, in other RFC's, for instance RFC1869. 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.
To break the SMTP connection, send the QUIT command.
If you have a home system without an official domain name, what name do you use? In fact anything is OK, including your own, self-chosen domain name, such as heaven.home. Let's try it with our ISP's SMTP server by typing telnet smtp.isp.com 25 or whatever. After the welcome message type
We get a more or less elaborate 'greeting' message, like:
250-smtp.isp.com Hello customer123.dialin.isp.com [xxx.yyy.zzz.123],
pleased to meet you
The greeting begins with '250'; this is the SMTP 'OK' code. In this case we are also greeted with our temporary domain name (customer123.dialin.isp.com) and temporary IP address (xxx.yyy.zzz.123) 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 extra SMTP or ESMTP commands it understands, apart from the minimum set required by RFC821.
Mail servers generally don't look at the argument 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 telnet host smtp connection.
MAIL FROM: joe@home
250 <joe@home> is syntactically correct
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.
RCPT TO: emi@home
250 <emi@home> is syntactically correct
So this is also 250, OK. The third step: we enter the message itself, using the DATA command:
354 Enter message, ending with "." on a line by itself
The '354' reply invites us to type the message data. This is not only the text (or 'body') of the message! 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, RFC822. Strictly speaking that is no longer SMTP's business. SMTP is only concerned with the envelope of the message, that is, the information in the MAIL FROM: and RCPT TO: commands. So, the To: header inside the message and the RCPT TO: address on the envelope of the message are in principle two different things. You can actually make them different (experiment only with local messages please!). So, for instance, after the '354' reply we can type a message with 'fake headers':
To: My Daughter
From: Your Dad
<--(a blank line separates the headers from the body of the message)
. <--(a period at the beginning of a line ends the message)
This will be promptly delivered to user emi. If she opens the message using pine, she will see the To: My Daughter and From: Your Dad addresses.
Problems arise when she tries to reply 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.
The MTA may not be active at all
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 not 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 (most of them, apart from mail, can do this), and your MTA will not be used at all. 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 local address; exim's transport filter will change it for outgoing mail.
The 'envelope from' is not changed
This was the really big problem. As I said, the exchange of e-mail with an SMTP host involves three steps:
This means that we definitely should fix not only the From: address inside the message (using the program outfilt described in my previous article) but also the MAIL FROM: (or 'envelope from'). There are two ways in which you can do this.
If you have exim 2.05 or earlier the only way is to add a line in the last section, REWRITE CONFIGURATION, of exim.conf:
*@home firstname.lastname@example.org F
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.
If you have exim 2.10 or later you can instead add an option to the remote_smtp subsection of the TRANSPORTS CONFIGURATION section of exim.conf. These newer exims allow the 'envelope from' to be changed for outgoing mail only. After the line driver = smtp you insert a line
return_path = "email@example.com"
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 www.debian.org among the 'unstable' packages (it is quite stable, don't worry). Upgrading is pretty painless.
Both methods described above produce a fixed 'envelope from' address, just as the program outfilt in my previous article produced a fixed '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 different 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.