| Applications Area Working Group | T. Akagiri |
| Internet-Draft | Rakuten, Inc. |
| Intended status: Informational | K. Wakamatsu |
| Expires: September 10, 2015 | SoftBank Mobile Corp. |
| K. Okada | |
| K. Maeda | |
| Lepidum Co. Ltd. | |
| March 09, 2015 |
Outbound Port 25 Blocking for Dynamic IP Addresses
draft-akagiri-op25b-dynamicip-00.txt
Outbound Port 25 Blocking has been widely used over a decade as a countermeasure against mail spams. It is the operation to filter TCP traffic which (1) the source IP addresses are dynamic IP addresses and (2) the destination port is 25. Since ordinal mail message submissions from dynamic IP addresses can be done via submission port (port number 587), operators can introduce the blocking without preventing ordinal mail message submissions. We explain current OP25B operations in this document.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Countermeasures for spam mails are categorized into two types, “to block sending spam mails” and “not to receive spam mails”. Outbound Port 25 Blocking (OP25B) is one of the former approaches. Blocking a spam mail inside the spam origin domain is more desirable as the spam distributed domain is limited to one domain.
The way spam senders send spam mails are categorized into three types.
OP25B prevents approach 1. By introducing OP25B, network operators can focus on actions against spam mails from static addresses.
At the time OP25B was first introduced, there were two issues that we needed to consider. Submission port (port number 587) was not yet fully adopted, and the number of filtering rules hit performance of network routers. These have been solved these days, enabling easier OP25B deployment. While OP25B becomes widespread in this decade, this document summarize current OP25B practices to help newly introducing the blocking.
Figure 1 and Figure 2 are the typical pattern diagrams of mail components. Figure 1 is the diagram which single server doubles as MSA and MTA. Figure 2 is the diagram which MSA and MTA are separated.
+-------------+ +---------------+
| | forwarding| +-----------+ |
| +-------+ +-------------------> | +-------+ | |
| | MTA | | +----------> | | MTA | | |
| +-------+ | |submission| | +-------+ | |
| | | | +-+-------+-+ |
+-------------+ | | mail server |
+----|------+ | |
| | | +---------------+
+----|+-----+
||
+++-+
|MUA|
+---+
Figure 1: Single server model
In Figure 1, single SMTP server utilizes port 25 both for submissions and forwarding, that is, MSA and MTA cannot be distinguished. In this document, submissions to this kind of SMTP servers are called “submissions to MTA”. In Figure 2, different SMTP servers engage in submissions and forwarding respectively, that is, MSA and MTA can be distinguished. In this document, SMTP servers which serve port 25 for mail submissions are called MSA[25].
+-------------+ +-+-----------+-+
| | forwarding| +-----------+ |
| +-------+ +-------------------> | +-------+ | |
| | MTA | | | | | MTA | | |
| +-------+ | | | +-------+ | |
| | | +-+---------+ |
+-------------+ submission| mail server |
+-----------+ | +-+---------+ |
| +----------> | +-------+ | |
+----|------+ | | | MSA | | |
|| | | +-------+ | |
+++-+ | +-+-------+-+ |
|MUA| | mail server |
+---+ +---------------+
Figure 2: Separate server model
In this document, we categorize ISPs into 3 types:
Figure 3 shows how end clients are connected to the Internet through 3 types of ISPs.
+----------------------+
|Internet |
| +-----+ ^ ^ ^ |
MSA of model B ISP+--------+ MSA | <--+ | | |
| +-----+ | | | |
+-------------------------------+ | | |
| | +---------------+ | |
| +--|-----------------|-+
| | +-----------------+
| | |
+-+-----------------|--+ +--------------------|-+
|model A ISP | | |model C ISP | |
| |(B) (A)| | | (C)| |
| | +-----+ | | | +-----+ | |
| | | MSA | <---+ | | | MSA | <-+ |
| | +-----+ | | | +-----+ | |
| | | | | | |
+-|------+---+------|--+ +--------------------|-+
+-|------+ +------|--+ +--------------------|-+
| | | | | | Access | | |
+-|------+ +------|--+ Network +--------------------|-+
| | |
+-+-+ +-+-+ +-+-+
|MUA| |MUA| |MUA|
+---+ +---+ +---+
subscriber of subscriber of subscriber of
model B ISP model A ISP model C ISP
Figure 3: ISP models
All subscribers of ISPs of model A and model C are connected to the Internet via ISPs to which they subscribe. In Figure 3, 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.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| (b)^ | | (e)^ |
+-----------|------------+ +-----------------|------+
+------------+ +----------+- - - - - - - - - - - +
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA | | | (b) | | MTA | |
| | MSA | | +--------------> | MSA | |
| +-------+ | | | +-------+ |
| ^ | | | ^ |
| | | | | |(b) |
| +---------------------------------|-------+ +---------------+
| | | | | | |
| | | | +-------+ | | +-+-+ +---+
| | |(b) | | MSA | | | |MUA| |MUA|
| | | | +-------+ | | +---+ +---+
| | | | ^(a) | ISP A|
+-+----------+-------------|--------|-------+
| +--------|
+-+-+ +---+ +-+-+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 4: Valid Mail Submission
Figure 4 shows valid mail submissions by ISP subscribers. These submissions MUST NOT be disrupted by OP25B.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +------+-------+ | | +---+---+ +-------+ |
| (c)^ | | (d)^ |
+----+------|------------+ +------|-----------------+
+------------+ +------+----------------------+
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA | (c) | (c) | MTA | |
| | MSA | <----+--------------------------------> | MSA | |
| +-------+ | | | +-------+ |
| | | | |
| | | | |
| +---------------|-------------------------+ +---------------+
| | | | |
| | | | +-------+ | +---+ +---+
| | | | | MSA | | |MUA| |MUA|
| | | | +-------+ | +---+ +---+
| | | | ^(f) ISP A|
+-+----------+----|-----|-------------------+
| +---+
+---+ +-+-+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 5
Figure 5 shows invalid mail submissions by spam senders or bots. These submissions are the block target of OP25B.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| (g)^ | | (g)^ |
+----------|-------------+ +------|-----------------+
+------------+ +-----------------------+
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA | (g) | (g) | MTA | |
| | MSA | <----------+--------------------------> | MSA | |
| +-------+ | | | +-------+ |
| | | | |
| | | | |
| +---------------------|-------------------+ +---------------+
| | | | |
| | | +-------+ | +---+ +---+
| | | | MSA | | |MUA| |MUA|
| | | +-------+ | +---+ +---+
| | | ISP A|
+-+----------+------------------------------+
+---+ +---+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 6: Valid Mail Forwarding
Figure 6 shows valid mail forwarding between MSAs and MTAs. The forwarding MUST NOT be disrupted by OP25B.
Spam senders’ strategies can be categorized into two patterns:
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| (g)^ | | (g)^ |
+----------|-------------+ +------|-----------------+
+------------+ +-----------------------+
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA | (g) | (g) | MTA | |
| | MSA | <----------+--------------------------> | MSA | |
| +-------+ | | | +-------+ |
| | | | |
| | | | |
| +---------------------|-------------------+ +---------------+
| | | | |
| | | +-------+ | +---+ +---+
| | | | MSA | | |MUA| |MUA|
| | | +-------+ | +---+ +---+
| | | ^(f) ISP A|
+-+----------+----------|-------------------+
+-----+
+---+ +-+-+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 7: Spam sender strategy: Pattern I
Figure 7 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.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +------+-------+ | | +---+---+ +-------+ |
| (c)^ | | (d)^ |
+-----------|------------+ +------|-----------------+
+------------+ +------+----------------------+
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA | (c) | (c) | MTA | |
| | MSA | <----+--------------------------------> | MSA | |
| +-------+ | | | +-------+ |
| | | | |
| | | | |
| +---------------|-------------------------+ +---------------+
| | | | |
| | | | +-------+ | +---+ +---+
| | | | | MSA | | |MUA| |MUA|
| | | | +-------+ | +---+ +---+
| | | | ISP A|
+-+----------+----|-------------------------+
|
+---+ +-+-+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 8: Spam sender strategy: Pattern II
Figure Figure 8 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 Section 3.2, we explained the relation between mail distribution paths and OP25B in Figure 4, Figure 5, and Figure 6. 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.
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.
+--------------------------------+ Core Side
|The Internet | ^
| | |
+------+-------------------------+ |
| |
+--+---+ +-+ [Point 4] |
+---+Router+---------------------+ | Core side of backbone |
| +------+ | +-+ |
|Bacbone Network | |
|(Core Network) | |
| | |
+-------+-----------------+------+ |
| | |
+---+--+ +---+--+ +-+ [Point 3] |
+---+Router+---+ +---+Router+---+ | Edge side of backbone |
| +------+ | | +------+ | +-+ |
| Access | | Access | |
| Network | | Network | |
|+---+ +---+| |+---+ +---+| +-+ [Point 2] |
+|OLT|----|OLT|+ +|OLT|----|OLT|+ | OLT, Terminator |
+-+-+ +-+-+ +-+-+ +-+-+ +-+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +-+ [Point 1] |
|modem| |modem| |modem| |modem| | Home router |
+--+--+ +--+--+ +--+--+ +--+--+ +-+ |
| | | | |
+-+-+ +-+-+ +-+-+ +-+-+ |
|MUA| |MUA| |MUA| |MUA| |
+---+ +---+ +---+ +---+ Edge Side
Figure 9: Blocking point analysis
Figure 9 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:
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 Section 2, 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.
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. Figure 10 shows this problem. The number of the arrows in Figure 10 is correspondent to the number in the list above.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| ^ | | |
+--------|---------------+ +------------------------+
+------------+ + - - - - - - +
| ISP B| (2) | +---------------+
| | | ISP C|
| +-------+ | | (1) | +-------+ |
| | MTA | | - - - - - - | >| MTA | |
| | MSA | | | | | MSA | |
| +-------+ | | +-------+ |
| ^(3) | | | |
| | | |
| +--X------------------------------X-------+ +---------------+
| | | | | |
| | | | +-------+ | | +---+ +---+
| | | | | MSA | | | |MUA| |MUA|
| | | | +-------+ | | +---+ +---+
| | | | | ISP A|
+-+--|-------+------------------------------+
| |
+-+-+ +---+ +-+-+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 10: Problem with complete OP25B
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 [RFC6409], MUAs can use the submission port (port 587) for submissions.
+-------------+ +-+-----------+-+
| | | +-----------+ |
| +-------+ | forwarding| | +-------+ | |
| | MTA | +------------------->[25] MTA | | |
| +-------+ | | | +-------+ | |
| | | +-+---------+ |
+-------------+ submission| |
+-----------+ | +-----------+ |
| +---------->[587]------+ | |
+----|------+ | | | MSA | | |
|| | | +-------+ | |
+++-+ | +-----------+ |
|MUA| +---------------+
+---+
Figure 11: Complete OP25B with submission port
Figure 11 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 (Section 4.2.2).
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| | | ^ ^ ^ |
+------------------------+ +----|-|----------|------+
+------------+ + - - - - - - - - - - - - - + |
| ISP B| | +-----------------------+ |
| | |
| +-------+ | (d)| | + - - - - - - - - - - -+
| | MTA | | |
| | MSA | | | | (e)|
| +-------+ | |
| | | | |
| | |
| +---------------X-----|-----------+-------+
| | | | | | |
| | | | +-------+ |
| | | | | MSA | | |
| | | | +-------+ |
| | | | ^ | ISP A|
+-+----------+----------|-------------------+
| +-----------+
+---+ +-+-+ +-+-+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 12: OP25B bound for cellular carriers only
Figure 12 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.
+------------+ ^
| ISP B| |
| |
| +-------+ | |
| | MTA | |
| | MSA | | |
| +-------+ |
| [25][587+auth] |
| ^ ^ |
| +--|-----|------X-------------------------+
| | | | | | |
| | | | | | +-------+ |
| | |(b) | (b') | | MSA | |
| | | | | | +-------+ |
| | | | | | ISP A|
+-+--|-----|-+----|-------------------------+
| | | |
+-+-+ | +-+-+ +-+-+
|MUA+---+ |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 13: OP25B with submission port
In Figure 13, 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 Section 3.3. 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.
As mentioned in Section 3.3, 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(Section 4.3.1).
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:
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.
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 Section 4.3 are not required in IPSs of model C.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +-------+-------+ | | +-------+ +-------+ |
| | MSA | MTA | | | | MTA | | MSA | |
| +-------+-------+ | | +-------+ +-------+ |
| [25] | | [25] |
+---------------^--------+ +----^-------------------+
+------------+ | |
| ISP B| | | +---------------+
| | | | | ISP C|
| +--------+ | | | | +--------+ |
| | MTA [25]<----------------+----------------+-----| MTA | |
| | MSA | | | [25]MSA | |
| +--------+ | | +-^------+ |
| | | | |
| | | | |
| +-----------------------------------------+ +---------------+
| | | | |
| | | +-------+ | +-+-+ +---+
| | | | MSA | | |MUA| |MUA|
| | | +-------+ | +---+ +---+
| | | ISP A|
+-+----------+------------------------------+
+---+ +---+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 14: Mail distribution path after OP25B in ISPs of model C
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +-------+-------+ | | +-------+ +-------+ |
| | MSA | MTA | | | | MTA | | MSA | |
| +-------+-------+ | | +-------+ +-------+ |
| [25] | | [25] |
+---------------^--------+ +----^-------------------+
+------------+ | |
| ISP B| | | +---------------+
| | | | | ISP C|
| +-------+ | | | | +-------+ |
| | MTA +-----------------+----------------+-->[25] MTA | |
| | MSA | | | | MSA | |
| +-------+ | | +-------+ |
| [25][587 auth] | |
| ^ ^ | | |
| +--X-----|--------------------------------+ +---------------+
| | | | | |
| | | | | +-------+ | +---+ +---+
| | |(b) | (b') | MSA | | |MUA| |MUA|
| | | | | +-------+ | +---+ +---+
| | | | | ISP A|
+-+--|-----|-+----+-----------------+-------+
| | | |
+-+-+ | +-+-+ +-+-+
|MUA+---+ |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 15: Mail distribution path of model B ISP
In Figure 15, 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.
If ISP A and ISP B choose 1, the ACL problems arise in ISP A as described in Section 4. 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.
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).
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +-------+-------+ | | +-------+ +-------+ |
| | MSA | MTA | | | | MTA | | MSA | |
| +-------+-------+ | | +-------+ +-------+ |
| [587+auth][25] | | |
+----------^----^--------+ +---- -------------------+
+------------+ | |
| ISP B| | | +---------------+
| | | | | ISP C|
| +-------+ | | | | +-------+ |
| | MTA +----------+------+-------------------+ | MTA | |
| | MSA | | | | | | MSA | |
| +-------+ | | +---------+ | +-------+ |
| | | | | |
| | | | | |
| +-------------------|---------------------+ +---------------+
| | | | | |
| | | +-+-----+ | | +---+ +---+
| | | | MSA | | | |MUA| |MUA|
| | | +-------+ | | +---+ +---+
| | | [587+auth] | ISP A|
+-+----------+----+-----^---------|-+-------+
| +---------+ |
+---+ +-+-+ +-+-+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 16: Mail distribution path after OP25B in ASP of Hosting Providers
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 Section 4.2.2, 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.
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 Section 4. 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 (Section 4). 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”.
Figure 17 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.
+-------+
| MSA |
++------+
| ^
| |
| |
| |
v |
+-----+-+ ++-----+
|dynamic+--+static|
+-------+ +------+
| |
| spam sender |
| |
+---------------+
Figure 17: Asymmetric routing attack
“Triangular spamming”[Triangular] is a more generalized attack. Triangular spamming enables spam senders to bypass OP25B utilizing relaying nodes. Figure 18 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.
+----------------------+
|Internet |
| +-----+ |
+------------+ MSA |<-----------+
| | +-----+ | |
| | | |
| | | |
| +----------------------+ |
| |
| |
+-----------|----------+ +---------|------------+
|ISP2 | | |ISP1 | |
| | | | | |
| | +---------------------------+ | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+-----------|-|--------+ +-------|-|------------+
v | v |
+-------+--+ +-+-+
|Spam Relay| |MUA|spam sender
+----------+ +---+
Figure 18: Triangular spamming
Countermeasures for these attacks are shown below.
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.
This operation is for the operators of ISPs.
To explain the need for alternative MSAs, we illustrate a mail user disrupted by OP25B.
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 Section 3.1. 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 [RFC5321], 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
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).
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.
In these cases, operators of the servers SHOULD obtain static IP addresses.
After the implementation of OP25B, the mail distribution paths from ISP A are reformed as three figures below (Figure 19, Figure 20, Figure 21).
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| [587+Auth] [25] | | [25] |
+--------^---------------+ +------------------------+
+------------+ |
| ISP B| | +---------------+
| | | | ISP C|
| +-------+ | | | +-------+ |
| | MTA |[25] | [25]| MTA | |
| | MSA | | +-------------+----->[587+Auth]| MSA | |
| +-------+ | | | ^+-------+ |
| [587+Auth]| | | | |
| ^ | | | | |
| +--|------------------------------|-------+ +-|-------------+
| | | | | | +-+
| | | | +-------+ | | +-+-+ +---+
| | | | | MSA | | | |MUA| |MUA|
| | | | +-------+ | | +---+ +---+
| | | | [587+Auth] | ISP A|
+-+--|-------+--------^-------------|-------+
| +-------------+
+---+ +---+ +-+-+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 19: Valid mail submission after OP25B
Figure 19 depicts the valid mail submissions from MUA in ISP A. All the email messages are submitted to port 587 of MSAs. Even for the local domain submissions, MUA SHOULD use the submission port(587).
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| [587+Auth] [25] | | [25] |
+-----------------^------+ +---^--------------------+
+------------+ | |
| ISP B| | | +---------------+
| | | | | ISP C|
| +-------+ | | | | +-------+ |
| | MTA |[25]<-------+------+-------------+-->[25]| MTA | |
| | MSA | | | [587+Auth]| MSA | |
| +-------+ | | | +-------+ |
| [587+Auth]| | | |
| | | | |
| +---------------------|-------------------+ +---------------+
| | | | |
| | | +---+---+ | +---+ +---+
| | | | MSA | | |MUA| |MUA|
| | | +-------+ | +---+ +---+
| | | [587+Auth] ISP A|
+-+----------+------------------------------+
+---+ +---+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 20: Valid mail forwarding after OP25B
MSAs in ISP A forward submitted email messages to port 25 of MTAs outside of ISP A. Because MSAs are allocated static IP addresses, the ACL rules of OP25B do not match the traffic.
+------------------------+ +------------------------+
|ASP/Hosting/ | |Cellular carrier |
|Business Enterprise/ | | |
|Academic institution | | |
| +--------------+ | | +-------+ +-------+ |
| | MSA/MTA | | | | MTA | | MSA | |
| +--------------+ | | +-------+ +-------+ |
| [587+Auth] [25] | | [25] |
+-----------------^------+ +---^--------------------+
+------------+
| ISP B| | | +---------------+
| | | ISP C|
| +-------+ | | | | +-------+ |
| | MTA |[25]< + - - - - - - - - - - - - - - >[25]| MTA | |
| | MSA | | [587+Auth]| MSA | |
| +-------+ | | | +-------+ |
| [587+Auth]| | |
| | | | |
| +---------------X-------------------------+ +---------------+
| | | | |
| | | | +-------+ | +---+ +---+
| | | | | MSA | | |MUA| |MUA|
| | | | +-------+ | +---+ +---+
| | | | [587+Auth] ISP A|
+-+----------+----|-------------------------+
|
+---+ +-+-+ +---+
|MUA| |MUA| bot(zombie) |MUA|
+---+ +---+ spam sender +---+
Figure 21: Invalid mail submission after OP25B
All the submissions from dynamic IP addresses to port 25 of MSAs outside of ISP A are blocked by ACL rules of OP25B.
The author would like to thank Rodney Van Meter for his good contributions to this memo.
| [RFC5321] | Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. |
| [RFC5322] | Resnick, P., "Internet Message Format", RFC 5322, October 2008. |
| [RFC5598] | Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. |
| [RFC6409] | Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011. |
| [Triangular] | Qian, Z., "Investigation of Triangular Spamming a Stealthy and Efficient Spamming Technique", In proceedings of IEEE Symposium on Security and Privacy (Oakland) 2010 , May 2010. |