North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Fun new policy at AOL
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 [email protected], 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 [email protected]'s account has a > > > > Vixie Experimental [Page 4] > > RFC XXXX Repudiating MAIL FROM May 26, 2002 > > > ".forward" file pointing at [email protected], 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 <[email protected]> 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 > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Vixie Experimental [Page 6] >
|