Internet DRAFT - draft-akagiri-op25b-dynamicip
draft-akagiri-op25b-dynamicip
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]
