Subject: Mail-Transmitter RR

From: David Green <[email-masked]>
Date: Sat, 1 Jun 2002 20:49:48 -0400 (EDT)

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)

Thanks,

David Green

---

From: Paul Vixie <[email-masked]>
Date: Sat, 01 Jun 2002 18:16:37 -0700

> 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 [email-masked], 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 [email-masked]'s account has a
   ".forward" file pointing at [email-masked], 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 <[email-masked]> 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
      [email-masked]

   Vixie                         Experimental                      [Page 5]


--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Sun, 02 Jun 2002 11:24:30 +1000

Email addresses are tied to individuals not machines.  I don't
	think anyone wants to give up sending email as themselves from
	a arbitary machine.  Without the will to give this up you won't
	reach the critical match to make this idea work.

	SPAM is a political problem and as such technical solutions won't,
	in general, work.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 01 Jun 2002 21:46:40 -0400

Agreed.  I send mail from my laptop, which travels with me all over
the place, but my From address is elsewhere.  How is my home address
supposed to know what IP address I'm using at any particular point in
time?  Forcing me to forward all my mail through my home network just
means more latency when they get clogged.  Worse, I've got _multiple_
addresses that I use -- how is my mail agent (UA or TA) supposed to
know how to forward the mail?

I agree that this technical solution wont really work.  However I
disagree that all technical solutions are out of the question.  Some
of the technical proposals I've seen might help.  For example, if all
email required PGP security, or if all email required a "digital
postage stamp" where the sender has to pay real money to the recipient
if they consider the message spam.  For real email usage the recipient
would never cash in the postage, but for spammers it would (hopefully)
be a financial disincentive to spam.  MTAs could verify the postage on
messages or drop them, MUAs would be given an option of "cash the
postage or ignore it".

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Al Costanzo" <[email-masked]>
Date: Sat, 1 Jun 2002 21:30:30 -0400

Hi,

The draft needs work but its a -- good concept -- you could add code the
mail agent to look for the RR record.

I think this will need to be discussed on the SMTP side of the house first
because a RR does nothing if the mail protocol does not use it IMHO.

Regards,

Al
----- Original Message -----
From: "David Green" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 01, 2002 8:49 PM
Subject: Mail-Transmitter RR

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8+WuwCi6CzkbyeRQRAhgwAKCMt8l88znXNKkC2QQMFAcsKCApsACggDIn
> 8dBjMHAeIVCIinb/g4HKyEE=
> =s/yu
> -----END PGP SIGNATURE-----
>
>

---

From: Mathias Koerber <[email-masked]>
Date: Sun, 02 Jun 2002 10:42:01 +0800

> know how to forward the mail?

There are mail clients that can distinguish between different 
sender-accounts
and select different outgoing SMPT servers for each. In addition, I
tunnel all such traffic through SSH to my home-site anyway, mostly to
have a central log of all mail and to have a unified sending-location
anyway..

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 01 Jun 2002 21:54:09 -0500

David Green wrote:

>                   Name: domauth.txt
>    domauth.txt    Type: Plain Text (TEXT/PLAIN)
>               Encoding: BASE64

This comes up every few months. Welcome to the club.

See draft-church-dns-mail-sender-01.txt as another approach, and one that
considers how to deal with roadblock relays.

See the attached message for some ideas on getting more mileage out of a
single RR (such as allowing an org to declare their entire reverse PTR
space as valid relays).

See the [email-masked] archives for flames, accusations, innuendos, and
unsupported arguments against it. Some people are very opposed to it.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Subject: Re: authenticating the source of mail
From: "Eric A. Hall" <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 17 May 2002 12:36:49 -0500
List-Id: <ietf-822.imc.org>

More thinking on this, probably the best approach here is to define a
flags sub-field in the MS RR, which allows for domain indirection.

Two flags which could be used right away:

   bit 1 off=value refers to a host
          on=value refers to a domain

   bit 2 off=use A/AAAA RRs associated with value
          on=use MX RRs associated with value

Combining these flags would allow for various functions, with a minimal
amount of overhead. Some examples below.

Use the IP addresses associated with outbound.example.com as the
authorized relay servers for example.com:

 [Answer Section]
  example.com.           MS   0   outbound.example.com.

 [Additional-Data Section]
  outbound.example.com.  A    10.0.0.3

Use the MX RRs associated with mail.example.com as the authorized relay
servers for example.com:

 [Answer Section]
  example.com.           MS   3   mail.example.com.

 [Additional-Data Section]
  mail.example.com.      MX   5   mx-1.example.com.
  mail.example.com.      MX   5   mx-2.example.com.
  mx-1.example.com.      A    10.0.0.1
  mx-2.example.com.      A    10.0.0.2

[note that the MX RRs would not be provided in the Additional-Data section
if a query for ALL resulted in them being provided in the Answer section
of the response]

Any and all hosts in the mail.example.com domain are authorized relay
servers for example.com:

 [Answer Section]
  example.com.           MS   1   mail.example.com.

 [Additional-Data Section]
  <empty>

[the PTR for the current mail session should be examined, and if it
resides within the specified domain, then it is authorized]

These could also be cumulative. EG, use the IP addresses associated with
outbound.example.com PLUS the MX RRs associated with the mail.example.com
domain as the authorized relay servers for example.com:

 [Answer Section]
  example.com.           MS   0   outbound.example.com.
                         MS   3   mail.example.com.

 [Additional-Data Section]
  outbound.example.com.  A    10.0.0.3
  mail.example.com.      MX   5   mx-1.example.com.
  mail.example.com.      MX   5   mx-2.example.com.
  mx-1.example.com.      A    10.0.0.1
  mx-2.example.com.      A    10.0.0.2

The benefit of this approach is that it allows for sender-based
customization of the interpretation (hosts vs MX lists), but minimizes the
risk of overloads. The above needs more smoothing out but I think it is
workable.

Any other flags which would be useful? Any comments on this approach?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 12:49:54 -0400 (EDT)

> know how to forward the mail?

Or use a different From: address for the network you are currently on, 
and use the Reply-To header to point to your real email address. I imagine 
that once domains become authenticated, then ISPs will start to do 
user-based authentication. Therefore, if you're using 
[email-masked]'s Internet account, then [email-masked] would 
be forced by MindSpring to be the From: address for all outgoing mail from 
your particular IP. Which is, actually, correct; the email IS coming from 
[email-masked]'s connection/computer. Then set the appropriate 
Reply-To field.

David Green

---

From: Alan Barrett <[email-masked]>
Date: Sun, 2 Jun 2002 19:31:24 +0200

>    mail claiming to be from [email-masked], the following DNS MX RR's should

I think that the magic label should begin with an underscore
(e.g. "_MAIL-FROM"), for the same reasons that we use "_tcp" rather than
just "tcp" as a label for SRV records.

--apb (Alan Barrett)