[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Applications Area Working Group                               T. Akagiri
Internet-Draft                                              Regumi, Inc.
Intended status: Informational                              K. Wakamatsu
Expires: January 28, 2018                          SoftBank Mobile Corp.
                                                             G. Yasutaka
                                                           Rakuten, Inc.
                                                                K. Okada
                                                        Lepidum Co. Ltd.
                                                           July 27, 2017


           Outbound Port 25 Blocking for Dynamic IP Addresses
                  draft-akagiri-op25b-dynamicip-01.txt

Abstract

   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.

Status of This Memo

   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 January 28, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Akagiri, et al.         Expires January 28, 2018                [Page 1]


Internet-Draft                    OP25B                        July 2017


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Mail Distribution Models  . . . . . . . . . . . . . . . . . .   4
     3.1.  ISP models  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Mail distribution path  . . . . . . . . . . . . . . . . .   6
     3.3.  Spam sender strategies and countermeasures  . . . . . . .   9
   4.  Outbound Port 25 Blocking . . . . . . . . . . . . . . . . . .  11
     4.1.  Deployment Considerations . . . . . . . . . . . . . . . .  14
     4.2.  Submission port (587) . . . . . . . . . . . . . . . . . .  16
     4.3.  Complete migration to submission port(587)  . . . . . . .  18
       4.3.1.  ISP of model C  . . . . . . . . . . . . . . . . . . .  19
       4.3.2.  ISP of model A and B  . . . . . . . . . . . . . . . .  20
       4.3.3.  Providers which cannot identify submission sources  .  22
       4.3.4.  Related item  . . . . . . . . . . . . . . . . . . . .  24
     4.4.  Considerations  . . . . . . . . . . . . . . . . . . . . .  24
       4.4.1.  Attacks against OP25B . . . . . . . . . . . . . . . .  24
       4.4.2.  Alternative MSA . . . . . . . . . . . . . . . . . . .  26
       4.4.3.  Mail quota  . . . . . . . . . . . . . . . . . . . . .  27
       4.4.4.  IPv6 Consideration  . . . . . . . . . . . . . . . . .  28
       4.4.5.  ACL rules to permit submission port . . . . . . . . .  28
       4.4.6.  MTAs with dynamic IP addresses  . . . . . . . . . . .  28
   5.  The goal of this document . . . . . . . . . . . . . . . . . .  28
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   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.




Akagiri, et al.         Expires January 28, 2018                [Page 2]


Internet-Draft                    OP25B                        July 2017


   The way spam senders send spam mails are categorized into three
   types.

   1.  Spam senders refer MX RR from dynamic IP addresses to send spam
       mails directly to target MTAs.

   2.  Spam senders send spams via webmail MSAs.

   3.  Spam senders obtain static IP addresses to send spam mails.

   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.

2.  Terminology

   o  Mail User Agent(MUA): user application which submit email messages
      to MSA

   o  Mail Submission Agent(MSA): program which receive submitted email
      messages from MUA and forward them

   o  Mail Transfer Agent(MTA): programs which receive forwarded email
      messages from MSA or MTA and forward them

   o  submit: The action by the MUA of entrusting the deliveries of
      email messages to MSA

   o  forward: actions which MTA(or MSA) entrust the deliveries of email
      messages to other MTAs

   o  subscriber: User who establishes account(s) with some ISP(s) to
      obtain Internet connectivity

   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.






Akagiri, et al.         Expires January 28, 2018                [Page 3]


Internet-Draft                    OP25B                        July 2017


   +-------------+                  +---------------+
   |             |        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

3.  Mail Distribution Models








Akagiri, et al.         Expires January 28, 2018                [Page 4]


Internet-Draft                    OP25B                        July 2017


3.1.  ISP models

   In this document, we categorize ISPs into 3 types:

   1.  ISP model A: ISP that provides Internet connectivity services to
       other ISPs (model B)

   2.  ISP model B: ISP that depends on end-user Internet connectivity
       on other ISPs (model A)

   3.  ISP model C: ISP that utilize their internet connectivity for
       their own services only.

   Figure 3 shows how end clients are connected to the Internet through
   3 types of ISPs.

   o  (A): the Internet connectivity for subscribers of ISPs of model A

   o  (B): the Internet connectivity for subscribers of ISPs of model B

   o  (C): the Internet connectivity for subscribers of ISPs of model C






























Akagiri, et al.         Expires January 28, 2018                [Page 5]


Internet-Draft                    OP25B                        July 2017


                        +----------------------+
                        |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.2.  Mail distribution path

   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 and "ASP/Hosting/Business Enterprise/
   Academic institution" are mail receivers.




Akagiri, et al.         Expires January 28, 2018                [Page 6]


Internet-Draft                    OP25B                        July 2017


   o  ISP A: ISP of model A

   o  ISP B: ISP of model B

   o  ISP C: ISP of model C

   o  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

                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |        (b)^            |
                +-----------|------------+
   +------------+           +----------+
   |       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




Akagiri, et al.         Expires January 28, 2018                [Page 7]


Internet-Draft                    OP25B                        July 2017


   Figure 4 shows valid mail submissions by ISP subscribers.  These
   submissions MUST NOT be disrupted by OP25B.

   o  (a): submissions from MUA to MSA of ISP A

   o  (b): submissions from MUA to MSA located outside of ISP A

                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +------+-------+    |
                |        (c)^            |
                +----+------|------------+
   +------------+    +------+
   |       ISP B|    |                               +---------------+
   |            |    |                               |          ISP C|
   |  +-------+ |    |                               |  +-------+    |
   |  |  MTA  | (c)  |                              (c) |  MTA  |    |
   |  |  MSA  | <----+--------------------------------> |  MSA  |    |
   |  +-------+ |    |                               |  +-------+    |
   |            |    |                               |               |
   |            |    |                               |               |
   | +---------------|-------------------------+     +---------------+
   | |          |    |                         |
   | |          |    | +-------+               |       +---+    +---+
   | |          |    | |  MSA  |               |       |MUA|    |MUA|
   | |          |    | +-------+               |       +---+    +---+
   | |          |    |     ^(d)           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.

   o  (c): submissions from spam senders or bots to MTAs located outside
      of ISP A

   o  (d): submissions from spam senders or bots to MSAs of ISP A





Akagiri, et al.         Expires January 28, 2018                [Page 8]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |       (e)^             |
                +----------|-------------+
   +------------+          |
   |       ISP B|          |                         +---------------+
   |            |          |                         |          ISP C|
   |  +-------+ |          |                         |  +-------+    |
   |  |  MTA  | (e)        |                        (e) |  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.

   o  (e): mail deliveries between MTAs or deliveries from MSAs to MTAs

3.3.  Spam sender strategies and countermeasures

   Spam senders' strategies can be categorized into two patterns:

   1.  Pattern I: submit spam mails to MSA and let the MSA to distribute
       them.

   2.  Pattern II: submit spam mails directly to target MSAs from
       dynamic IP addresses.





Akagiri, et al.         Expires January 28, 2018                [Page 9]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |       (e)^             |
                +----------|-------------+
   +------------+          |
   |       ISP B|          |                         +---------------+
   |            |          |                         |          ISP C|
   |  +-------+ |          |                         |  +-------+    |
   |  |  MTA  | (e)        |                        (e) |  MTA  |    |
   |  |  MSA  | <----------+--------------------------> |  MSA  |    |
   |  +-------+ |          |                         |  +-------+    |
   |            |          |                         |               |
   |            |          |                         |               |
   | +---------------------|-------------------+     +---------------+
   | |          |          |                   |
   | |          |      +-------+               |       +---+    +---+
   | |          |      |  MSA  |               |       |MUA|    |MUA|
   | |          |      +-------+               |       +---+    +---+
   | |          |          ^(d)           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 (d)).  Then,
   the submitted spam mails are delivered to MTAs of target domains
   (line labeled with (e)).  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.












