Build a mailertable that routes mail bound for specific domains through the procmail mailer.

Create a file in the /etc/procmailrcs directory that defines the specific filtering needed. Multiple filters can be used.

Create a sendmail configuration that enables the mailertable feature and adds procmail to the list of available mailers. Here are the lines that should be added to the sendmail configuration:

dnl Enable support for the mailertable

FEATURE(`mailertable')

dnl Add procmail to the list of available mailers

MAILER(procmail)

Build the sendmail.cf file, copy it to /etc/mail/sendmail.cf

The MAILER(procmail) macro adds the procmail mailer definition to the sendmail.cf file. The procmail mailer is not related to the local_procmail feature. A system can use the procmail mailer without using procmail as a local mailer, and procmail can be used as a local mailer without adding the MAILER(procmail) macro to the configuration.

The MAILER(procmail) macro does not add any code to the configuration to use the procmail mailer. You must either add custom sendmail.cf rules to reference the mailer, or route mail through the procmail mailer using the mailertable. Using the mailertable is the easiest and the recommended way to access the mailer. Here we add mailertable entries that invoke procmail:

# cd /etc/mail 

# cat >> mailertable 

example.com       procmail:/etc/procmailrcs/spam-filter

wrotethebook.net  procmail:/etc/procmailrcs/spam-filter

fake.ora.com      procmail:/etc/procmailrcs/uce-filter  

Ctrl-D 

# makemap hash mailertable < mailertable 

The example adds three entries to the mailertable that route mail through the procmail mailer. The first field in a mailertable entry is the key against which the recipient address is matched. The second field is the mailer value and the host value that sendmail uses to build the mail delivery triple. In this example, mail with a matching recipient address is routed through the procmail mailer. A few tests of a system running show this:

# sendmail -bv crooks@example.com

crooks@example.com... deliverable: mailer procmail, host /etc/procmailrcs/

spam-filter, user crooks@example.com

# sendmail -bv spammers@wrotethebook.net

spammers@wrotethebook.net... deliverable: mailer procmail, host /etc/procmailrcs/

spam-filter, user spammers@wrotethebook.net

# sendmail -bv thieves@fake.ora.com  thieves@fake.ora.com... deliverable: mailer procmail,

 host /etc/procmailrcs/  uce-filter, user thieves@fake.ora.com

When mail is routed to the procmail mailer, the host value ($h) must contain the pathname of the rc-file that procmail should use to filter the mail. In the example above, two different filters, spam-filter and uce-filter, are passed to procmail depending on the destination of the email. sendmail calls procmail from the procmail mailer using the following command:

procmail -Y -m $h $f $u

The -Y flag tells procmail to use the Berkeley Unix mailbox format. The -m flag runs procmail as a general-purpose mail filter. The first argument that follows the -m flag must be the path of the rc-file that contains the procmail filter. sendmail assigns the host value returned by the mailertable lookup to the $h macro, which it then passes to procmail as the first argument after the -m flag. Therefore, the host field of a mailertable entry that uses the procmail mailer must contain the full pathname of an rc-file.

The next two arguments passed to procmail are the envelope sender email address ($f) and the envelope recipient email address ($u). These values are available inside the procmail rc-file as variables $1 and $2, respectively.

One common technique for avoiding a loop is to add the pseudodomain .PROCMAIL to the recipient address when mail is resent to the original recipient. The pseudodomain ensures that the recipient address no longer matches a value in the mailertable, which breaks the loop. The pseudodomain is added by procmail commands in the rc-file. However, a properly configured rc-file is not the complete solution. .PROCMAIL is not a real domain, so code must be added to the sendmail.cf file to ensure that the pseudodomain is properly handled. The following m4 macros and sendmail.cf code, added to the end of the this recipe’s master configuration file, handle the .PROCMAIL pseudodomain, if one is added by the rc-file:

LOCAL_CONFIG

# Add .PROCMAIL to the pseudo-domain list

CP.PROCMAIL

LOCAL_RULE_0

# Strip .PROCMAIL and send via esmtp

R$+ < @ $+ .PROCMAIL . >        $#esmtp $@ $2 $: $1<@$2>

The LOCAL_CONFIG macro marks the start of code that is to be added to the local information section of the sendmail.cf file. In this example, we add a comment and a C command to the local information section. The C command adds .PROCMAIL to class P. Class P lists pseudodomains that sendmail should not attempt to lookup in the DNS. Adding .PROCMAIL to class P avoids the delays and wasted resources that occur when sendmail looks up a domain name that does not exist.

The LOCAL_RULE_0 macro marks the start of sendmail.cf code that is added to ruleset 0—more commonly called the parse ruleset. Specifically, the code that follows the LOCAL_RULE_0 macro is added to the ParseLocal ruleset, which is a hook into the parse ruleset where locally defined rules are addedThe parse ruleset rewrites the delivery address to a mail delivery triple.

The code that follows the LOCAL_RULE_0 macro in the example is a comment and a rewrite rule. The R command matches input addresses of the form user@domain.PROCMAIL, and rewrites those addresses into a mail delivery triple where the mailer is esmtp, the host value is domain, and the user value is user@domain. After rebuilding the configuration with the new master configuration file, running a sendmail -bv test shows the impact of this rewrite rule:

# sendmail -bv crooks@example.com.PROCMAIL

crooks@example.com.PROCMAIL... deliverable: mailer esmtp, host example.com,

user   crooks@example.com

Add the local_procmail feature to the sendmail configuration, placing the FEATURE macro after the OSTYPE macro and before the MAILER(`local’) line in the master configuration file. Values for the local mailer are usually set in the OSTYPE file. Carefully review the file for your operating system. Add the local_procmail feature to your master configuration file only if local_procmail is not already included in the OSTYPE file.

