[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mail-Transmitter RR
> I'm sorry if this is off-topic, but I couldn't find a working group that
> is working on dealing with spam, so this is the closest match I could
> find. I know this is in no way related to IPv6 or anything else you guys
> are working on, but it is an idea I had involving the addition of a RR
> type. If this is not the right place to be sending this, any pointers to
> other working groups/forums would be greatly appreciated. And I appreciate
> all of the hard work you guys are doing... My idea is attached (domauth.txt)
In 1998, Jim Miller suggested this. A few weeks ago, I wrote the following.
Comments are welcome.
Independent Paul Vixie (Ed.)
Request for Comments: XXXX Category: Experimental
May 28, 2002
Repudiating MAIL FROM
Status of this Memo
This memo describes an experimental procedure for handling received
e-mail. It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
At the time of this writing, more than half of all e-mail received by
the author has a forged return address, due to the total absence of
address authentication in SMTP (see [RFC2821]). We present a simple
and backward compatible method whereby cooperating e-mail senders and
receivers can detect forged source/return addresses in e-mail.
1 - Introduction and Overview
1.1. Internet e-mail return addresses are nonrepudiable by design of the
relevant transport protocols (see [RFC2821]). Simply put, there is no
cause for ANY confidence in the proposition "this e-mail came from where
it says it came from."
1.2. Irresponsible actors who wish to transmit unwanted bulk e-mail
routinely use this designed-in lack of source/return authenticity to
hide their point of origin, which usually involves forging a valid
return address belonging to some highly visible and popular ISP (for
example, HOTMAIL.COM).
1.3. Recipients who wish to reject unwanted bulk e-mail containing
forged source/return addresses are prevented from doing so since the
addresses, as presented, are nonrepudiable by design. Simply put, there
would be too many false positives, and too much valid e-mail rejected,
if one were to program an e-mail relay to "reject all e-mail claiming to
be from HOTMAIL.COM" since, statistically, most e-mail claiming to be
from HOTMAIL.COM is actually from somewhere else. HOTMAIL.COM, in this
example, is a victim of forgery.
Vixie Experimental [Page 1]
RFC XXXX Repudiating MAIL FROM May 26, 2002
1.4. What's needed is a way to guaranty that each received e-mail
message did in fact come from some mail server or relay which can
rightfully originate or relay messages from the purported source/return
address.
1.5. Approaches of the form "use PGP" and "use SSL" are not scalable in
the short term since they depend on end-to-end action and there are just
too many endpoints. An effective solution has to be applicable to mail
relay, not just final delivery.
1.6. Valid ("wanted") e-mail must not be rejected by side effect or
partial adoption of this proposal. Source/return authenticity must be a
confidence effector, as in "we can be sure that this did not come from
where it claims" and simple uncertainty must remain in effect otherwise.
2 - Behaviour
2.1. Domain owners who wish their mail source/return information to be
repudiable will enter stylized MX RR's into their DNS data, whose owner
name is "MAIL-FROM", whose priority is zero, and whose servername
registers an outbound (border) relay for the domain. For example, to
tell the rest of the Internet who they should believe when they receive
mail claiming to be from VIXIE@ISC.ORG, the following DNS MX RR's should
be entered:
$ORIGIN isc.org.
MAIL-FROM MX 0 rc
MX 0 rc1
In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as
appropriate places to originate mail from @ISC.ORG. Note that this
differs from the normal inbound MX RRset for this example domain:
$ORIGIN isc.org.
@ MX 0 rc
MX 0 isrv4
So, the inbound mail server set partially overlaps with, but differs
from, the example outbound mail server set. This is quite common in the
Internet, and is the reason why the normal inbound mail server set
described by a domain's apex MX RRset cannot be used for repudiation
purposes.
Vixie Experimental [Page 2]
RFC XXXX Repudiating MAIL FROM May 26, 2002
2.2. Second-stage relays such as ISP mail servers are often used and can
be described by adding as many relays as necessary to the MAIL-FROM MX
RRset. In our example, if ISC sometimes used UUNET for outbound mail
services, the DNS data describing this relationship might be as follows:
$ORIGIN isc.org.
MAIL-FROM MX 0 rc
MX 0 rc1
MX 0 uunet.uu.net.
Let it be noted that a domain owner's power to repudiate forged e-mail
is only as strong as the security policy of its registed outbound mail
relays, and that if UUNET.UU.NET were (in the above example) open to
third party relay, then no value will be added by registering a domain
MAIL-FROM.
2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail
would check the SMTP (see [RFC2821]) MAIL FROM payload at the time of
receipt. The precise method to be used is as follows:
on (MAIL FROM mailfrom) {
if (repudiated(mailfrom, ipsource)) {
reply(5xx, "you've got to be joking 1");
reset();
}
}
And:
repudiated(mailfrom, ipsource) = {
(lhs, rhs) = parse_addr(mailfrom);
mxset = get_mx("MAIL-FROM" "." rhs);
if (mxset == NULL)
return FALSE;
mxset += configured(perimeter_relays);
foreach mx (mxset) {
aset = get_a(mx.server);
if (ipsource IN aset)
return FALSE;
}
return TRUE;
}
(EDITOR'S NOTE: need to establish a value for 5xx, and also get someone
from the SMTP community to rule on the reset() shown here.)
Vixie Experimental [Page 3]
RFC XXXX Repudiating MAIL FROM May 26, 2002
The method amounts to "if there's a MAIL-FROM for the purported domain
and if the IP source isn't on the resulting list, then reject the mail".
Multistage inbound relays are allowed for, by implicitly appending one's
own outer perimeter relay names to every extant MAIL-FROM.
3 - Impact
3.1. This specification is optional, and will only affect cooperating
parties. Any domain owner who does not enter a MAIL-FROM will be
unaffected, and any SMTP receiver who does not look for a MAIL-FROM at
time of receipt will be unaffected. However, both parties working
together CAN work to repudiate forged e-mail return/source information.
3.2. Transport-level e-mail forwarding must be more explicit under this
specification. For example if VIXIE@NETBSD.ORG's account has a
".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the
former will be received by the latter, but with no change in the payload
of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be
configured to implicitly add NETBSD's outbound mail relays as
"multistage inbound relays." This could scale poorly and may add
pressure toward transport remailing (with a new envelope) rather than
transport forwarding (reusing the old envelope.)
3.3. The likely endgame for this behaviour is to force senders of
unwanted bulk e-mail to stop lying about who they are, which is illegal
in meatspace anyway -- but such laws are unenforceable due to the nature
of the Internet's mail system. Under this proposal, any domain owner
who is the victim of forgery can respond by adding MAIL-FROM data to
their DNS zone, and any relay owner who is the victim of forged unwanted
e-mail can respond by checking for MAIL-FROM data upon receipt of all
incoming e-mail.
4 - Security Considerations
In the continuing absence of widely deployed security for DNS, this
proposal effectively places an access control list for forged
source/return information in a place where it can be attacked. However,
it must be noted that the current senders of forged unwanted bulk e-mail
are typically not technologically capable of attacking the DNS to insert
forged MAIL-FROM data.
5 - Acknowledgements
This idea originated with Jim Miller <jmiller@jcmco.com> in 1998.
Vixie Experimental [Page 4]
RFC XXXX Repudiating MAIL FROM May 26, 2002
5 - Author's Address
Paul Vixie
950 Charter Street
Redwood City, CA 94063
+1 650 779 7000
paul@vix.com
Vixie Experimental [Page 5]
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>