The MAIL_ACCESS mapping table is a superset of the SEND_ACCESS and PORT_ACCESS mapping tables. It combines both the channel and address information of SEND_ACCESS with the IP address and port number information of PORT_ACCESS. Similarly, the ORIG_MAIL_ACCESS mapping table is a superset of the ORIG_SEND_ACCESS and PORT_ACCESS mapping tables. The format for the probe string for MAIL_ACCESS is:
Similarly, the format for the probe string for ORIG_MAIL_ACCESS is:
Here port-access-probe-info consists of all the information usually included in a PORT_ACCESS mapping table probe in the case of incoming SMTP messages; otherwise, it is blank. app-info includes the system name claimed in the HELO/EHLO SMTP command. This name appears at the end of the string and is separated from the rest of the string (normally “SMTP*”) by a slash. The claimed system name can be useful in blocking some worms and viruses. submit-type may be one of MAIL, SEND, SAML, or SOML, corresponding to how the message was submitted into Messaging Server. Normally the value is MAIL, meaning it was submitted as a message; SEND, SAML, or SOML can occur in the case of broadcast requests (or combined broadcast/message requests) submitted to the SMTP server. And for the MAIL_ACCESS mapping, send-access-probe-info consists of all the information usually included in a SEND_ACCESS mapping table probe. Similarly for the ORIG_MAIL_ACCESS mapping, orig-send-access-probe-info consists of all the information usually included in an ORIG_SEND_ACCESS mapping table probe.
Setting the MTA option ACCESS_ORCPT to 1 adds an additional vertical bar delimited field to the probe value passed to the SEND_ACCESS, ORIG_SEND_ACCESS, MAIL_ACCESS, and ORIG_MAIL_ACCESS mapping tables that contains the original recipient (ORCPT) address. If the message doesn't have an ORCPT address, the original unmodified RCPT TO: address is used instead. The default is 0, and the probe value is at the end. Example:
Having the incoming TCP/IP connection information available in the same mapping table as the channel and address information makes it more convenient to impose certain sorts of controls, such as enforcing what envelope From: addresses are allowed to appear in messages from particular IP addresses. This can be desirable to limit cases of email forgery, or to encourage users to configure their POP and IMAP clients’ From: address appropriately. For example, a site that wishes to allow the envelope From: address firstname.lastname@example.org to appear only on messages coming from the IP address 184.108.40.206 and 220.127.116.11, and to ensure that the envelope From: addresses on messages from any systems in the 18.104.22.168 subnet are from siroe.com, might use a MAIL_ACCESS mapping table as shown in the example below.
MAIL_ACCESS ! Entries for vip's two systems ! TCP|*|25|22.214.171.124|*|SMTP*|MAILemail@example.com|*|* $Y TCP|*|25|126.96.36.199|*|SMTP*|MAILfirstname.lastname@example.org|*|* $Y ! ! Disallow attempts to use vip's From: address from other ! systems ! TCP|*|25|*|*|SMTP*|MAILemail@example.com|*|* \ $N500$ Not$ authorized$ to$ use$ this$ From:$ address ! ! Allow sending from within our subnet with siroe.com From: ! addresses ! TCP|*|25|1.2.*.*|*|SMTP*|MAILfirstname.lastname@example.org|*|* $Y ! ! Allow notifications through ! TCP|*|25|1.2.*.*|*|SMTP*|MAIL|tcp_*||*|* $Y ! ! Block sending from within our subnet with non-siroe.com ! addresses ! TCP|*|25|1.2.*.*|*|SMTP*|MAIL|tcp_*|*|*|* \ $NOnly$ siroe.com$ From:$ addresses$ authorized