Create an /etc/procmailrc file containing the filters you want to apply to local mail.

Build and install the new configuration

The linux.m4 OSTYPE file contains the local_procmail feature because procmail is the local mailer used by default on most Linux systems. On a Linux system, just running a configuration that uses the linux.m4 OSTYPE file is sufficient. Other systems are not so easy. For example, assume you have a Solaris 8 system. The solaris8.m4 OSTYPE file uses the local_lmtp feature to set mail.local as the local mailer. To change the local mailer to procmail, override the local_lmtp feature by placing the local_procmail feature in the master configuration file. Here is an example based on the generic-solaris.mc file:

VERSIONID(`Solaris with local_procmail added’)
OSTYPE(solaris2)
DOMAIN(generic)
dnl Add the local_procmail feature
FEATURE(`local_procmail’)
MAILER(local)
MAILER(smtp)

Because the local_procmail feature occurs after the OSTYPE macro, it overrides the local_lmtp feature defined in the OSTYPE file. The local_procmail feature is enabled once the sendmail.cf file is built, copied to sendmail.cf, and sendmail is restarted.

When the local_procmail feature is used, sendmail passes local mail to procmail for delivery. procmail processes the mail, first using the commands defined in the /etc/procmailrc file and then using the commands defined in the .procmailrc file in the recipient’s home directory. If no rc file is defined, procmail writes the mail to the user’s mailbox unaltered. Note that the user’s .procmailrc file is applied to mail delivered by the local_procmail feature. When local_procmail is used, it is not necessary for the user to call the procmail program from the .forward file. All the user needs to do is create a .procmailrc file and it will be applied to the mail. Using procmail as a local mailer allows both the system administrator and the user to filter inbound mail with procmail.

When procmail is used as the local mailer, sendmail runs it with three arguments: -Y, -a, and -d. The -Y argument tells procmail to use the standard Berkeley Unix mailbox format. The -d argument provides procmail with the username of the local recipient who is to receive the mail (in the mail delivery triple this is the user value). The -a argument passes an optional value to procmail that is accessible inside the procmail as the $1 variable; in the mail delivery triple, this is the host value. sendmail only passes a value through -a when either the +detail syntax is used or mail is routed to the local mailer via the mailertable. In the case of the +detail syntax, the detail value is passed. In the case of the mailertable, the input address that was the key to the mailertable entry is the value passed. In all other cases, no value is passed by the -a argument and the $1 variable is unassigned.

Using a graphical user interface

