Symptom:
(public)
These are the most often asked questions in regards to SPAM:
  • My server is used by SPAMmers. What can I do to stop that?
  • Sendmail shut down because it is overloaded. What's going on?
  • Thousands of undeliverable emails appeared in my admin mailbox. What gives?
  • What about SMTP-AUTH?

Let us start with some technical background. Nothing too complicated - promised.

Problem:
(public)

For emailing purpose three separate services are installed on a RaQ:

Sendmail:

Runs on port 25 tcp and is responsible for sending emails to remote or local destinations.

Qpopper:

Runs on port 110 tcp. When you fetch email with an POP3 client, then this email program connects to port 110 on your server and talks to Qpopper, which in turn establishes a connection with the users local mailbox file. So POP3 is only used for receiving emails.

IMAP:

Runs on port 143 tcp and serves the same general purpose as Qpopper. It interacts between an email client and the users mailbox file on the server and is only used for receiving emails.

Aside from the shared purpose POP3 and IMAP have another thing in common: Users have to authenticate against them with their username and password.

However, Sendmail on the RaQs is usually wide open and anyone (and their mother) can use it to send emails to local and remote mailboxes.

This is a heritage from the good old days of the internet before marketing squirrels and AOL users discovered the internet and the benefits of email.


Solution:
(public)

This means that any Sun Cobalt server appliance is prone to being (ab)used as a spammer heaven unless the server administrator activates a service specifically designed to deny Sendmail to all but legitimate users:

POP-before-SMTP:

This service is an additional daemon which runs persistently in the background. It checks the logfiles and writes the IP-address of anyone who successfully connects to POP3 and IMAP (with their username and password) into a small database. Only IP addresses in this database are allowed to use Sendmail to send mails to local or remote destinations.

A configurable time (usually 5 minutes) after their last POP3 or IMAP access these IP addresses are removed from the database.

This small but effective procedure pretty much hardens your RaQ against the dangers of being abused as SPAM sending source by third parties.

More information about POP-before-SMTP and how to enable it is available in this official Sun Cobalt PDF file.

FormMail.pl

The second most common cause for RaQs being used to send SPAM is Matt Wright's FormMail script.

Many people use his scripts - his FormMail.pl script for instance was downloaded 2 million times according to his own website.

Ever since 1997 FormMail.pl has had security issues which could be abused to trick your mail server into sending emails to anyone. Nowadays automated tools are available which scan the internet for servers and domains which run vulnerable versions of FormMail and once they find such a script on your server, then you are in a world of pain.

If you have to run FormMail.pl (and do not switch to a more security minded software for that purpose), then make darn sure that you run version 1.92 and NOT any older version of it.

Personally I would not even recommend to go for the latest FormMail.pl because of its troubled history, it's widespread use and the unduly long time that it took the programmer to fix the problems.

How to detect if you are used as SPAM sender?

Well, the logfiles will tell the whole sad story. Check /var/log/maillog and also check your admin email account. If your RaQ sends SPAM to third parties and they refuse to accept it (because the recipient no longer exists - for instance), then the email bounces back to you. And ends up in your admin mailbox. In that case you simply use the following checklist:

a) Is POP-before-SMTP enable?

If not, then enable it.

b) Check if a FormMail.pl script exists in one of the virtual sites:

find /home/sites/ -name *orm*ail.*

That will return all instances of FormMail scripts in the directory /home/sites (and subdirectories) which are named either way:

FormMail.pl
FormMail.cgi
formmail.pl
formmail.cgi
Formmail.pl
Formmail.cgi

(This search will show any files which are named FormMail with all possible extensions - like .php, .htm, .html, .asp)

Then simply delete all those returned files. Sure, some of the returned FormMail scripts might be secure, but you can't be expected to debug third party scripts while you're under a SPAM attack, right? So expect some collateral damage and handle this along the lines of "Kill 'em all and let God sort 'em out."


Relay for the following Hosts/Domains:

A section named like that exists in the GUI in "Control Panel" / "Services" / "Sendmail Parameters".

What happens if you put "aol.com" into that field? Well, right: Anyone using AOL to connect to the Internet can use your RaQ to send emails. To anyone. Regardless of POP-before-SMTP.

Is it a smart idea? Of course not. But don't laugh, I see it all the time - which makes this world a sad place. For you, me and anyone with a mailbox.

So make sure to never ever put anything into that field unless you really know what you are doing and know all the consequences.


What about SMTP-AUTH?

SMTP AUTH is " ..an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Security Layer [SASL]. "

This is what RFC 2554 says.

For mere mortals this means that nobody can use Sendmail to send email, unless they authenticate with a username and password.

However, on a RaQ SMTP-AUTH is not available on a RaQ. Support for it is not compiled into Sendmail. Recompiling and/or upgrading Sendmail on a RaQ is no trivial task due to a couple of Sun Cobalt specific extras and add ons. So it is not an option.Switch to BlueQuartz, where it is available by default.