Akagiri, et al.         Expires January 28, 2018               [Page 10]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +------+-------+    |
                |        (c)^            |
                +-----------|------------+
   +------------+    +------+
   |       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)) A countermeasure
   for this strategy is OP25B.

4.  Outbound Port 25 Blocking

   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.



Akagiri, et al.         Expires January 28, 2018               [Page 11]


Internet-Draft                    OP25B                        July 2017


   After ISP A implements OP25B, a mail sender can send email messages
   via MSA which ISP A serves (a, e) while they cannot send email
   messages via other paths (c).  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.

   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.

   1.  Allow traffic from dynamic IP addresses to port 25 of designated
       MSAs

   2.  Deny all traffic to port 25 of MSAs other than MSAs described in
       1

   3.  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.









Akagiri, et al.         Expires January 28, 2018               [Page 12]


Internet-Draft                    OP25B                        July 2017


 +--------------------------------+                            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:

   o  Fewer ACL rules on each network devices




Akagiri, et al.         Expires January 28, 2018               [Page 13]


Internet-Draft                    OP25B                        July 2017


   o  No spam mail traffic to the backbone network

   o  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.

4.1.  Deployment Considerations

   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.

   1.  Subscribers use other MSAs than ones located inside the ISP.  In
       this case, the subscribers subscribe to multiple ISPs.

   2.  Subscribers use the MSAs served by hosting providers or ASPs.

   3.  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.  Figure 10 shows this problem.  The number of the
   arrows in Figure 10 is correspondent to the number in the list above.









