define(`SMART_HOST', `mail.isp.net')
We don't need to specify SMTP as the transport, as it is the default.
Can you guess what the LOCAL_NET_CONFIG macro and the rewrite rule might be doing?
The LOCAL_NET_CONFIG macro allows you to add raw sendmail rewrite rules to your configuration that define what mail should stay within the local mail system. In our example, we've used a rule that matches any email address where the host belongs to our domain (.$m.) and rewrite it so that it is sent directly to the SMTP mailer. This ensures that any message for a host on our local domain is directed immediately to the SMTP mailer and forwarded to that host, rather than falling through to our smart host, which is the default treatment.
Managing Unwanted or Unsolicited Mail (Spam)
If you've subscribed to a mailing list, published your email address on a web site, or posted an article to UseNet, you will most likely have begun to receive unsolicited advertising email. It is commonplace now for people to scour the net in search of email addresses to add to mailing lists that they then sell to companies seeking to advertise their products. This sort of mass-mailing behavior is commonly called spamming.
The Free On-line Dictionary of Computing offers a mail-specific definition of spam as:[112]
2. (A narrowing of sense 1, above) To indiscrimately send large amounts of unsolicited e-mail meant to promote a product or service. Spam in this sense is sort of like the electronic equivalent of junk mail sent to "Occupant."
In the 1990s, with the rise in commercial awareness of the net, there are actually scumbags who offer spamming as a "service" to companies wishing to advertise on the net. They do this by mailing to collections of e-mail addresses, Usenet news, or mailing lists. Such practises have caused outrage and aggressive reaction by many net users against the individuals concerned.
Fortunately, sendmail includes some support for mechanisms that can help you deal with unsolicited mail.
The Real-time Blackhole List
The Real-time Blackhole List is a public facility provided to help reduce the volume of unsolicited advertising you have to contend with. Known email sources and hosts are listed in a queryable database on the Internet. They're entered there by people who have received unsolicited advertising from some email address. Major domains sometimes find themselves on the list because of slip-ups in shutting down spam. While some people complain about particular choices made by the maintainers of the list, it remains very popular and disagreements are usually worked out quickly. Full details on how the service is operated may be found from the home site of the Mail Abuse Protection System at http://maps.vix.com/rbl/.
If you enable this sendmail feature, it will test the source address of each incoming mail message against the Real-time Blackhole List to determine whether to accept the message. If you run a large site with many users, this feature could save a considerable volume of disk space. This feature accepts a parameter to specify the name of the server to use. The default is the main server at rbl.maps.vix.com.
To configure the Real-time Blackhole List feature, add the following macro declaration to your sendmail.mc file:
FEATURE(rbl)
Should you wish to specify some other RBL server, you would use a declaration that looks like:
FEATURE(rbl,`rbl.host.net')
The access database
An alternative system that offers greater flexibility and control at the cost of manual configuration is the sendmail access_db feature. The access database allows you to configure which hosts or users you will accept mail from and which you will relay mail for.
Managing who you will relay mail for is important, as it is another technique commonly employed by spamming hosts to circumvent systems such as the Real-time Blackhole List just described. Instead of sending the mail to you directly, spammers will relay the mail via some other unsuspecting host who allows it. The incoming SMTP connection then doesn't come from the known spamming host, it instead comes from the relay host. To ensure that your own mail hosts aren't used in this way, you should relay mail only for known hosts. Versions of sendmail that are 8.9.0 or newer have relaying disabled by default, so for those you'll need to use the access database to enable individual hosts to relay.
The general idea is simple. When a new incoming SMTP connection is received, sendmail retrieves the message header information and then consults the access database to see whether it should proceed to accept the body of the message itself.
The access database is a collection of rules that describe what action should be taken for messages received from nominated hosts. The default access control file is called /etc/mail/access. The table has a simple format. Each line of the table contains an access rule. The lefthand side of each rule is a pattern used to match the sender of an incoming mail message. It may be a complete email address, a hostname, or an IP address. The righthand side is the action to take. There are five types of action you may configure. These are:
OK
Accept the mail message.
RELAY
Accept messages from this host or user even if they are not destined for our host; that is, accept messages for relaying to other hosts from this host.
REJECT
Reject the mail with a generic message.
DISCARD
Discard the message using the $#discard mailer.
### any text
Return an error message using ### as the error code (which should be RFC-821 compliant) and "any text" as the message.
An example /etc/mail/access might look like:
friends@cybermail.com REJECT
aol.com REJECT
207.46.131.30 REJECT
postmaster@aol.com OK
linux.org.au RELAY
This example would reject any email received from friends@cybermail.com, any host in the domain aol.com and the host 207.46.131.30. The next rule would accept email from postmaster@aol.com despite the fact that the domain itself has a reject rule. The last rule allows relaying of mail from any host in the linux.org.au domain.
To enable the access database feature, use the following declaration in your sendmail.mc file:
FEATURE(access_db)
The default definition builds the database using hash -o /etc/mail/access, which generates a simple hashed database from the plain text file. This is perfectly adequate in most installations. There are other options that you should consider if you intend to have a large access database. Consult the sendmail book or other sendmail documentation for details.
Barring users from receiving mail
If you have users or automated processes that send mail but will never need to receive it, it is sometimes useful to refuse to accept mail destined for them. This saves wasted disk-space storing mail that will never be read. The blacklist_recipients feature, when used in combination with the access_db feature, allows you to disable the receipt of mail for local users.
112
The Free On-Line Dictionary of Computing can be found packaged in many Linux distributions, or online at its home page at http://wombat.doc.ic.ac.uk/foldoc/.