Blocking SMTP relaying

One application of the   mapping table, along with appropriate configuration of channels with   and   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   and   channel options in conjunction with a rewrite rule that compares connection source IP addresses against the   mapping table, plus user authentication during message submission in conjunction with the   and   channel options. The effect of such configuration is to "sort" incoming messages based on knowledge of the message&#x27;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  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&#x27;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   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    channel and going back out that same channel. To that end, an  mapping table may be conveniently used.

An  mapping table may be used to block traffic based  upon the source and destination channel. In this case, traffic from and back to the   channel is to be blocked. This is realized with the following   mapping table: ORIG_SEND_ACCESS tcp_local&#x7c;&#x2a;&#x7c;tcp_local&#x7c;&#x2a;              $NRelaying$ not$ permitted In the above, the entry states that messages cannot come in the   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  mapping table is used rather than a     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  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&#x7c;&#x2a;&#x7c;tcp_local&#x7c;&#x2a;              $NRelaying$ not$ permitted ! ! Block direct submission to MTA "intermediate" channels !  tcp_&#x2a;&#x7c;&#x2a;&#x7c;native&#x7c;&#x2a;       $N tcp_&#x2a;&#x7c;&#x2a;&#x7c;hold&#x7c;&#x2a;        $N tcp_&#x2a;&#x7c;&#x2a;&#x7c;pipe&#x7c;&#x2a;        $N ! ! Block direct submission to Message Store delivery channels; ! routing to such channel should only occur due to MTA address/alias ! processing !  tcp_&#x2a;&#x7c;&#x2a;&#x7c;ims-ms&#x7c;&#x2a;        $N tcp_&#x2a;&#x7c;tcp_lmtpcs&#x2a;&#x7c;&#x2a;    $N ! ! Block "external" submissions of explicitly source-routed "internal" addresses !   tcp_local&#x7c;&#x2a;&#x7c;tcp_intranet&#x7c;@&#x2a;:&#x2a;.&#x2a;   $N$D30&#x7c;Explicit$ routing$ not$ allowed tcp_local&#x7c;&#x2a;&#x7c;tcp_intranet&#x7c;&#x2a;$%&#x2a;@&#x2a;  $N$D30&#x7c;Explicit$ routing$ not$ allowed tcp_local&#x7c;&#x2a;&#x7c;tcp_intranet&#x7c;&#x2a;.&#x2a;!&#x2a;@&#x2a; $N$D30&#x7c;Explicit$ routing$ not$ allowed tcp_local&#x7c;&#x2a;&#x7c;tcp_intranet&#x7c;"&#x2a;@&#x2a;"@&#x2a; $N$D30&#x7c;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.

See also:
 * Typical TCPIP channels and servers
 * Recipient access mapping tables
 * switchchannel Option
 * saslswitchchannel Option
 * maysasl Option
 * routelocal Option
 * INTERNAL_IP mapping table
 * Mail filtering and access control
 * TCPIP channels
 * SRS and Relay Blocking