Blocking SMTP relaying
One application of the
ORIG_SEND_ACCESS mapping table, along with appropriate configuration of channels with
saslswitchchannel channel options, is to prevent people from using your MTA to relay junk mail to hundreds or thousands of Internet mail boxes. By default, at a code level, the MTA does not prevent SMTP relaying activity. However, the normal installation and initial configuration does configure to prevent SMTP relaying from "external" sources.
Blocking unauthorized relaying while allowing it for legitimate local users requires configuring the MTA to know how to distinguish between the two classes of users. The distinction between "internal" vs. "external" users is achieved using a combination of the
allowswitchchannel channel options in conjunction with a rewrite rule that compares connection source IP addresses against the
INTERNAL_IP mapping table, plus user authentication during message submission in conjunction with the
saslswitchchannel channel options. The effect of such configuration is to "sort" incoming messages based on knowledge of the message's source (whether that knowledge is of the source of the IP connection, or of the sender of the messages) assigning the messages to different source channels. Once such assignment of source channel has been achieved, then the desired relaying restrictions can be easily controlled in, e.g., the
ORIG_SEND_ACCESS mapping table.
When preventing unauthorized people from relaying SMTP mail through your system, keep in mind that you do want to allow local users to relay SMTP mail! For instance, POP and IMAP users typically rely upon using the MTA 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 those random people out on the Internet who you want to prevent from using you as a relay. With appropriate configuration to recognize the cases of "internal" source IP addresses or local user authenticated messages and handle them via special channels, rather than the default
tcp_local channel, you can differentiate between these classes of users and block only the correct class. Specifically, (once "internal" users have been properly sorted for handling by one or another special incoming channel), 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 may be conveniently used.
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$ permitted
In 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.
Note that 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.
A further refinement, to block attempts to relay "through" internal systems using source-routed addresses, is included in the following sample mapping table:
ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NRelaying$ not$ permitted ! ! Block direct submission to MTA "intermediate" channels ! tcp_*|*|native|* $N tcp_*|*|hold|* $N tcp_*|*|pipe|* $N ! ! Block direct submission to Message Store delivery channels; ! routing to such channel should only occur due to MTA address/alias ! processing ! tcp_*|*|ims-ms|* $N tcp_*|tcp_lmtpcs*|* $N ! ! Block "external" submissions of explicitly source-routed "internal" addresses ! tcp_local|*|tcp_intranet|@*:*.* $N$D30|Explicit$ routing$ not$ allowed tcp_local|*|tcp_intranet|*$%*@* $N$D30|Explicit$ routing$ not$ allowed tcp_local|*|tcp_intranet|*.*!*@* $N$D30|Explicit$ routing$ not$ allowed tcp_local|*|tcp_intranet|"*@*"@* $N$D30|Explicit$ routing$ not$ allowed
The final four entries will cause attempts by remote senders to submit explicitly source-routed messages to be immediately rejected. Note that depending upon the actual configuration of your other, internal hosts, it is often the case that even such explicitly source-routed attempts at relaying will not, in fact, end up truly getting relayed back out to the Internet, but will instead be rejected by the other, internal host. But by rejecting the attempts immediately, you can avoid getting (falsely) accused of being an open relay by carelessly constructed and operated relay testers, that only check if their relay attempt was initially blocked, rather than testing whether the probe message actually ever got relayed out and delivered.