Outbound Port 25 Blocking for Dynamic IP Addresses

In this document, we categorize ISPs into 3 types: ISP model A: ISP that provides Internet connectivity services to other ISPs (model B) ISP model B: ISP that depends on end-user Internet connectivity on other ISPs (model A) ISP model C: ISP that utilize their internet connectivity for their own services only. shows how end clients are connected to the Internet through 3 types of ISPs. (A): the Internet connectivity for subscribers of ISPs of model A (B): the Internet connectivity for subscribers of ISPs of model B (C): the Internet connectivity for subscribers of ISPs of model C

All subscribers of ISPs of model A and model C are connected to the Internet via ISPs to which they subscribe. In , MSAs for these subscribers are located in ISPs users are subscribing to. Lines with labels (A) and (C) in the figure depict the communication between MSAs and clients in ISPs of model A and model C respectively. Subscribers in the ISPs of model B are connected to the Internet via ISPs of model A. This is shown by the line labeled as (B) in the figure. In this case, MSAs are located somewhere on the Internet.

3 figures in this section show the mail distribution paths in the current mail architecture. These figures depict “valid mail submission” scenario, “invalid mail submission” scenario and “valid mail forwarding” scenario respectively. In the figures, ISP A is the mail sender, and ISP B, ISP C, cellular carrier and “ASP/Hosting/Business Enterprise/Academic institution” are mail receivers. ISP A: ISP of model A ISP B: ISP of model B ISP C: ISP of model C MUA: Client PCs which obtain dynamic IP addresses and run MUAs. These MUAs include: Valid User PCs: ISP subscribers’ PCs (not include spam senders or bots) Spam senders Bots

| MSA | | | +-------+ | | | +-------+ | | ^ | | | ^ | | | | | | |(b) | | +---------------------------------|-------+ +---------------+ | | | | | | | | | | | +-------+ | | +-+-+ +---+ | | |(b) | | MSA | | | |MUA| |MUA| | | | | +-------+ | | +---+ +---+ | | | | ^(a) | ISP A| +-+----------+-------------|--------|-------+ | +--------| +-+-+ +---+ +-+-+ |MUA| |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> shows valid mail submissions by ISP subscribers. These submissions MUST NOT be disrupted by OP25B. (a): submissions from MUA to MSA of ISP A (b): submissions from MUA to MSA located outside of ISP A (e): submissions from MUA to cellular carriers (These submissions do not exist in the real world. This is detailed in )

| MSA | | | +-------+ | | | +-------+ | | | | | | | | | | | | +---------------|-------------------------+ +---------------+ | | | | | | | | | +-------+ | +---+ +---+ | | | | | MSA | | |MUA| |MUA| | | | | +-------+ | +---+ +---+ | | | | ^(f) ISP A| +-+----------+----|-----|-------------------+ | +---+ +---+ +-+-+ +---+ |MUA| |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> shows invalid mail submissions by spam senders or bots. These submissions are the block target of OP25B. (c): submissions from spam senders or bots to MTAs located outside of ISP A (d): submissions from spam senders or bots to MTAs located in cellular carriers (f): submissions from spam senders or bots to MSAs of ISP A

Spam senders’ strategies can be categorized into two patterns: Pattern I: submit spam mails to MSA and let the MSA to distribute them. Pattern II: submit spam mails directly to target MSAs from dynamic IP addresses.

| MSA | | | +-------+ | | | +-------+ | | | | | | | | | | | | +---------------------|-------------------+ +---------------+ | | | | | | | | +-------+ | +---+ +---+ | | | | MSA | | |MUA| |MUA| | | | +-------+ | +---+ +---+ | | | ^(f) ISP A| +-+----------+----------|-------------------+ +-----+ +---+ +-+-+ +---+ |MUA| |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> shows a spam sender strategy of pattern I. First, spam senders submit spam mails to the MSA (line labeled with (f)). Then, the submitted spam mails are delivered to MTAs of target domains (line labeled with (g)). In this scenario, the mail distribution paths are same as one via which subscribers send valid email messages. Possible countermeasure is to set a quota with user authentication.

