One application of access control mappings is to prevent people from relaying SMTP mail through your PMDF system; for instance, to prevent people from using your PMDF system to relay junk mail to hundreds or thousands of Internet mail boxes.
By default PMDF does not prevent SMTP relaying activity: for starters, SMTP relaying is not necessarily a bad thing. Sites should only block such activity if it is causing them difficulty. Morever, note that local users using POP or IMAP depend upon PMDF to act as an SMTP relay. Blocking unauthorized relaying while allowing it for legitimate local users requires configuring PMDF to know how to distinguish between the two classes of users. Configuring PMDF to make this distinction is the topic of the next section.
16.1.6.1 Differentiating between internal and external mail
In order to block mail relaying activities, you must first be able to
differentiate between internal mail originated at your site and
external mail originated out on the Internet and passing through your
system back out to the Internet. The former class of mail you want to
permit; the latter class you want to block. This differentiation is
achieved using the switchchannel keyword on your inbound
SMTP channel, usually the tcp_local channel.
The switchchannel keyword works by causing the PMDF SMTP
server to look at the actual IP address associated with the incoming
SMTP connection. PMDF uses that IP address, in conjunction with your
rewrite rules, to differentiate between an SMTP connection originated
within your domain and a connection from outside of your domain. This
information can then be used to segregate the message traffic between
internal and external traffic.³
Let's now actually change your PMDF configuration so that you can
differentiate between your internal and external message traffic. This
is done by editing your PMDF configuration file, pmdf.cnf,
located in the PMDF table directory.
defaults noswitchchannelSo that the configuration file appears something like
! final rewrite rules defaults noswitchchannel ! Local channel l ...If you already have a defaults channel at this point in your configuration file, then simply add the
noswitchchannel
keyword to it.
switchchannel and remotehost keywords,
e.g.,
tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON
tcp_internal smtp single_sys mx allowswitchchannel routelocal TCP-INTERNALThe
routelocal channel keyword is used to cause
short-circuited rewriting of source routed addresses through this
channel, thereby blocking possible attempts to relay by means of
looping through internal SMTP hosts via explicitly source routed
addresses.
.acme.com $U%$H$D@TCP-INTERNAL [a.b.] $U%[a.b.$L]@TCP-INTERNAL$E$R
With the above configuration changes, SMTP mail generated within your domain will come in via the tcp_internal channel. All other SMTP mail will come in via the tcp_local channel. You can therefore distinguish between internal and external mail based upon which channel it comes in on.
How does the above work? The key is the switchchannel
keyword. In Step 2 above, that keyword is applied to the tcp_local
channel. When a message comes in your SMTP server, that keyword causes
the server to look at the source IP address associated with the
incoming connection. The server attempts a reverse-pointing envelope
rewrite of the literal IP address of the incoming connection, looking
for an associated channel. If that rewrite matches a local host of
yours, then the rewrite rules added in Step 4 cause the address to
rewrite to the tcp_internal channel added in Step 3. Since the
tcp_internal channel is marked with the allowswitchchannel
keyword, the message is "switched" to the tcp_internal
channel and comes in on that channel. If the message comes in from an
external source, the IP address will not correspond to an internal
source. In that case the reverse-pointing envelope rewrite will either
rewrite to the tcp_local channel or to some other channel. However, it
will not rewrite to the tcp_internal channel and since all other
channels were marked noswitchchannel in Step 1, the
message will not "switch" to another channel and will remain
with the tcp_local channel.
Note:
Note that any mapping table or conversion file entries which use the string "tcp_local" may need to be changed to either "tcp_*" or "tcp_internal" depending upon the usage.
16.1.6.2 Differentiating authenticated users' mail
Sometimes administratively local users of IMAP and POP clients may wish
to submit their messages when they aren't physically local (aren't
physically on your network). Though such message submissions come in
from an external IP address---for instance, arbitrary Internet Service
Providers---if your users use mail clients that can perform SASL
authentication, then their authenticated connections can be
distinguished from arbitrary other external connections. The
authenticated submissions you can then permit, while denying
non-authenticated relay submission attempts. Differentiating between
authenticated and non-authenticated connections is achieved using the
saslswitchchannel keyword on your inbound SMTP channel,
usually the tcp_local channel.
The saslswitchchannel keyword takes an argument specifying
the channel to switch to; if an SMTP sender succeeds in authenticating,
then their submitted messages are considered to come in the specified
switched to channel.
We will now continue the example of the previous section, adding in distinguishing authenticated submissions.
tcp_auth smtp single_sys mx mustsaslserver noswitchchannel TCP-INTERNALThis channel should not allow regular channel switching (that is, it should have
noswitchchannel on it either explicitly or
implied by a prior defaults line). This channel should
have mustsaslserver on it.
maysaslserver
and saslswitchchannel tcp_auth to it. So your tcp_local
channel definition should now appear along the lines of:
tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth \ switchchannel TCP-DAEMON
With this configuration, SMTP mail sent by users who can authenticate with a local password will now come in the tcp_auth channel. Unauthenticated SMTP mail sent from internal hosts will still come in tcp_internal. All other SMTP mail will come in tcp_local.
16.1.6.3 Preventing mail relaying
Now to the point of this example: preventing unauthorized people from
relaying SMTP mail through your system. First, keep in mind that you
want to allow local users to relay SMTP mail. For instance, POP and
IMAP users rely upon using PMDF to send their mail. Note that local
users may either be physically local, in which case their messages come
in from an internal IP address, or may be physically remote but able to
authenticate themselves as local users. It's random people out on the
Internet who you want to prevent from using you as a relay. With the
configuration from Section 16.1.6.1 and Section 16.1.6.2 , you can
differentiate between these classes of users and block the correct
class. Specifically, you want to block mail from coming in your
tcp_local channel and going back out that same channel. To that end, an
ORIG_SEND_ACCESS mapping table is used.
An ORIG_SEND_ACCESS mapping table may be used to block traffic based upon the source and destination channel. In this case, traffic from and back to the tcp_local channel is to be blocked. This is realized with the following ORIG_SEND_ACCESS mapping table:
ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NRelaying$ not$ permittedIn the above, the entry states that messages cannot come in the tcp_local channel and go right back out it. That is, this entry disallows external mail from coming in your SMTP server and being relayed right back out to the Internet.
An ORIG_SEND_ACCESS mapping table is used rather than a SEND_ACCESS mapping table, so that the blocking will not apply to addresses that originally match the l (lowercase L) channel (but which may expand via an alias or mailing list definition back to an external address). With a SEND_ACCESS mapping table one would have to go to extra lengths to allow outsiders to send to mailing lists that expand back out to external users, or to send to users who forward their messages back out to external addresses.
16.1.6.4 Allowing localhost submissions to the SMTP port
This section discusses a further refinement of the SMTP relay blocking
approach described above.
Some sites may wish to disallow submissions to the SMTP port from clients running on the system itself; for instance, if no legitimate applications are expected to attempt this, then blocking such submissions closes one avenue by which users can spoof (forge) e-mail.
Other sites, however, may have legitimate applications that perform message submission by making a TCP/IP connection to the SMTP port of their own system. For instance, some third party mailing list expansion applications (though not PMDF's own mailing list expansion) operate in this way.
Further, to simplify their configuration such applications may connect using a loopback name or address, such as LOCALHOST or [127.0.0.1], rather than using the system's domain name. Depending on the underlying TCP/IP package, this may result in the incoming connection also appearing to come from LOCALHOST or [127.0.0.1], rather than coming from the system's specific domain name or IP address.
Using merely the internal vs external differentiation as shown above in Section 16.1.6.1 would result in treating SMTP submissions from clients on the host system itself as coming in the tcp_local channel. Thus if tcp_local to tcp_local message traffic is prevented, as discussed in Section 16.1.6.3 , then any users or applications attempting to submit messages in such a way would not be allowed to submit messages to external addressees.
If you wish to treat such submissions as "internal" submissions, for instance, in order to allow third party mailing list applications to operate even if SMTP relay blocking has been implemented, then an additional configuration step should be performed.
To the very top of the PMDF configuration file, add rewrite rules for the local host name (or LOCALHOST or [127.0.0.1], depending on from where the underlying TCP/IP package "sees" the connection as having originated) of the following form:
localhostname $U%localhostname@TCP-INTERNAL$E$R [localhostipnumber] $U%localhostname@TCP-INTERNAL$E$R LOCALHOST $U%localhostname@TCP-INTERNAL$E$R [127.0.0.1] $U%localhostname@TCP-INTERNAL$E$Rwhere
localhostname is the official host name on
the L channel. The $E and $R control sequences on these rewrite rules,
which limit their effect to envelope From: address rewriting, mean that
normal rewriting will still apply to addresses addressed to the local
system. Yet switchchannel rewriting will use these rules
also, and hence will see message submissions from the system to its own
SMTP port as "internal" submissions.