Akagiri, et al.         Expires January 28, 2018               [Page 14]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |        ^               |
                +--------|---------------+
   +------------+        + - - - - - - +
   |       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.








Akagiri, et al.         Expires January 28, 2018               [Page 15]


Internet-Draft                    OP25B                        July 2017


   +-------------+                  +-+-----------+-+
   |             |                  | +-----------+ |
   |  +-------+  |        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).

4.2.  Submission port (587)

   o  Mail system operators MUST serve MSAs which support the submission
      port (port number 587).

   o  The operators MUST implement SMTP Auth on the MSAs.

   o  Even for the local mail distributions, the subscribers SHOULD use
      SMTP Auth.

   o  The POP ID/Password pairs SHOULD be identical with AUTH ID/
      Password of SMTP Auth.

   o  MSAs MUST NOT serve POP before SMTP.

   o  These operations are for the operators of MSAs which accept
      submissions from global IP addresses.










Akagiri, et al.         Expires January 28, 2018               [Page 16]


Internet-Draft                    OP25B                        July 2017


   +------------+    ^
   |       ISP B|    |
   |            |
   |  +-------+ |    |
   |  |  MTA  | |
   |  |  MSA  | |    |
   |  +-------+ |
   |  [25][587+auth] |
   |    ^     ^ |
   | +--|-----|------X-------------------------+
   | |  |     | |    |                         |
   | |  |     | |    | +-------+               |
   | |  |(b)  | (b') | |  MSA  |               |
   | |  |     | |    | +-------+               |
   | |  |     | |    |                    ISP A|
   +-+--|-----|-+----|-------------------------+
        |     |      |                 |
      +-+-+   |    +-+-+             +-+-+
      |MUA+---+    |MUA| bot(zombie) |MUA|
      +---+        +---+ spam sender +---+

                   Figure 12: OP25B with submission port

   In Figure 12, 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



Akagiri, et al.         Expires January 28, 2018               [Page 17]


Internet-Draft                    OP25B                        July 2017


   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.

4.3.  Complete migration to submission port(587)

   o  For mail submissions, MUAs MUST utilize MSAs which support both of
      the submission port(port 587) and SMTP Auth.

   o  The mail system operators MUST abolish the use of MSAs which
      utilize the port 25.

   o  The operators MUST deny submissions to MTAs.

   o  This operation is for the operators of MSAs which accept the
      submissions from global IP addresses.

   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).



Akagiri, et al.         Expires January 28, 2018               [Page 18]


Internet-Draft                    OP25B                        July 2017


   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:

   1.  Operators of mail systems prepare MSA(s)[587+Auth] other than
       MTA/MSA[25].

   2.  For new subscribers, prepare the guidance of MSA[587+Auth] only.

   3.  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.

   4.  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.

   1.  ISP of model C

   2.  ISP of model A and B

   3.  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.