| MSA | | | +-------+ | | | +-------+ | | | | | | | | | | | | +---------------|-------------------------+ +---------------+ | | | | | | | | | +-------+ | +---+ +---+ | | | | | MSA | | |MUA| |MUA| | | | | +-------+ | +---+ +---+ | | | | ISP A| +-+----------+----|-------------------------+ | +---+ +-+-+ +---+ |MUA| |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> Figure shows a spam sender strategy of pattern II. First, spam senders obtain dynamic IP addresses on their client PCs. Then, spam senders send spam mails directly to MTAs in target domains from the dynamic IP addresses. (lines labeled with (c) and (d)) A countermeasure for this strategy is OP25B.

In this document, we define OP25B as “filtering of the TCP traffic which the source addresses are dynamic IP addresses and the destination port is 25”. In , we explained the relation between mail distribution paths and OP25B in , , and . The alphabets “a” to “g” in the following paragraph refers to the arrows labeled with those alphabets in the above three figures. After ISP A implements OP25B, a mail sender can send email messages via MSA which ISP A serves (a, g) while they cannot send email messages via other paths (c, d). Thus subscribers of ISP A are ensured a method to send email messages via MSAs. By OP25B, operators can prevent spams sent by spam sender strategy pattern II. We define OP25B for the line labeled (d) as “OP25B bound for cellular carriers only” and OP25B for the line (c) and (d) as “complete OP25B”. OP25B is implemented by configuring access control lists (ACL) on the network devices located on the ISP backbone networks. We call the location where those network devices are located “blocking points”. Below is an example of filtering policies to filter spams from dynamic IP addresses. Allow traffic from dynamic IP addresses to port 25 of designated MSAs Deny all traffic to port 25 of MSAs other than MSAs described in 1 No filtering rules for static IP addresses This is one of the simplest filtering policies. The access control rules could differ depending on the specifications of the devices to filter or services policies of network domains. The numbers of ACL rules are calculated using this formula: (# of ACL rules) = (# of dynamic IP address blocks) * (# of MSA address blocks + 1) For example, if the number of dynamic IP address blocks is 100 and the number of MSA address blocks is 10, the number of ACL rules is 1100 = 100 * (10+1). The number of ACL rules directly influences the costs such as filter performance of the network devices and/or filter rule management of network operators. In this example, the ISP which intends to implement OP25B has to introduce network devices that have enough performance to handle 1100 ACL entries. In the model A ISPs, the number of MSA address blocks to “permit” can be increased dependent on the numbers of ISPs of model B to serve connectivity. On the other hand, the number of ACL entities are generally fewer in ISPs of model C, because they can concentrate on their internal MSAs only.

shows a blocking point analysis in a backbone network. If the blocking point get closer to the “core side”, the performance requirements for the filtering network devices increase while the number of the network devices operators have to configure comes down. On the other hand, If the blocking point get closer to the “edge side”, the performance requirements for the filtering network devices decrease while the number of the network devices operators have to configure comes up. In the case point 1 is selected as the blocking point, the filtering configurations are set to home routers in subscribers’ home networks. The advantages of this approach are: Fewer ACL rules on each network devices No spam mail traffic to the backbone network No additional configurations to the network devices in the backbone network The ISPs who can employ this method are the ISPs which can control home routers from network operations centers. In the case of point 2, the blocking point is set to the terminating devices of the access networks. The configurations are done using Radius attributes. In the case of point 3, the blocking points are the routers located between access networks and the backbone networks. This approach is expected to be most common. In the case of point 4, the network devices located near to the ISP border gateways are the blocking point. In this case, relatively small amount of the devices are engaged in filtering and huge amount of ACL rules are configured to each network devices. The performance requirements for the devices are high enough to withstand the load.

As mentioned in , currently port 25 is used for mail submissions. When the complete OP25B is employed by an ISP, the subscribers in the ISP get not to be able to send email messages in the cases below. Subscribers use other MSAs than ones located inside the ISP. In this case, the subscribers subscribe to multiple ISPs. Subscribers use the MSAs served by hosting providers or ASPs. The ISP is a model B ISP. In all the cases listed above, subscribers uses the MSAs located outside of the ISPs which they subscribe. In this document, we call this kind of submission “submissions to third-party servers”. The implementation of OP25B causes problems with submissions to third-party servers. shows this problem. The number of the arrows in is correspondent to the number in the list above.

| MTA | | | | MSA | | | | | MSA | | | +-------+ | | +-------+ | | ^(3) | | | | | | | | | +--X------------------------------X-------+ +---------------+ | | | | | | | | | | +-------+ | | +---+ +---+ | | | | | MSA | | | |MUA| |MUA| | | | | +-------+ | | +---+ +---+ | | | | | ISP A| +-+--|-------+------------------------------+ | | +-+-+ +---+ +-+-+ |MUA| |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> ISP A in the figure is an ISP of model A, and ISP B is an ISP of model B. As described in former sections, mail submissions of subscribers in ISP B are forwarded through the backbone network of ISP A to MSAs of ISP B. When ISP A implements OP25B, the path of the line (3) is blocked by the operation. Then subscribers of ISP B cannot submit to their MSAs. MUAs can use port number other than 25 for submissions to avoid this problem. As described in , MUAs can use the submission port (port 587) for submissions.

[25] MTA | | | | +-------+ | | | +-------+ | | | | | +-+---------+ | +-------------+ submission| | +-----------+ | +-----------+ | | +---------->[587]------+ | | +----|------+ | | | MSA | | | || | | +-------+ | | +++-+ | +-----------+ | |MUA| +---------------+ +---+ ]]> shows a typical SMTP server configuration for complete OP25B. In this figure, MTA receives forwarded email messages on port 25 and MSA accept submissions from MUAs on port 587. With this configuration, users can keep submitting to their MSAs using the submission port that OP25B does not affect.. We detail the use of submission port in a following section ().