1. Open the Control Panel.
2. From the Network Connections applet, open the connection you want to configure.
3. Click the Properties button.
4. Select Internet Protocol (TCP/IP).
5. Click the Properties button.
6. Click the Advanced button.
7. Click the Options tab.
8. Select TCP/IP filtering.
9. Click the Properties button.
10. Check the box beside Enable TCP/IP Filtering.
11. Select Permit Only for TCP Ports, UDP Ports, and/or IP Protocols.
12. Click the Add button.
13. Enter the port or protocol number and click OK.
14. Repeat the last couple of steps until you’ve entered all desired ports and protocols.
15. After you are done, close all the dialog screens by clicking either OK or Close.
16. You will be prompted to reboot for the changes to take effect.

Using a command-line interface

The following command enables TCP/IP filtering:

> reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /vEnableSecurityFilters /t REG_DWORD /d 1

You must reboot for the changes to take effect. To disable filtering, change /d 1 to /d 0.

Next, configure the protocols and ports you want to filter. This must be done on a per-interface basis. To configure this using the registry, you need to know the GUID assigned to the interface you want to modify. This is a sample interface entry:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{07383FC4-FF4D-4E16-9DD6-C27061719D76}

To find out what adapter that corresponds with, you can use this command (on Windows Server 2003):

> wmic nicconfig get caption,settingid

Once you know the GUID of the interface, you can use the reg add command to modify the RawIPAllowedProtocols, TCPAllowedPorts, or UDPAllowedPorts values to filter what you want. Each of those values is of type REG_MULTI_SZ. Here is an example of setting protocols 25 and 80:

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{07383FC4-FF4D-4E16-9DD6-C27061719D76} /v RawIPAllowedProtocols /t REG_MULTI_SZ /d 25\080

You can also use the WMIC utility to configure TCP/IP filtering. These two commands show you how:

> wmic /node:"<ServerName>" nicconfig call EnableIPFilterSec(1)> wmic /node:"<ServerName>" nicconfig where ipenabled=True call EnableIPSec

(<TCPPortList>),(<UDPPortList>),(<ProtoList>)

This command allows all TCP and UDP ports, but allows only protocols 80 (http) and 25 (smtp):

> wmic nicconfig where ipenabled=True call EnableIPSec (80,25),(0),(0)

Using VBScript

' This code enables IP Filtering for all adapters and configures' filtering for all IP-enabled adapters.

' ------ SCRIPT CONFIGURATION ------

strComputer = "."

arrTCPPorts = Array ( 0 )       ' Allow all TCP ports

arrUDPPorts = Array ( 0 )       ' Allow all UDP ports

arrProtos   = Array ( 80, 25 )  ' Allow only HTTP and SMTP

' ------ END CONFIGURATION ---------

set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

set objAdapterConfig = objWMI.Get("Win32_NetworkAdapterConfiguration")

intRC = objAdapterConfig.EnableIPFilterSec( True )

if intRC = 0 then

WScript.Echo "IP Filtering for all adapters enabled"

elseif intRC = 1 then

WScript.Echo "IP Filtering enabled for all adapters, " & _

"but you must reboot for the changes to take effect"

else

WScript.Echo "There was an error enabling IP Filtering for all " & _

"adapters: " & intRC

end ifset colNAConfigs = objWMI.ExecQuery( _

"select * " & _

" from Win32_NetworkAdapterConfiguration " & _

" where IPEnabled = True" )

for each objNAConfig in colNAConfigs

intRC = objNAConfig.EnableIPSec( arrTCPPorts, arrUDPPorts, arrProtos )

if intRC = 0 then

WScript.Echo "IP Filtering configured for '" & _

objNAConfig.Description & "'"

elseif intRC = 1 then

WScript.Echo "IP Filtering configured for '" & objNAConfig.Description & _

"', but you must reboot for the changes to take effect"

else

WScript.Echo "There was an error configuring IP Filtering for '" & _

objNAConfig.Description & "': " & intRC

end if

next

Filtering by port or protocol can be useful in certain situations, but be aware of the limitations. A good example of when you might want to configure filtering is for external web servers. If your web server is running on the default HTTP port (80) and it is running no other networked application, then you only need port 80 open. But allowing only port 80 traffic also prevents the server from acting as a member in an Active Directory domain (which requires several ports to be open) and makes remote administration difficult because you can’t connect using the Terminal Services client. Obviously you can add these ports to the list you allow, but remember that if you do port/protocol filtering, you must have the ports/protocols open that are needed to support the machine.