4.3.1.  ISP of model C

   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.








Akagiri, et al.         Expires January 28, 2018               [Page 19]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |   +-------+-------+    |
                |   |  MSA  |  MTA  |    |
                |   +-------+-------+    |
                |             [25]       |
                +---------------^--------+
   +------------+               |
   |       ISP B|               |                    +---------------+
   |            |               |                    |          ISP C|
   | +--------+ |               |                    | +--------+    |
   | | MTA [25]<----------------+----------------------|   MTA  |    |
   | | MSA    | |                                    | [25]MSA  |    |
   | +--------+ |                                    | +-^------+    |
   |            |                                    |   |           |
   |            |                                    |   |           |
   | +-----------------------------------------+     +---------------+
   | |          |                              |         |
   | |          |      +-------+               |       +-+-+    +---+
   | |          |      |  MSA  |               |       |MUA|    |MUA|
   | |          |      +-------+               |       +---+    +---+
   | |          |                         ISP A|
   +-+----------+------------------------------+

      +---+        +---+             +---+
      |MUA|        |MUA| bot(zombie) |MUA|
      +---+        +---+ spam sender +---+


     Figure 13: Mail distribution path after OP25B in ISPs of model C

4.3.2.  ISP of model A and B

   o  Operators of model B ISPs SHOULD cooperate with operators of model
      A ISPs.

   o  Operators of model A ISPs SHOULD accept the requests from model B
      ISPs.

   o  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].







Akagiri, et al.         Expires January 28, 2018               [Page 20]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |   +-------+-------+    |
                |   |  MSA  |  MTA  |    |
                |   +-------+-------+    |
                |             [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 14: Mail distribution path of model B ISP

   In Figure 14, 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.

   1.  ISP A permit the mail submissions from MUAs in ISP B to MSA[25]
       or MTA[25] of ISP B.

   2.  Subscribers of ISP B "completely" migrate SMTP server
       configurations of their MUAs to MSA[587+Auth]




Akagiri, et al.         Expires January 28, 2018               [Page 21]


Internet-Draft                    OP25B                        July 2017


   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.

   1.  ISP B aggregates the address blocks for MSAs as few as possible.

   2.  ISP A permits submissions from subscribers of ISP B to MSAs[25]
       or MTA[25].

   3.  ISP A implements OP25B.

   4.  Subscribers of ISP B migrates SMTP server configurations of their
       MUAs to MSA[587+Auth].

   5.  ISP B stops to accept submissions to MSA[25] or MTA[25].

   The transition period is desirable to be as short as possible.

4.3.3.  Providers which cannot identify submission sources

   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).


























Akagiri, et al.         Expires January 28, 2018               [Page 22]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |   +-------+-------+    |
                |   |  MSA  |  MTA  |    |
                |   +-------+-------+    |
                |   [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 15: 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, the use of POP before SMTP is not recommended.  It MUST
   be migrated to SMTP Auth as soon as possible.






Akagiri, et al.         Expires January 28, 2018               [Page 23]


Internet-Draft                    OP25B                        July 2017


4.3.4.  Related item

   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.

4.4.  Considerations

4.4.1.  Attacks against OP25B

   o  TCP traffic which the source IP addresses are dynamic IP addresses
      and the destination port is 25 MUST be blocked.

   o  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 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 16 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.






Akagiri, et al.         Expires January 28, 2018               [Page 24]


Internet-Draft                    OP25B                        July 2017


        +-------+
        |  MSA  |
        ++------+
         |     ^
         |     |
         |     |
         |     |
         v     |
   +-----+-+  ++-----+
   |dynamic+--+static|
   +-------+  +------+
    |               |
    |  spam sender  |
    |               |
    +---------------+

                   Figure 16: Asymmetric routing attack

   "Triangular spamming"[Triangular] is a more generalized attack.
   Triangular spamming enables spam senders to bypass OP25B utilizing
   relaying nodes.  Figure 17 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.




















Akagiri, et al.         Expires January 28, 2018               [Page 25]


Internet-Draft                    OP25B                        July 2017


                    +----------------------+
                    |Internet              |
                    |       +-----+        |
               +------------+ MSA |<-----------+
               |    |       +-----+        |   |
               |    |                      |   |
               |    |                      |   |
               |    +----------------------+   |
               |                               |
               |                               |
   +-----------|----------+          +---------|------------+
   |ISP2       |          |          |ISP1     |            |
   |           |          |          |         |            |
   |           | +---------------------------+ |            |
   |           | |        |          |       | |            |
   |           | |        |          |       | |            |
   |           | |        |          |       | |            |
   +-----------|-|--------+          +-------|-|------------+
               v |                           v |
         +-------+--+                        +-+-+
         |Spam Relay|                        |MUA|spam sender
         +----------+                        +---+

                      Figure 17: Triangular spamming

   Countermeasures for these attacks are shown below.

   1.  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)

   2.  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.