If the implementation of complete OP25B requires time, ISPs SHOULD implement OP25B bound for cellular carriers only first. This operation is for the ISP operators.

shows the mail distribution path to cellular carriers from ISP A. The line (d) means the spam distribution path from dynamic IP addresses to cellular carriers. The line labeled as (e) shows the submission path from ISP subscribers to third-party servers in cellular carriers. This line (e) does not exist in the real world, because MSAs in cellular carrier networks do not accept the submissions from outside of their domain. Additionally, MTAs in the cellular carriers do not accept submissions from the Internet. For these reasons, OP25B bound for cellular carrier is easier to implement for ISPs. This quickly clears spams from their dynamic IP address blocks to cellular carriers.

Mail system operators MUST serve MSAs which support the submission port (port number 587). The operators MUST implement SMTP Auth on the MSAs. Even for the local mail distributions, the subscribers SHOULD use SMTP Auth. The POP ID/Password pairs SHOULD be identical with AUTH ID/Password of SMTP Auth. MSAs MUST NOT serve POP before SMTP. These operations are for the operators of MSAs which accept submissions from global IP addresses.

In , if the ISP A implements OP25B, the line (b) becomes a blocking target of the operation. In this case, subscribers become not to be able to keep using services they could utilize before. The ISP have to serve alternatives for the subscribers of ISP B to perform valid submissions to third-party MSAs of ISP B. One of the alternatives is the submission port (port number 587). A submission to the submission port of an MSA in ISP B is depicted as the line (b’). The operators of MSAs which are used as third-party servers MUST serve the submission port immediately after the implementation of OP25B on ISP A. Then, subscribers can send email messages by re-configuring their MUAs properly. When an MSA provides submission port, operators of the MSA MUST implement SMTP AUTH on it. In this case, the local mail distribution SHOULD be achieved via SMTP AUTH to prevent spam mails to the local domain. The POP ID/Password pairs SHOULD be identical with AUTH ID/Password of SMTP Auth. In this case, MUAs can use POP ID/Password pairs to the authentications if AUTH ID/Password pair is not configured. If SMTP AUTH is not implemented in the domain, spam sender simply switch their mail submission port from 25 to 587 and keep sending spams using the spam sender strategy pattern I as described in . After the implementation of SMTP AUTH on port 587, the operators can limit the number of email messages sent by single user ID. MSAs MUST NOT serve POP before SMTP because of its architectural defect. In the POP before SMTP architecture, POP servers store the IP addresses from which the POP authentications succeeded for certain periods, and verify mail submissions using the IP address list. That is, if the IP addresses from which the MTA receives submitted email messages are in the IP address list, the submissions are taken as valid. This IP address based authentication causes a serious security problem. Suppose a client which has successfully succeeded the POP authentication leaves the network. If a malicious node obtains the same IP address while the POP server still hold the IP address in the valid IP address list, the malicious node can send spams freely. When the valid IP addresses are the global addresses of the NAT routers, the situation gets worse. In the case multiple MUAs behind a NAT router utilizes a same MSA located on the WAN side and a client PC which runs MUA get infected by a bot, the bot can send email messages via the MSA after an MUA on another PC has done the POP authentication for the MSA. If the healthy PC is configured to do the POP authentications periodically, it effectively cancels POP before SMTP authentication from the LAN behind the NAT router.

