ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: RMX evaluation / Paul Vixie's procedure

2003-05-08 23:31:46
I have to admit that this does seem to be a well laid out and workable method.
(any comments I may have made earlier to the contrary were based on incomplete 
and inaccurate information)

It accomplishes all of the goals of RMX and similar schemes and it is 
reasonably close to accepted standards and doesn't abuse them and it does not 
require any programming changes on the DNS end.

Due to interactions with internet mailing lists I personally feel that the 
comparison should be against the envelope-from instead of mail-from and that 
differences between the envelope-from and mail-from should be displayed in 
the MUA.  I believe Outlook (I know, not a good example but an example) 
displays this information via the Sender or X-Sender header if I remember 
correctly.  The output resembles 
"From: asrg(_at_)ietf(_dot_)org on behalf of paul(_at_)vix(_dot_)com"

Are there any/very many servers configured this way currently?

On Thursday 08 May 2003 12:47 pm, Paul Vixie wrote:
I searched for but failed to find Paul Vixie's short mail message
describing the idea.  ...

   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(_dot_)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(_dot_)ORG's account has a



   Vixie                         Experimental                      [Page 4]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002


   ".forward" file pointing at VIXIE(_at_)ISC(_dot_)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(_dot_)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(_dot_)com









































   Vixie                         Experimental                      [Page 6]

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg