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.
22.214.171.124 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
keyword on your inbound SMTP channel, usually the tcp_local channel.
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.3
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,
located in the PMDF table directory.
! final rewrite rules defaults noswitchchannel ! Local channel l ...
noswitchchannelkeyword to it.
tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON
tcp_auth smtp single_sys mx allowswitchchannel routelocal TCP-INTERNAL
routelocalchannel 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.
.example.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
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
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 that any mapping table or conversion file entries which use the string "tcp_local" can need to be changed to either "tcp_*" or "tcp_internal" depending upon the usage.
126.96.36.199 Differentiating Authenticated Users' Mail
Sometimes administratively "local" users of IMAP and POP
clients can want 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
saslswitchchannel keyword on your inbound SMTP
channel, usually the tcp_local channel.
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-AUTH
noswitchchannelon it either explicitly or implied by a prior
defaultsline). This channel should have
saslswitchchannel tcp_authto 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.
188.8.131.52 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 can either be physically local, in which case their messages come
in from an internal IP address, or can 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 184.108.40.206 and Section 220.127.116.11, 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 can 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$ permitted
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 can 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.
18.104.22.168 Allowing localhost Submissions to the SMTP Port
This section discusses a further refinement of the SMTP relay blocking
approach described above.
Some sites can want 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, can 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 can 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 can 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 22.214.171.124 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 126.96.36.199, 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 want 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$R
localhostnameis 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
switchchannelrewriting will use these rules also, and hence will see message submissions from the system to its own SMTP port as "internal" submissions.
3 Since the source IP address is used, it is important that your network router connecting your local network to the Internet be configured to prevent "IP spoofing". Contact your router vendor for assistance if you are unsure of how to configure your router.