4.4.2.  Alternative MSA

   o  Operators SHOULD provide third-party alternative MSAs.

   This operation is for the operators of ISPs.




Akagiri, et al.         Expires January 28, 2018               [Page 26]


Internet-Draft                    OP25B                        July 2017


   To explain the need for alternative MSAs, we illustrate a mail user
   disrupted by OP25B.

   1.  User A is a subscriber of ISP A.

   2.  ISP A does not allow relays other than that for the email
       messages which the MAIL FROM field is within its own domain.

   3.  The user has another mail address "foo@example.com" than that of
       ISP A.

   4.  The MSA of "example.com" is located outside of ISP A and does not
       provide submission port.

   5.  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].

4.4.3.  Mail quota

   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.




Akagiri, et al.         Expires January 28, 2018               [Page 27]


Internet-Draft                    OP25B                        July 2017


4.4.4.  IPv6 Consideration

   TBD

4.4.5.  ACL rules to permit submission port

   o  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).

4.4.6.  MTAs with dynamic IP addresses

   o  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.

   1.  The case the MTA is using dynamic IP address(es) and dynamic DNS.

   2.  The case send-only SMTP servers have dynamic IP addresses only.

   In these cases, operators of the servers SHOULD obtain static IP
   addresses.

5.  The goal of this document

   After the implementation of OP25B, the mail distribution paths from
   ISP A are reformed as three figures below (Figure 18, Figure 19,
   Figure 20).







Akagiri, et al.         Expires January 28, 2018               [Page 28]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |    [587+Auth]  [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 18: Valid mail submission after OP25B

   Figure 18 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).
















Akagiri, et al.         Expires January 28, 2018               [Page 29]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |    [587+Auth]  [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 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.
















Akagiri, et al.         Expires January 28, 2018               [Page 30]


Internet-Draft                    OP25B                        July 2017


                +------------------------+
                |ASP/Hosting/            |
                |Business Enterprise/    |
                |Academic institution    |
                |    +--------------+    |
                |    |   MSA/MTA    |    |
                |    +--------------+    |
                |    [587+Auth]  [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 20: 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.

6.  Acknowledgements

   The author would like to thank Rodney Van Meter for his good
   contributions to this memo.

7.  References

7.1.  Normative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <http://www.rfc-editor.org/info/rfc5321>.




Akagiri, et al.         Expires January 28, 2018               [Page 31]


Internet-Draft                    OP25B                        July 2017


   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <http://www.rfc-editor.org/info/rfc5598>.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
              <http://www.rfc-editor.org/info/rfc6409>.

7.2.  Informative References

   [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.

Authors' Addresses

   Takehito Akagiri
   Regumi, Inc.

   Email: akagiri@regumi.net


   Koji Wakamatsu
   SoftBank Mobile Corp.

   Email: koji.wakamatsu@g.softbank.co.jp


   Genki Yasutaka
   Rakuten, Inc.

   Email: genki.yasutaka@rakuten.com


   Kouji Okada
   Lepidum Co. Ltd.

   Email: okd@lepidum.co.jp







Akagiri, et al.         Expires January 28, 2018               [Page 32]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/