Fun new policy at AOL
Joseph McDonald
joem at uu.net
Fri Aug 29 20:22:20 UTC 2003
Is this being added to a bind 9 rewrite? If so, when can we
expected it to be released? :)
On Fri, Aug 29, 2003 at 04:47:58PM +0000, Paul Vixie wrote:
>
> > But how about this: in addition to MX hosts, every domain also has one or
> > more MO (mail originator) hosts. Mail servers then get to check the address
> > of the SMTP server they're talking to against the DNS records for the
> > domain in the sender's address. Then customers who use an email address
> > under their ISP's domain have to use the ISP's relay, while people with
> > their own (sub) domain get to use their own.
>
> a fine idea. thank jim miller for it if you see him.
>
> > For AOL and the likes this would also help against spam as they can rate
> > limit incoming mail from unknown domains. Spammers are forced to register
> > new domains all the time in addition to having to find abusable IP
> > addresses so hopefully life for them will be a little more miserable too.
> >
> > (Could reuse MX for this if a new RR is too much hassle, but large ISPs
> > don't use the same SMTP servers for incoming as for outgoing.)
>
> see below.
>
>
>
>
>
>
>
> Independent Paul Vixie (Ed.)
> Request for Comments: XXXX Category: Experimental
> June 6, 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 at 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 registered inbound and
> outbound mail relays, and that if such a relay is (for example) open to
> third party relay, then no value will be added by registering a domain
> MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking
> will be possible on final delivery relays for a domain @ MX containing
> that relay. Multistage relays (both inbound and outbound) are a
> breeding ground for anonymity unless they are very carefully configured.
>
> 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:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vixie Experimental [Page 3]
>
> RFC XXXX Repudiating MAIL FROM May 26, 2002
>
>
> on (MAIL FROM mailfrom) {
> switch (repudiated(mailfrom, ipsource))
> case tempfail:
> smtpreply(450, "temporary dns failure, try again later")
> break
> case repudiated:
> smtpreply(550, "surely you're joking")
> dsn("5.7.1", "delivery not authorized")
> invalidate() // reject all but QUIT and RSET
> break
> }
> }
>
> repudiated(mailfrom, ipsource) = {
> (lhs, rhs) = parse_addr(mailfrom);
> // handle "MAIL FROM:<>" somehow
> mxset = get_mx("MAIL-FROM" "." rhs);
> if (mxset == NULL)
> return nonrepudiated;
> mxset += configured(perimeter_relays);
> foreach mx (mxset) {
> aset = get_a(mx.server);
> if (ipsource IN aset)
> return nonrepudiated;
> }
> return repudiated;
> }
>
> (EDITOR'S NOTE: need to establish a value for 5xx.)
>
> 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 at NETBSD.ORG's account has a
>
>
>
> Vixie Experimental [Page 4]
>
> RFC XXXX Repudiating MAIL FROM May 26, 2002
>
>
> ".forward" file pointing at VIXIE at 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. Roaming hosts such as laptop computers will probably not be able to
> be listed in the MAIL-FROM MX RR for their return address domain name,
> and may be forced to use an intermediary for outbound e-mail. STARTTLS
> or an SSL/SSH tunnel back "home" may become a necessary first hop for
> mobile e-mail.
>
> 3.4. 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.
>
> 3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than for
> the corresponding domain's apex MX RR, since the cost of widely cached
> wrong information is much higher for outbound repudiation data than for
> inbound delivery data. Consider that an incomplete apex MX RR can cause
> mail to be delivered by a suboptimal path, whereas an incomplete MAIL-
> FROM MX RR can cause valid mail to be rejected by relays who attempt
> repudiation.
>
> 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 at jcmco.com> in 1998.
>
>
>
>
>
> Vixie Experimental [Page 5]
>
> 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 at vix.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vixie Experimental [Page 6]
>
More information about the NANOG
mailing list