For mail submissions, MUAs MUST utilize MSAs which support both of the submission port(port 587) and SMTP Auth. The mail system operators MUST abolish the use of MSAs which utilize the port 25. The operators MUST deny submissions to MTAs. This operation is for the operators of MSAs which accept the submissions from global IP addresses. As mentioned in , the mail quota using SMTP AUTH is workable against the spam senders’ strategy pattern I. For this operation, all the mail submissions must be done with SMTP AUTH. While ISPs of model C do not need to sweep away the MSAs with port 25 and MTAs after all the submissions are completely done with SMTP Auth, the ISPs SHOULD migrate to port 587 for the users’ convenience if deployments of SMTP AUTH are still not be completed. The operation in the model C ISP is described in the following section(). For the completion of this operation, all the subscribers have to change the configurations of their MUAs. ISPs MUST encourage their subscribers to change the configurations of their MUAs. Proposed migration steps are: Operators of mail systems prepare MSA(s)[587+Auth] other than MTA/MSA[25]. For new subscribers, prepare the guidance of MSA[587+Auth] only. For subscribers who need to change the configuration of MTAs on their MUAs (for example, users who want to change their mail addresses), show them a configuration guideline of MSA[587+Auth] only. encourage all other subscribers to change their MUA configurations to MSA[587+Auth] The focuses or problems of the complete migration vary by the ISP models and network configurations. We explain the focuses and problems for 3 models below in the following sections. ISP of model C ISP of model A and B providers which cannot identify submission sources (ex) ASP) Essentially, the categorization of the ISPs (model A, B and C) is not the categorization of the ISPs themselves but of the services which the ISPs provide for their subscribers. (An ISP can provide one service categorized as model A and another service of model B simultaneously) For simplicity, we use the above categorization over ISPs themselves in the following sections.

Operators of model C ISPs are able to implement OP25B while their MSAs and MTAs keep accepting submissions for port 25. This is because their OP25B implementations do not influence on mail services on other ISPs. Therefore, the operations described in are not required in IPSs of model C.

Operators of model B ISPs SHOULD cooperate with operators of model A ISPs. Operators of model A ISPs SHOULD accept the requests from model B ISPs. Operators of model A ISPs MUST keep their mail distribution paths for MSA[25] and MTA[25] until all the subscribers of model B ISPs complete the migrations to MSA[587+Auth].

