Contents

• Disclaimer
• Nullmailer + This Doc = Success
• Nullmailer Mental Model
• Troubleshooting Tools for Nullmailer
• Troubleshooting Ladder
• Editorial: It Doesn't Have to Be This Way

Disclaimer

Nullmailer + This Doc = Success

Nullmailer Mental Model

smtp.myisp.com smtp --port=465 --user=junk@myisp.com --pass=mypassword --ssl

Troubleshooting Tools for Nullmailer

It's an idea. A method. It's been around since the hunter-gatherers settled down to farming, and had to repair their plows. It's a simple idea:

ps

slitt@mydesk:~$ ps ax | grep nullmail
 6167 pts/15   S+     0:00 nullmailer-send
 6223 pts/9    S+     0:00 grep --color=auto nullmail
slitt@mydesk:~$

Injection Shellscript

nullmailer-send output

When you run nullmailer-send you can get somewhat of an idea what's going on. Here's what it looks like when you start nullmailer-send in a functional Nullmailer system with no pending emails queued:

Here's what nullmailer-send looks like when you successfully send a message:

So what you do is you view nullmail-send in one (root) terminal, while in another visible terminal your run

Sometimes you see one of these error messages in the running nullmailer-send:

• Sending failed: Could not exec program
• Could not load the config
• Could not open trigger file: Permission denied

libexec/nullmailer/smtp Substitute (test.sh)

smtp.myisp.com test.sh --port=465 --user=junk@myisp.com --pass=mypassword --ssl

But Wait, There's More!

Locate Command

One of the toughest things to do is figure out where the Nullmailer system expects to see its configuration files and its executable files. One would think that the executables would tell this either with an error message or with their --help option.

But noooooooooo! You have to figure it out yourself, pretty much by trial and error. With perhaps hundreds of subdirectories on your computer, you have to trial and error it. The good news is, you can probably greatly narrow the search. Do this:

sudo updatedb
locate nullmailer | grep "/etc"
locate nullmailer | grep "/bin"
locate nullmailer | grep "/sbin"
locate nullmailer | grep "/libexec"

Those likely will give you a pretty good idea where to look for Nullmailer's config and executables. If you've had other Nullmailer installations on this computer, you could get several. And conceivably, if some package maintainer thought it was a good idea to put these things in paths not including the word "nullmailer", the preceding might yield wrong or no information. But chances are, they'll yield the correct directories, and not too many others.

From there, it's just a matter of changing remotes to run test.sh instead of smtp, and see whether the change takes place. And if it does, see the output of  test.sh. A little trial and error should positively indicate the correct directories. And of course, if worse comes to worse, in a candidate directory you can rename a file and see whether the symptom changes.

Troubleshooting Ladder

1. ping smtp.myisp.com, or whatever the URL of the SMTP server you're trying to send to. If you have no connectivity, nothing else will work. If ping fails, make sure it's not a firewall problem on your end or theirs. Hint: If you can't ping anything on the Internet, that's a good indication that you have a connectivity or firewall problem on your end. Also, try the traceroute and nmap. If you can find no evidence of the far end, this might be a good time to call tech support at your ISP.
2. Verify user and group nullmail by grepping against /etc/passwd and /etc/group as root. Nullmailer specifications say that this user and group is necessary to run Nullmailer. If they're not there, use adduser to create them.
3. Find Nullmailer directories
1. sudo updatedb or su -c updatedb to update the locate database
2. locate -r /smtp$ | grep libexec to find the libexec(s)
3. locate -r /nullmailer-send$ to find Nullmailer's sbin directory(s)
4. locate -r /nullmailer-inject$ to find Nullmailer's bin directory(s)
5. locate -r /remotes$ to find Nullmailer's etc directory(s)
6. For each of the preceding directory categories, find the legitimate directory used by the currently installed Nullmailer version via experimentation, such as renaming a needed file and seeing if the symptom changes. If none of the listed directories respond to a file rename, it's likely the correct directories don't exist.
4. Verify that nullmailer-send is running when you send a message. If it's not, the message can't possibly get sent.
5. Verify that nullmailer-send is running as either root or user nullmail. If it's not, there will probably be problems.
6. Verify that the SMTP login info you're using: name, password, SSL status, port, protocol and the like work in an email program. If you've been regularly sending email from an email client on your computer, this info is what you need to use in your remotes file.
7. If you're trying to use SSL, verify that your libexec/nullmailer/smtp is SSL capable with this command:
   libexec/nullmailer/smtp --help
   If it doesn't list an argument called --ssl, this program cannot possibly do SSL and will throw an error message if you put --ssl in remotes. If this command doesn't show --ssl as a possible argument, you'll need to recompile Nullmailer 1.10 or later using the --enable-tls argument to ./configure, and then, as the make repeatedly aborting because of dependencies, you'll need to install packages to fulfill those dependencies. You're almost certainly going to need to install  the gnutls and gnutls dev packages, although of course they could be called something else.
8. If the preceding test indicated SSL support, verify that your line in remotes contains the --ssl flag, or else it can't possibly do SSL.
9. Use test.sh.

Diagnostic Prints

fprintf(stderr, "Config file is: >%s<\n", fullname.c_str());

grep

grep -irl "The specific error message" | grep -v \.o$

grep -irl "cli_options" | grep -v \.o$

Fixing the Security Problem

Nullmailer's security problem is that your SMTP server's password is delivered to the smtp executable on the commaned line, meaning it's visible to anyone with local or remote access to the computer, via the ps command. Changing it to an environment variable wouldn't be any better, because the environment variable would be available in the executable's pid directory's environ file.

What you need to do is have the password read from a file readable by the user running the smtp executable, but no other user. Probably its group should be root. So here's how it would work, assuming that user nullmail is running the smtp executable...

Remember, the remotes file looks like this:

smtp.myisp.com smtp --port=465 --user=junk@myisp.com --pass=mypassword --ssl

In this case, you would change the literal mypassword to the filename. For instance:

 --pass=/home/nullmail/pass/pass.txt

Where both the directory pass and the file within it are owned by user nullmail, group root and chmod 700 and 600, respectively. Then the smtp executable would read the file and use it for the password, but those looking at a ps command would only know the filename to a file they could not read.

Unfortunately, due to the way Nullmailer is written (Volleyball Code)), I couldn't find where the password gets set inside the executable, so I was unable to make the change in the amount of time I'd allocated to do so. Keep in mind that only I use my system, so for me it's not much of a security problem.

If you want to make the change, I'd recommend setting a breakpoint at the password to see when it gets set, and also find out where the remotes file gets read. You can then just put the password filename as a separate variable or object property somewhere, and then use it to do the read where the password gets set.

Summary

• Use the Mental Model in this magazine, perhaps with your own additions, perhaps added by use of reverse engineering techniques
• Use tools to look at and strongarm Nullmailer components. Some tools named in this document include:
  • ps command
  • Injection shellscript
  • Viewing output of nullmailer-send
  • libexec/nullmailer/smtp substitute (test.sh)
  • Direct manipulation of the smtp command
  • locate command
  • Troubleshooting ladder
  • Debugger and/or diagnostic prints
  • The grep command
• Keep a cool head (The Attitude)