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