[25] MTA | | | | MSA | | | | MSA | | | +-------+ | | +-------+ | | [25][587 auth] | | | ^ ^ | | | | +--X-----|--------------------------------+ +---------------+ | | | | | | | | | | | +-------+ | +---+ +---+ | | |(b) | (b') | MSA | | |MUA| |MUA| | | | | | +-------+ | +---+ +---+ | | | | | ISP A| +-+--|-----|-+----+-----------------+-------+ | | | | +-+-+ | +-+-+ +-+-+ |MUA+---+ |MUA| bot(zombie) |MUA| +---+ +---+ spam sender +---+ ]]> In , after ISP A implements OP25B, the subscribers in ISP B become not to be able to submit to their MTAs[25] and MSAs[25] (line (b)). Because ISP B does not have own backbone network and IP address blocks for subscribers, ISP B depends the implementation of OP25B on ISP A. Therefore, ISP A and ISP B have to cooperate with the implementation of OP25B. Before the implementation of OP25B, ISP A and ISP B MUST choose one of the operations below. ISP A permit the mail submissions from MUAs in ISP B to MSA[25] or MTA[25] of ISP B. Subscribers of ISP B “completely” migrate SMTP server configurations of their MUAs to MSA[587+Auth] If ISP A and ISP B choose 1, the ACL problems arise in ISP A as described in . Regarding to the choice 2, the implementation of OP25B will be delayed. Below is a practical procedure of the OP25B implementation of ISP A and ISP B. ISP B aggregates the address blocks for MSAs as few as possible. ISP A permits submissions from subscribers of ISP B to MSAs[25] or MTA[25]. ISP A implements OP25B. Subscribers of ISP B migrates SMTP server configurations of their MUAs to MSA[587+Auth]. ISP B stops to accept submissions to MSA[25] or MTA[25]. The transition period is desirable to be as short as possible.

Providers which cannot identify submission sources MUST migrate to MSA[587+Auth] immediately. This operations is for the operators of MSAs which accept submissions from global IP addresses (especially for the operators of ASP or hosting companies).

Providers which provide ASP services or hosting services cannot identify which ISP their users submit their email messages from. Such is the case with companies or academic institutions which allow submissions from the Internet. These providers MUST setup MSA[587+Auth] immediately and encourage their users to change their MUA configurations. Because it requires time to implement SMTP AUTH, it is expected that these provides need to utilize POP before SMTP on the submission port as a temporary solution. Even in this case, as described in , the use of POP before SMTP is not recommended. It MUST be migrated to SMTP Auth as soon as possible.

In the case implementations of OP25B proceed, spam senders are expected to subscribe to the target ISP and send spams to the MTAs on the local domain. For this problem, ISPs SHOULD block the traffic from dynamic IP addresses of their IP address blocks to port 25 of MTAs. For this purpose, MSA and MTA have to obtain separated port numbers or separated IP addresses.

TCP traffic which the source IP addresses are dynamic IP addresses and the destination port is 25 MUST be blocked. Operators SHOULD implement some countermeasure for asymmetric routing attack and triangular spamming. These operations are for the operators of ISPs. As OP25B blocks the email messages directly submitted to MTAs (not via MSAs), spam senders cannot send spam mails to the target directly after the implementations of OP25B. At the same time, valid users can keep sending email messages via submission port. How to implement OP25B is shown in . In this section, we explain two notes while implementing OP25B. We defined OP25B as “filtering of the TCP traffic which the source addresses are dynamic IP addresses and the destination ports are 25” in a former section (). Even after the implementations of OP25B, it is known that the spam senders keep sending spam mails using some characteristics of IP communications. This attack is called “asymmetric routing attack”. illustrates the asymmetric routing attack. First, the spam sender obtains two IP addresses, a static address and a dynamic IP address. The spam sender send spam mails which the source address is dynamic IP address via the network interface which has static IP address. Thus, the spam mails are transferred through the static IP address segment. If ACL for OP25b is not set on the gateway of the static IP address segment, the junk mails sent by the sender will be submitted to the target MSAs. The target MSA sends TCP responses to the dynamic IP address of the spam sender and the TCP connections from the spam sender to the target MSA are established.

“Triangular spamming” is a more generalized attack. Triangular spamming enables spam senders to bypass OP25B utilizing relaying nodes. illustrates triangular spamming. First, a spam sender sends IP packets which the source address is IP address of the spam relay node and the destination is the target MSA. As the source addresses are not the dynamic IP addresses of ISP1, the packets pass the ACL(s) of ISP1. The target MSA send responses which the destination is the spam relay node. The spam relay node forwards the packets modifying the destination IP address to the address of the original spam sender. This forwarded packets will be received by the spam sender not being blocked, because the in-bound ACLs are not configured in ISP1. Thus OP25B can be bypassed by triangular spamming.

Countermeasures for these attacks are shown below. Out of all the mail traffic from backbone networks to dynamic IP addresses, only the traffic which is from port 25 of designated MSAs are permitted. (traffic from “other MSAs” are blocked) Prevent source address spoofing of the traffic from static or dynamic addresses to the backbone networks by source address validation. For asymmetric routing attack and triangular spamming, the adoption of source address validation (item 2) is more desirable than inbound ACL (item 1). However, as the implementations of source address validation are burdens in many cases, at least the operators SHOULD employ the inbound ACL (item 1) until source address validation is ready on the domain.

Operators SHOULD provide third-party alternative MSAs. This operation is for the operators of ISPs. To explain the need for alternative MSAs, we illustrate a mail user disrupted by OP25B. User A is a subscriber of ISP A. ISP A does not allow relays other than that for the email messages which the MAIL FROM field is within its own domain. The user has another mail address “foo@example.com” than that of ISP A. The MSA of “example.com” is located outside of ISP A and does not provide submission port. The user cannot configure different FROM between Envelop and Header on her/his MUA. If the ISP A implements OP25B in this situation, the illustrated user gets to lose MSA and is not able to submit email messages. In this case, ISPs SHOULD provide the MSA[587+Auth] which users can configure their MAIL FROM field freely. This operation is not only for the users subscribed to ISPs themselves but for the providers which still have not implemented MSA[587+Auth].

Operators SHOULD implement mail quota on MSAs utilizing SMTP AUTH. The number of the email messages SHOULD be counted by “RCPT TO”. After the implementations of OP25B and submission port, the only way mail senders submit their email messages is to use MSA[587+Auth] if the senders are using dynamic IP addresses. The way spam senders try to send junk mails via MSA[587+Auth] resembles to the spam sender strategy pattern I described in . As MSAs[587+Auth] can figure out the number of email messages sent from single user ID, operators SHOULD implement the mail quota using these mail sent counts. Operators have to decide the limit rate carefully not to influence on the mail deliveries of users other than the spam senders. The number of outgoing email messages SHOULD be measured sorely by “RCPT TO”. In , the minimum total number of recipients is defined as 100. If the maximum number of the MAIL FROM is also limited to 100, mail senders can send 10,000 email messages(“MAIL FROM” * “RCPT TO”) from single MUA. If the number is measured by “MAIL FROM” and not considering “RCPT TO”, the combination tends to allow huge amount of outgoing email messages for each spam sender.

TBD

Operators MUST configure to permit tcp 587 traffic to the Internet if MSAs which users have to communicate with are outside of their LANs. In this section, we describe the problems with OP25B other than the problems related to submissions to third-party servers. After the implementations of OP25B, there are cases caused by the ACL configurations on routers or firewalls. For example, MUAs cannot submit email messages in the case “some companies or academic institutions are using dynamic IP addresses and rely the capability of MSAs on ASP or hosting providers, and the submission port (587) is blocked”. In this case, operators of the routers and firewalls MUST permit the traffic to submission port (587). In the case of proxies, the situation is the same. Proxies MUST forward the mail traffic to submission port (587).

MTAs utilizing dynamic IP addresses SHOULD obtain static addresses. If there is an SMTP server which obtain a dynamic IP address and resolves MX records to forward email messages directly to the destination MTAs, these forwarded traffic are blocked by OP25B configurations. Below are examples of this case. The case the MTA is using dynamic IP address(es) and dynamic DNS. The case send-only SMTP servers have dynamic IP addresses only. In these cases, operators of the servers SHOULD obtain static IP addresses.