A typical entry in logfile looks like this:
04/24/94 07:12:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] delivered
| via: vstout.vbrew.com
| to: [email protected]
| orig-to: [email protected]
| router: smart host
| transport: smtp
This shows that a message from root to
[email protected] has been properly delivered to host
vstout over SMTP.
Messages smail could not deliver generate a similar entry in the log file, but with an error message instead of the delivered part:
04/24/94 07:12:04: [m0puwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [m0puwU8-00023UB] [email protected] ... defer
(ERR 148) transport smtp: connect: Connection refused
The above error is typical for a situation in which smail
properly recognizes that the message should be delivered to
vstout but was not able to connect to the SMTP service on
vstout. If this happens, you either have a configuration problem,
or TCP support is missing from your smail binaries.
This problem is not as uncommon as one might think. There have been pre-compiled smail binaries around, even in some distributions, without support for TCP/IP networking. If this is the case for you, you have to compile smail yourself. Having installed smail, you can check if it has TCP networking support by telnetting to the SMTP port on your machine. A successful connect to the SMTP server is shown below (your input is marked like this):
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 monad.swb.de Smail3.1.28.1 #6 ready at Sun, 23 Jan 94
19:26 MET
QUIT
221 monad.swb.de closing connection
If this test doesn't produce the SMTP banner (the line starting with
the 220 code), first make sure that your configuration is really
correct before you go through compiling smail yourself, which
is described below.
If you encounter a problem with smail that you are unable to locate from the error message smail generates, you may want to turn on debugging messages. You can do this using the -d flag, optionally followed by a number specifying the level of verbosity (you may not have any space between the flag and the numerical argument). smail will then print a report of its operation to the screen, which may give you more hints about what is going wrong.
[Don't know,...Maybe people don't find this funny:]
If nothing else helps, you may want to invoke smail in Rogue mode
by giving the -bR option on the command line. The manpage says
on this option: ``Enter the hostile domain of giant mail messages, and
RFC standard scrolls. Attempt to make it down to protocol level 26 and
back.'' Although this option won't solve your problems, it may provide
you some comfort and consolation.