address differs from the From header.
6.4. Address Space Hijacking
This mechanism assumes the integrity of IP address space for
determining whether a given client is authorized to send messages
from a given PRA. In addition to the TCP attack given in Section
6.2, a sufficiently resourceful attacker might be able to alter the
IP routing structure to permit two-way communication using a
specified IP address. It would then be possible to execute an SMTP
session that appears to come from an authorized address, without the
need to guess TCP sequence numbers or transmit in the blind.
Such an attack might occur if the attacker obtained access to a
router that participates in external BGP routing. Such a router
could advertise a more specific route to a rogue SMTP client,
temporarily overriding the legitimate owner of the address.
6.5. Malicious DNS Attacks on Third Parties
There is class of attacks in which an attacker A can entice a
participant P to send a malicious message to a victim V.
These attacks are undertaken by A citing the address of V in the SMTP
MAIL FROM request and then by causing P to generate (or invoke the
generation of) a Delivery Status Notification ’bounce’ message
(RFC3464), which is sent to the victim V.
The attacker relies upon it being common practice to copy the
original message into the ’bounce’ report, thereby causing the malice
to be sent onward to V.
This mode of attack has the advantages (to the attacker) of
obfuscating the location of the host from which the attack was
mounted, and of possibly damaging the reputation of P by making it
appear that P originated or was an active participant in the sending
of the malicious message.
In current practice, A causes P to cause the ’bounce’ by addressing
the original message to a nonexistent recipient.
Sender ID enables a new variant of this attack.
In this variant, the attacker A sends a message whose PRA (Section 4)
is selected by the attacker to be such that, when P undertakes the
Sender ID test, a Fail will result (Section 5.3).
The message will be rejected (as the attacker intended) and a
malicious ’bounce’ message may be generated and sent to the victim V.
7. Implementation Guidance
This section describes the actions that certain members of the
Internet e-mail ecosystem must take to be compliant with this
specification.
7.1. Simple E-Mailers
A domain that injects original e-mail into the Internet, using its
own name in From headers, need do nothing to be compliant. However,
such domains SHOULD publish records in DNS as defined by [RFC4408]
and this specification.
In the majority of cases, the domain’s published information will be
the same for both the PRA and MAIL FROM variants of this test. In
this case, domains SHOULD publish their information using an SPF
record with the prefix "v=spf1". Doing so will render their
published information usable by the older SPF protocol, too. (See
[RFC4408] for information on the SPF protocol.)
7.2. E-Mail Forwarders
In order to pass the PRA variant of the test, a program that forwards
received mail to other addresses MUST add an appropriate header that
contains an e-mail address that it is authorized to use. Such
programs SHOULD use the Resent-From header for this purpose.
In order to pass the MAIL FROM variant of the test, a program that
forwards received mail to other addresses MUST alter the MAIL FROM
address to an address under its control. Should that address
eventually receive a DSN relating to the original message, that DSN
SHOULD be forwarded to the original MAIL FROM address. However, if
this altered address receives any messages other than DSNs related to
the original message, these messages MUST NOT be forwarded to the
original MAIL FROM address; they SHOULD be refused during an SMTP
transaction.
In addition, e-mail forwarders SHOULD publish Sender ID records for
their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
Some of today’s forwarders already add an appropriate header
(although many of them use Sender rather than Resent-From.) Most of
them do not perform the address-rewriting specified above.
Note that an e-mail forwarder might receive a single message for two
or more recipients, each of whom requests forwarding to a new
address. In this case, the forwarder’s MTA SHOULD transmit the
message to each new recipient individually, with each copy of the
message containing a different newly inserted Resent-From header
field.
7.3. Mailing List Servers
In order to pass the PRA variant of the test, a mailing list server
MUST add an appropriate header that contains an e-mail address that
it is authorized to use. Such programs SHOULD use the Resent-From
header for this purpose.
In order to pass the MAIL FROM variant of the test, a mailing list
server MUST alter the MAIL FROM address to an address under its
control.
In addition, mailing list servers SHOULD publish Sender ID records
for their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
Most of today’s mailing list software already adds an appropriate
header (although most of them use Sender rather than Resent-From),
and most of them already alter the MAIL FROM address.
7.4. Third-Party Mailers
In order to pass the PRA variant of this test, a program that sends
mail on behalf of another user MUST add an appropriate header that
contains an e-mail address that it is authorized to use. Such
programs SHOULD use the Sender header for this purpose.
In order to pass the MAIL FROM variant of this test, a program that
sends mail on behalf of another user MUST use a MAIL FROM address
that is under its control. Defining what the program does with any
mail received at that address is beyond the scope of this document.
In addition, third-party mailers, servers SHOULD publish Sender ID
records for their domains, and SHOULD use MTAs for which the Sender
ID check yields a "pass" result.
Many, but not all, of today’s third-party mailers are already
compliant with the PRA variant of the test. The extent to which
mailers are already compliant with the MAIL FROM variant of this test
is unknown.
7.5. MUA Implementers
When displaying a received message, an MUA SHOULD display the
purported responsible address as defined by this document whenever
that address differs from the RFC 2822 From address. This display
SHOULD be in addition to the RFC 2822 From address.
When a received message contains multiple headers that might be used
for the purported responsible address determination, an MUA should
consider displaying all of them. That is, if a message contains
several Resent-From’s, a Sender, and a From, an MUA should consider
displaying all of them.
Sender ID also does not validate the display name that may be
transmitted along with an e-mail address. The display name is also
vulnerable to spoofing and other forms of attacks. In order to
reduce the occurrence and effectiveness of such attacks, MUA
implementers should consider methods to safeguard the display name.
This could include the following:
* Not presenting the display name to the user at all, or not
presenting the display name unless the corresponding e-mail address
is listed in the user’s address book.
* Treating as suspicious any e-mail where the display name is itself
in the form of an e-mail address, especially when it differs from
the actual e-mail address in the header.
* Making it clear to users that the e-mail address has been checked
rather than the display name.
8. Acknowledgements
This design is based on earlier work published in 2003 in [RMX] and
[DMP] drafts (by Hadmut Danisch and Gordon Fecyk, respectively). The
idea of using a DNS record to check the legitimacy of an e-mail
address traces its ancestry to "Repudiating Mail From" draft by Paul
Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain-
Authorized SMTP Mail" draft by David Green [Green], who first
introduced this idea on the namedroppers mailing list in 2002.
The current document borrows heavily from each of the above, as well
as earlier versions of [RFC4408] and [CallerID], and incorporates
ideas proposed by many members of the MARID working group. The
contributions of each of the above are gratefully acknowledged.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4405] Allman E. and H. Katz, "SMTP Service Extension for
Indicating the Responsible Submitter of an E-Mail
Message", RFC 4405, April 2006.
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail", RFC 4408,
April 2006.
9.2. Informative References
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification, http://www.microsoft.com/mscorp/safety/
technologies/senderid/resources.mspx
[DMP] Fecyk, G., "Designated Mailers Protocol",
http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt, December
2003.
[Green] David Green, "Mail-Transmitter RR",
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/
msg00656.html, June 2002.
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight
SMTP sender authorization",
http://www.danisch.de/work/security/txt/
draft-danisch-dns-rr-smtp-04.txt
[Vixie] Paul Vixie, "Repudiating Mail From",
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/
msg00658.html, June 2002.
Authors’ Addresses
Jim Lyon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: jimlyon@microsoft.com
Meng Weng Wong
Singapore
EMail: mengwong@dumbo.pobox.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).