Subject: [Asrg] RMX evaluation (was RE: Is there anything good enough? - Spoofing stats)

From: Paul Judge <[email-masked]>
Date: Thu, 8 May 2003 12:08:59 -0400

This is a clear list of arguments against RMX. To move this conversation
forward in a meaningful way, let's do a few things:

Vernon, can you post Vixie's suggestions that you referring to so that
everyone is aware of them. Can you also explain in more detail the
difference between those and RMX to show why you say that it is simpler.

Hadmut and/or Mike, please read the other links that Vernon provided "
http://www.google.com/search?q=match+sender+domain+hotmail and
http://www.monkeys.com/anti-spam/filtering/additions.html"  and provide a
comparison between those and RMX?

Paul
 
> No, I don't approve of RMX.  I believe
>   - it is redundant and unnecessary because existing 
> mechanisms achieve
>      can stop mail from free providers that does not come from each
>      provider's MTAs.
>   - there are simpler, already largely deployed ways to do exactly
>      what RMX does without a new RR, including Paul Vixie's 
> suggestions. 
>   - the new RMX RR will never be seriously considered in the DNS WG.
>   - if by some fluke that happens it will never pass Last 
> Call in a DNS WRK.
>   - if everyone is asleep there, it won't pass IESG review or 
> main list
>      Last Call.
>   - if it does get standardized, it will not be widely 
> implemented in MTAs.
>   - it will not be installed by the organizations you need to install
>      it, including Hotmail, AOL, and Microsoft, because they will not
>      change their business models.
> 
> I'm beginning to get the impression that RMX proponents are 
> egregiously unaware of how SMTP works and is commonly used.  
> Contrary to statements from RMX propoents, current standards 
> and practices support rejecting mail from a free provider 
> that does not come from the free provider's MTAs.  Many MTAs 
> have been doing exactly that for years.  For example, see the 
> pages found by 
> http://www.google.com/search?q=match+sender+domain+hotmail 
> including http://www.monkeys.com/anti-spam/filtering/additions.html
> 
> 
> > You're expending an awful lot of energy trying to break down the 
> > process but
> > you are an advocate of something much more anti-standards 
> and intrusive.  
> 
> Using existing standards is less "anti-standards" and less 
> intrusive than demanding other people do things including 
> change their business models and demanding changes to 
> standards such as DNS.  The current standards and practices 
> already support rejecting free provider mail that does not 
> come from the free provider's MTAs.  (I'm repeating myself 
> because repetitions in previous messages were apparently unclear.)
> 
> I think resisting standards changes that are based on willful 
> ignorance of existing standards and current practices is 
> required to keep the IETF process from breaking down completely.
> 
> 
> > Instead of blocking the spammers from using those domains you block 
> > everyone.
> 
> As I've said many times over the years including this list, I 
> think free providers are parasites on the Internet because of 
> how they handle network abuse.  I do not expect you or other 
> ASRG contributors to share this extreme view and I certainly 
> do not expec the free providers to change.  I do not block 
> all users using those domains, but only almost all.  My free 
> provider blacklist has a handful of whitelist holes.
> 
> 
> > >...I think demanding that free providers
> > >change to fit my model of how they should run their businesses to 
> > >suit my convenience would be wrong.
> >
> > Then why are you doing it?  Why are you saying "you can't have free 
> > e-mail or
> > I won't accept your messages"?  You are absolutely telling 
> them how to run 
> > their business if they want to send you mail.
> 
> Yes, but only if they want to send me mail.  Contrary to you 
> model, they are free to send each other mail that complies 
> with their providers' terms and conditions.  I think that 
> even spam is just fine, provided it stays on the spam 
> friendly side of the net and away from me.
> 
> 
> > >with postfix (which you seem to use).
> > I only use pieces of it.  I'm working on an SMTP proxy with 
> > finer-grained
> > scriptable rules and logging to a database.
> 
> So why haven't you long since implemented the standard checks 
> to prevent what you call "spoofed" free provider mail?
> 
> 
> Vernon Schryver    [email-masked]
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 8 May 2003 11:19:54 -0600 (MDT)

> From: Paul Judge <[email-masked]>

> ...
> ...

Paul Vixie's suggestion is differs from the common and old mechanism
of rejecting mail with Mail_From values of free providers when the
SMTP client is not an MTA of the free provider.  RMX and Paul's notion
allow the owner of a sender domain to authorize not only SMTP clients
with names related to the sender domain but also SMTP clients in a
small number of additional domain names to also send mail nominally
from the sender domain.  (The number is small because of the limited
size of DNS/UDP packets.)

I searched for but failed to find Paul Vixie's short mail message
describing the idea.  My recollection and perhaps slight elaboration
of it is:

 To determine if an STMP client is authorized to send mail for the
 sender domain name in the envelope Mail_From field

  1. an SMTP server first compares the reverse DNS name of the SMTP
   client with the sender domain.  If they match by the usual rules
   (e.g. [email-masked] matches mailhost.example.com), then the STMP
   client is authorized.  To prevent forgery, the usual reverse-forward
   DNS check is made.

  2. Otherwise the SMTP server searches for MX RRs for the sender
   domain.  The IP address of the SMTP client is then compared to the
   list of IP address eventually obtained for the names in the MX RRs.
   (As usual and described in RFC 2821, if no MX RRs are found, the
   IP address of A RRs, if any, are used.)  If the SMTP client's IP
   address is a member of this list, then the SMTP client is authorized.

  3. Otherwise the SMTP server checks the list of MX RRs for a record
   with the preference 65391.  If such a record exists, the SMTP server
   knows that sender domain is participating in this standard, the
   list of MX RRs contains a complete list of the SMTP clients authorized
   to send mail for the sender domain, and that the SMTP server is
   unauthorized.  The SMTP server therefore rejects the message.

  4. Otherwise the sender domain is not particpating and the SMTP
   server does not know whether the SMTP client is authorized to send
   the message.  The SMTP server procedes according to local policy
   and other standards.

Note that:
  - An authorized SMTP client need not be an SMTP server.  While its 
     IP address will found by other SMTP clients looking for an SMTP 
     server for the domain, its preference will be numerically higher
     than all working SMTP servers.  Only when all other SMTP servers
     are also not working will SMTP clients try to send to it.  They
     will immediately receive and ICMP Port Unreachable and give up.

  - Most mail will already pass this test, because it is sent from
     SMTP clients that are also SMTP servers for the sender domain.

  - Step #1 is currently used.  Many SMTP servers, albeit a small
    fraction of all SMTP servers, reject mail that does not satisfy
    the test in step #1.

  - The preference 65391 is choosen to be probably not currently used
     in any MX RR in the Internet.

  - This scheme is better than the RMX proposal because it has achieves
     the same goal, does not require the standardization and implementation
     of a new DNS RR in DNS server software and MTAs.  It requires
     only small changes in system administration conventions and modest
     changes in MTAs.

  - I do not like this scheme, because I do not agree with the goal of
     forcing people to use the same going as incoming ISPs.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 May 2003 14:01:14 -0400

>      will immediately receive and ICMP Port Unreachable and give up.

  If the client machine is configured correctly.  Many systems will be
listening on port 25 by default, and will undergo additional expense
before the connection is terminated.  (That's arguably their problem,
and unrelated to this proposal.)

  Also, spammers hit all MX's for a domain, so they will hit the
listed MX's for senders too, which may be seen as an additional
feature of this proposal over RMX.

>      only small changes in system administration conventions and modest

  I agree, but reserve judgment as to "better".

>      forcing people to use the same going as incoming ISPs.

  I do not believe that's a goal of this proposal, or of RMX.  The
goal is to provide accountability.  A side-effect of methods used to
achieve that goal may be that some people are forced to change their
network behaviour.  My response is that it's no longer 1983: the
network has changed, and our behaviour will likely have to change,
too.

  The benefit that RMX has over this proposal is that "wildcard" RMX
records can be added to domains, where the DNS administrator responds
that entire networks have consent to send "from" that domain.  In
contrast, since MX records must be 'A' records in DNS, this proposal
must explicitely list every IP in a network to acheive the same
effect.

  Alan DeKok.

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 20:36:51 +0200

>    client is authorized.  To prevent forgery, the usual reverse-forward

This doesn't work in common. A host can have only one reverse DNS
name, but deliver for many different domains. 

Hadmut

---

From: J C Lawrence <[email-masked]>
Date: Thu, 08 May 2003 11:49:56 -0700

On Thu, 8 May 2003 11:19:54 -0600 (MDT) 

> describing the idea.  My recollection and perhaps slight elaboration

Thanks, this is preferable to RMX.

> sender domain name in the envelope Mail_From field

I'd be happier if a straight forward check of the HELO==IP were added as
a check.

>   - This scheme is better than the RMX proposal because it has
> achieves the same goal, does not require the standardization and
> implementation of a new DNS RR in DNS server software and MTAs.  It
> requires only small changes in system administration conventions and
> modest changes in MTAs.

It also has the advantage of not changing its behaviour significantly as
penetration thresholds grow.

> forcing people to use the same going as incoming ISPs.

Agreed.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 20:48:15 +0200

On Thu, May 08, 2003 at 12:08:59PM -0400, Paul Judge wrote:
> 
> This is a clear list of arguments against RMX. 

You do call that "arguments"? Are you serious?

> >      can stop mail from free providers that does not come from each

We are not talking about the few free providers only. There are
tens of millions of domains, not only five.

> >      what RMX does without a new RR, including Paul Vixie's 

If they do exactly what RMX does, why shouldn't those objections
against RMX apply to them as well?

> >   - the new RMX RR will never be seriously considered in the DNS WG.

Wow, that is an first class argument. Shouldn't we let the WG itself
decide it instead of Vernon?

> >   - if by some fluke that happens it will never pass Last 

Wow, another first class argument. We are blessed to have such
a genius like Vernon who can predict other peoples opinion. 

> >   - if everyone is asleep there, it won't pass IESG review or 

Another one of these. I wonder what we need IETF, IRTF, working groups
and mailing lists for if we have a fortune teller like Vernon.

> >   - if it does get standardized, it will not be widely 

Wow, again a well-founded argument. 

> >      change their business models.

What does Microsoft need Bill Gates for if we have Vernon to define
their Business Model? Why do we need to fight against Spam at all if
Spam perfectly meets companies business models?

> > egregiously unaware of how SMTP works and is commonly used.  

Wow, another good argument. Paul, I guess that could be your 
favourite...

Paul, I really do applaude for your wise and experienced way
of group leadership and your profound ability to identify
good arguments.

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 8 May 2003 13:01:24 -0600 (MDT)

> From: J C Lawrence <[email-masked]>

> Thanks, this is preferable to RMX.

It seems it also differs from Paul's intent.  However, I think the
differences are minor.  Both involve overloading MX RRs and depend
on using keys or values that are unlikely to be in current use.
I'm not sure, but I think Paul's intent (or Jim Miller's idea) does
better on that score.

> I'd be happier if a straight forward check of the HELO==IP were added as

I think that's independent of the idea of RMX checking.

The problem with checking HELO values is that simple implementations
will have many false positives.  It's a hassle to make an SMTP client
vary its HELO value depending on the IP address that operating system
picks on a multi-homed system.  Forcing the choice of source IP address
is impractical on multi-homed systems acting as firewalls and where
some interfaces are not reachable from various networks.  You would
at least want to let a big outfit use a HELO value of domain.com on
all of its SMTP servers.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 08 May 2003 15:18:02 -0400

Paul Judge <[email-masked]> wrote:
> http://www.monkeys.com/anti-spam/filtering/additions.html

  That last link describes a method to attempt to discover *implicit*
consent, based on information in DNS.  e.g.

  For client/domain Y claiming to be in domain X, consent is implicit if:

    - domain X has an MX record that contains/names domain Y

  They further say:

   "... we should be generous and liberal in our attempts to
    ``correlate'' the envelope sender domain name with the SMTP client
    that is sending us the mail, ..."

  Which I interpret as acknowledging the method is trying to discover
implicit consent.

  RMX makes that consent explicit.  Further, RMX permits "wildcard"
consent to be applied to any network, so that with the consent of the
DNS administrator, dial-up users can claim to be within a domain, in
situations where it is otherwise difficult to discover implicit
consent, based on assumptions about use of domain names.

  Alan DeKok.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 8 May 2003 13:32:26 -0600 (MDT)

> From: Hadmut Danisch <[email-masked]>

> name, but deliver for many different domains. 

That check is only the first check.  If it fails, then no harm is done. 

Moreover, as was recently discussed in this mailing list, a host can
have many reverse DNS names.  See the thread that contains
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg04280.html

Note that I've removed the test case mentioned in that message. 
If there is any doubt that it worked, I can easily restore it.

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 22:09:05 +0200

> http://www.google.com/search?q=match+sender+domain+hotmail 

Paul, you will not seriously ask me to comment a google search 
reply. That's ridiculous. Please state exactly what you would like to
have comments on. Do you believe this is the way to chair a working
group? 

> comparison between those and RMX?

- The monkeys approach doesn't work in general. It works only for 
  the large providers like hotmail, yahoo, AOL, where all incoming and
  outgoing mails do have the same domain. 

- As they say, they need a list of "frequently forged domains". A 
  message is rejected only if the domain part is on that list.
  It's obvious that this doesn't work in common. You always need to 
  update such a list, which is expensive and error prone. Once this 
  gets commonly deployed, spammers will stop to use hotmail, yahoo,
  aol, but choose to use any random domain address.

  Keep in mind that spammers have lists of millions of email
  addresses. It's trivial to choose random domains from that list.

- It is based on a "relation" between the sender domain name and
  the name given in reverse domain names. This won't work in common. 

  Again, this is a hack limited to hotmail, yahoo and aol.

  But in most other cases it won't work. 

  A common case:

  You are sending mail from   [email-masked]
  and do deliver it through a machine which's reverse name 
  is   mta.provider.com

  regarding to the given web page at monkeys, I'll discuss 
  the four cases described over there. In my example

  X = yourdomain.de
  Y = relay.provider.com

  First case: Are X and Y the same? No.

  Second case: Is X a superdomain of Y? No.

  Third case: Does X have an MX record that contains/names domain Y ?
    Assume the MX record of X points to "relay.yourdomain.de"
    -> No

  Fourth case: Does X have an MX record that contains/names a
    superdomain or subdomain of Y ?

    Same as above.

  Therefore, this algorithm gives false results in many cases.

- The reverse domain name thing is vulnerable to name spoofing.
  Thus, the reverse-forward-check is needed. Interesting, this
  check fails in many cases.

- If you do read the monkey proposal further, you will see that
  they didn't even implement this, but make heavy use of a so
  called "list of frequently forged domains".

  It's obvious that this doesn't work reliably, must be updated 
  all the time, and is in principle a bad way of blacklisting, 
  because the domain owners can't do anything against it. 

So the differences between this and RMX are obvious. 
The Monkeys approach is a hack tailored to hotmail, yahoo, aol
and alike, it's bad design, it gives wrong results, it requires
maintenance of a blacklist, where people listed on that list don't
have any chance to get off that list, and which can easily be
circumvented by choosing a random domain for spamming.

Please, don't ask me again to provide a comparison of apples and
oranges.

Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 22:58:02 +0200

> That check is only the first check.  If it fails, then no harm is done. 

Great. A check that doesn't work in common, that does not much 
more than "no harm", and which's behaviour cannot be specified
in a technical or scientific way. 

That's indeed a great example of security engineering.

Hadmut

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 May 2003 17:47:00 +0000

> 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 [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 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-masked]'s account has a

   Vixie                         Experimental                      [Page 4]

   RFC XXXX                  Repudiating MAIL FROM             May 26, 2002

   ".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. 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-masked]> 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-masked]

   Vixie                         Experimental                      [Page 6]

---

From: David Walker <[email-masked]>
Date: Fri, 9 May 2003 01:31:33 -0500

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: [email-masked] on behalf of [email-masked]"

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

---

From: J C Lawrence <[email-masked]>
Date: Thu, 08 May 2003 23:51:33 -0700

On Fri, 9 May 2003 01:31:33 -0500 

>> Distribution of this memo is unlimited.

-0.5 [1]

> Due to interactions with internet mailing lists I personally feel that
> the comparison should be against the envelope-from ...

+1 

Its not clear to me from Paul's posting that he doesn't mean the
envelope.  

> ... instead of mail-from and that differences between the
> envelope-from and mail-from should be displayed in the MUA.  

Quite, tho Outlook's habit of quoting that disparity in its attributions
bugs the crap out of me.

1) http://www.python.org/peps/pep-0010.html
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Thu, 8 May 2003 22:06:02 -0700 (PDT)

RMX, MAIL-FROM, DSDNSBL all fail for mailing lists and for forwarding no 
matter if you compare it to "MAIL FROM" or to envelope "From" header or both.

Envelope "From:" is the worst case since most mailing lists use their own 
mailfrom and do not change "From:" (do not assume that what you see in 
outlook is what others would see or that its really how mailist messsage 
looks like), so when your message arrives and mailfrom-aware recepient 
server checks and sees that envelope "From:" is from domain that has 
mailfrom record but connecting mailserver is not on list of those domain
outgoing mail servers, then it would reject that email - to deal with this 
you have to whitelist maillist to let it through. But if you whitelist 
maillist then spammer can use that and forge "mailfrom" to appear that 
message is coming out of maillist and then your server will accept the 
email eventhough it came from spammer and eventhough he did not have 
right to use this envelope "From:".

If you use MAIL FROM header then you are able to accept emails from most 
mailing lists but its trivial for spammer to choose some domain for 
mail-from that has no mailfrom record but since most users consider 
"From:" as sender of the message, this still means spammer can appear to 
have sent email from address when he has no right to do so. In addition 
there is a bigger problem with forwarders and with maillists that 
actually use the original MAIL FROM (how many times have you received 
bounces from end-user servers when you send email to mailing list? - by 
SMTP specs all bounces go to MAIL FROM). And again a reminder - "MAIL FROM" 
is address for sending bounces - it is not the best idea to use as 
the only means of verifiyng origin of the email.

Add to this that some mail service providers (such as hotmail) mark as spam 
all emails that do not have the same email address for MAIL FROM as for 
envelope "From:". This leads to blockage of pretty much any maillist and 
forwarder of mailfrom or rmx where to be used.

I do belive that making originator verification linked through DNS is a 
good idea and some sort systems which has original in RMX or Mail From 
proposals can be used as part of larger solution but not something as 
simple as just checking an ip of connecting mail server.

And remember - when evaluating proposals that effect STMP routing (but do 
not replace it with new protocol) you have to consider transition situation
as being of the most importance - i.e. when some are aware of your changes 
to email system but most are not (this can go on for 5-10 years!). That a 
proposal might work if everybody has upgraded can in fact lead to failure of 
proposal if its initial impact is too high. Such would be the case with 
RMX since if any large domain setup such record (and large domains such as 
aol, hotmail, msn, etc are the ones most often forged) and their user's 
emails are bouncing, they will soon remove it and not try it again. 

This will probably be my only post on current ongoing mailfrom & rmx 
discussion, though I'v extensively commented on this before on this 
mail list. I'm not against these proposals, but having evaluated them 
I do not believe any current ones will work and I'm convinced their 
implementation will lead to more harm then good.

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 9 May 2003 09:58:07 +0200

>    Status of this Memo

This is in principle the same approach as RMX, but a different
implementation. (i.e. it lists the IP addresses of machines
authorized to deliver in DNS, it differs in the way those addresses
are stored).

It is very astonishing that it is Vernon who brings that proposal.
Concerning Vernon's objections against RMX, there is no difference
between RMX and this proposal. So why should those objections 
apply on RMX, but not on that proposal? The effect that use of 
a certain domain as a sender address will be limited to some
IP addresses as well. It will require DNS queries as well. 
It will require hotmail, yahoo, aol users to deliver through
the hotmail/yahoo/aol relays as well. So what's the point in 
quoting that proposal in context of the objections against RMX?

The advantage of Paul Vixie's proposal is, that it doesn't require
a new DNS RR type. 

The disadvantage is, that it is error prone and takes a high overhead:

There are providers who provide services for 20..2,000,000 domains. 
Since in this proposal the domain zone tables must list every single
mail relay, all zone tables must be updated if the provider installs
an additional relay. If the provider does have access to the zone
tables, this is just a heap of work. If the provider does not have
access to the zone tables, then it is a severe overhead and delay
to inform all the domain owners and ask them to update their tables.
When writing your domain table, you need a detailed list of the 
relays your provider has. At least you need to know the number of
relays. In reality, it would certainly look like this:

.. MX  relay0.provider.com
       relay1.provider.com
       relay2.provider.com

But you will always have to update the list if the provider uses
one more relay than you have listed. 

That's why RMX uses an indirection step through the provider's 
APL records. It's a design criterion to avoid this overhead and
delay.

Hadmut

---

From: Mike Rubel <[email-masked]>
Date: Fri, 9 May 2003 01:51:59 -0700 (PDT)

[ regarding why you believe Vixie's proposal is preferable to RMX ]

JCL> It also has the advantage of not changing its behaviour significantly 
JCL> as penetration thresholds grow.

Hi J.C.,

I dont't quite understand what you mean by this; could you please clarify?

Thanks,
Mike

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 9 May 2003 11:13:37 +0200

> matter if you compare it to "MAIL FROM" or to envelope "From" header

We have already discussed this issue on the mailing list several
weeks ago and came to the conclusion that it doesn't break mailing
lists. I have also addressed this issue in the second version of
my draft.

Would you mind to inform yourself before posting such claims?

Hadmut

---

From: Mike Rubel <[email-masked]>
Date: Fri, 9 May 2003 02:35:43 -0700 (PDT)

On Fri, 9 May 2003, David Walker wrote:
> 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)

Agreed: Vixie's proposal, like Feyck's, seems to accomplish much the same
outcome as RMX.  There are tradeoffs among them; RMX requires a new
resource record, but the other two hit DNS harder, for example.  The
similarities far outweigh the differences, though.  I'm most familiar with
RMX, but would not disappointed if either of the others took hold.

For now, assuming no new or important side-effects occur to me, please
regard my support for RMX as support for any of the three.

Mike

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 9 May 2003 10:06:13 +0100

> difference between those and RMX to show why you say that it is 

Please also check out the DMP (a.k.a. DS) proposal which does not 
require a new RR, and does not mean that the UDP size limit for DNS 
would be exceeded on a regular basis.

<http://www.pan-am.ca/draft-fecyk-dsprotocol-02.txt>

I don't recall seeing anyone respond to the size limit problem with RMX 
when asked about it, but then I also had to stop reading this list for 
a while.

Matt.

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 9 May 2003 13:56:33 +0200

> when asked about it, but then I also had to stop reading this list for 

I agree that this proposal does provide DNS answers with a better 
defined length and does not require a new RR type.

But I do not agree that this is a real problem of RMX. RMX uses
an indirection step, which keeps the RMX records small. 

And this proposal has a similar disadvantage like Paul Vixie's:
Whenever a provider changes the relay structure, it requires
immediate update of all zone tables. While in Paul Vixie's proposal
DNS names can be used and updates are required only if the 
number of relays grows, this proposal requires updates for every
single change. And if you really want to give a whole class-A network
permission, it requires 2^24 = about a million entries, still around 65000
entries for a class B network. This is a much more severe restriction
than the UDP packet size.

And you also have to keep in mind, that RMX, DMP and Paul Vixie's
proposal all fall into the same class, which is to store per-IP
authorization information in the sender address domain's DNS table.

If you take all the objections brought to this mailing list against 
RMX, these objections are not technical, not true or not arguable,
but however, if they apply, almost all of them apply to the whole
class of these DNS-based authorization methods. 

So moving to a different proposal doesn't contribute at this very
moment. It's a better step to move to the meta-layer and talk about
the whole class of these DNS-based methods. When this discussion is
finished then you can go back into the implementation details and
differences.

Hadmut

---

From: David Walker <[email-masked]>
Date: Fri, 9 May 2003 08:03:11 -0500

> right to use this envelope "From:".
In other conversations I have had all involved parties referred to "envelope 
from" and "mail from" as having the same meaning with "envelope" referring to 
the smtp transaction and "mail from" referring to the actual command used in 
the smtp transaction.  If this is not the case please substitute "mail from" 
for the term "envelope from" in my message.

> the only means of verifiyng origin of the email.
Not often.  and the list admins have corrected that behavior by now.
> forwarder of mailfrom or rmx where to be used.
That is current behavior.  It will not be made any better or worse by this 
design.
> simple as just checking an ip of connecting mail server.
I don't understand why not to do something simple.
> proposal might work if everybody has upgraded can in fact lead to failure
> of proposal if its initial impact is too high. Such would be the case with
Good error messages are good for everyone.  But I think you are guessing about 
their actions.
> implementation will lead to more harm then good.
When I get some free time I'm going to be harming my network then.

> > reasonably close to accepted standards and doesn't abuse them and it does
> > not require any programming changes on the DNS end.
> >
> > 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
> > >    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.
> > >       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.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."
> > >
> > >    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]
> > >
> > >    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.
> > >
> > >    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
> > > 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
> > >
> > >    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
> > >    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.
> > >
> > >    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]
> > >
> > >                 smtpreply(450, "temporary dns failure, try again
> > > later") break
> > >            case repudiated:
> > >    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
> > >
> > >
> > >
> > >    Vixie                         Experimental                     
> > > [Page 4]
> > >
> > >    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
> > >    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.
> > >
> > >    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.
> > >
> > >    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
> > >

---

From: David Walker <[email-masked]>
Date: Fri, 9 May 2003 08:12:49 -0500

> right to use this envelope "From:".

I re-read my message again and my use of the terms evelope-from and mail-from 
were just not done right.  Where I said "envelope from" I meant the "mail 
from:" part of the smtp transaction and where I said "mail from" I meant the 
mail's "from:" header.  But there really isn't any way people could know that 
from reading my message. (I will blame the late hour but I should have been 
more careful)

If the "from:" header doesn't match the "mail from" that the MUA should 
indicate that to the user.
if the "mail from" doesn't pass the MX MAIL-FROM lookup then the mail should 
be able to be denied.
If the "from:" header doesn't pass the MX MAIL-FROM lookup then a warning 
might be in order but not a deny since that would disable mailing list 
action.

Sorry for the confusion.

---

From: [email-masked]
Date: Fri, 9 May 2003 04:13:51 -0700 (PDT)

I looked at new version or proposal briefly and will reread it in fully as 
I plan to read fully all that is contained in the archive last month. But 
the problem is more fundamental that new version can not possibly address.
I would go as far as to say that its theoreticly impossible for RMX to do 
what it is supposed to do without breaking maillists and similar mail relay 
services because of the very basis of design for these proposals.

RMX and other similar proposals are there to verify mail sender (that person
or machine sending email) is authorized to use particular domain in the from
address. But validation is done by ip of the connecting mail server and 
that means you're substituting one-hop (server-server) verification where 
you actually want end-end verification. If you go by mailpath A->B->C 
where A is origin and B is intermediate server, then by the very design, 
best RMX can do for destination C is verify conversation and something about 
site "B" but not anything about site "A" which is the origin. The 
proponents will all say that if everybody is doing it and if B validates 
A and C validates B then its the same as that C validates A but that is 
where problem lies we do not have persistency of trust on the mail path 
so if C validates B, what we have is that "C verfied that B is using some 
third-party domain and that it is claiming that it has verified C".  The 
word "claiming" is the problem here, we have substituted real verification
of mail origin (which is what we wanted) for verification that some domain
being supplied by connecting server is there - that is all! And we all 
know that domains are pretty easy to get hold of for spammers and tracing 
by domain is actually less valuable then tracing by ip!

There are several ways to get around the above problem. One is to have 
clear way for C to verify that email passed through A, i.e. that sender 
network is aware that some mail originated there (this is mail tracking 
- I'll mention this again in details later and have already discussed this 
before in my notes). Another way is to use crypto signatures to provide 
necessary trust - that is either email itself is entirely signed (S/MIME, 
PGP, etc) or possibly it includes some token that we know only orign server 
could have included (i.e. token can be verified from dns) - this is hashcash
and similar proposals. In all cases we would need to have destination contact
some service at origin domain to verify something about the email (like
tracking data, crypto key or signature, CRL, etc) just like RMX proposal 
does it (i.e. dns check), so this basic idea would be used no matter what!

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 9 May 2003 16:26:22 +0200

> services because of the very basis of design for these proposals.

Please elaborate, how RMX would break e.g. the [email-masked] mailing
list.

Hadmut

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 9 May 2003 08:41:41 -0600 (MDT)

> quoting that proposal in context of the objections against RMX?

What is astonishing about trying to be honest and forthright?  Those
of my objections to RMX that are also relevant to Paul's notion
certainly apply.  I did write:

] - I do not like this scheme, because I do not agree with the goal of
l    forcing people to use the same going as incoming ISPs.

> an additional relay. 

I do not understand how which files must be edited differs among the
RMX varients.  I also do not understand how one can make any general
claim in that regard because the most popular DNS server implementations
have features like "include" statements to include other files.

>                      If the provider does have access to the zone

I do not understand how a provider that should be controlling RMX-like
records is likely to not have access to teh zone tables.

> APL records. It's a design criterion to avoid this overhead and

An example contrasting the records for the two proposals might
make that clear.

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 09 May 2003 11:50:27 -0400

> services because of the very basis of design for these proposals.

  I disagree.  You are operating under two misconceptions:

    1) Everyone is required to implement and use RMX

    2) Everyone is required to implement and use ONLY RMX.

  I would suggest that Hadmut add text to his draft saying something
like:

  "Sites implementing RMX verification are free to NOT perform that
   verification on whitelists of addresses/domains, if they so
   choose."

  Alan DeKok.

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 13 May 2003 13:03:02 +0100

[email-masked] wrote on 09 May 2003 at 06:06

>looks like)

Sorry, I will make that assumption.  So will you, if you know what you are
talking about. So far as I can see, Outlook will display the headers exactly
as received, except that it wil add a Sender: header where relevant in
conformance with the standard. Since RFC2822 headers are distinct from
RFC2822 content they are of course displayed in a different window from the
content, which is useful behaviour since the headers are long and it would
be boring to have to skip over them every time (certainly I used to find it
that way in the days of MUAs which displayed header plus content as a single
unit).

I've appended below the email headers that Outlook reports for the message
to which I am replying.  If you think any of these is not correct (ie
Outloook has got it wrong) please let me know and I'll take it up with M$.
If you don't think any of it is wrong, perhaps you'll not make silly
accusations about Outlook in future.

Tom

Received: from www1.ietf.org ([132.151.1.19]) by mail.neosinteractive.com
with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 9 May 2003 13:29:26 +0100
From: [email-masked]
To: [email-masked]
Subject: Re: [Asrg] Re: RMX evaluation / Paul Vixie's procedure
Sender: [email-masked]
Date: Thu, 8 May 2003 22:06:02 -0700 (PDT)
FILETIME=[A15052B0:01C31626]

---

From: [email-masked]
Date: Tue, 13 May 2003 02:48:51 -0700 (PDT)

You'v already answered your own question. The client/end-user mail reader 
is adding "Sender:" header to the email, that is not a proper behavior, 
the sender should be added by sending MUA or MTA. Your example does not 
really illustrate that behavior of Outlook since "Sender:" header is 
already part of the message having been added by ietf maillist remailer.

In addition your example illustrates yet again what I said since less 
sophisticated users (read 99% of users) who use outlook only see one 
"From:" and one "To:" headers which are part of the header/body of the 
email but you do not see the "MAIL FROM" and "RCPT TO" email used during 
transmission and these are really the ones used for actual delivery.

The problem is that if you were using "From:" header for RMX validation 
you would as in example below see "[email-masked]" but actual message 
came from "ietf.org" server and so the mail would not be validated and 
would fail RMX. Using "Sender:" headeris also not possible since "Sender:" 
could have been set by by MUA (mine is configured not to do that) and then
there are different maillist programs and majority will actually not set 
"Sender" or will not reset it to themselve if header already exists 
(some will add 2nd "Sender:" header, but this is rare and considered a bug,
though I think RFC2828 does not explicitly forbid this), so again it fails 
with mail lists. This leaves MAIL FROM to be used for RMX validation and 
this is what all current RMX-like drafts propose. But as you quite well 
illustrated the MAIL FROM is not even seen by end-users and it means 
spammer can use one domain for MAIL-FROM (which would random domain 
without any RMX record) and use another domain for "From:" and most users 
will still consider email as having come from the listed "From:" address.
And as for the "Sender:" header, spammers quite often set that as well.

On Tue, 13 May 2003, Tom Thomson wrote:

> Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
> 	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4982I811640;
> 	Fri, 9 May 2003 04:02:18 -0400
> Received: from ietf.org (odin.ietf.org [132.151.1.176])
> 	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h497xr811361
> 	for <[email-masked]>; Fri, 9 May 2003 03:59:53 -0400
> Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
> 	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08152
> 	for <[email-masked]>; Fri, 9 May 2003 03:49:32 -0400 (EDT)
> From: [email-masked]
> Received: from ietf-mx ([132.151.6.1])
> 	by ietf-mx with esmtp (Exim 4.12)
> 	id 19E2fG-0002N4-00
> 	for [email-masked]; Fri, 09 May 2003 03:51:34 -0400
> Received: from sokol.elan.net ([216.151.192.200])
> 	by ietf-mx with esmtp (Exim 4.12)
> 	id 19E2fF-0002N1-00
> 	for [email-masked]; Fri, 09 May 2003 03:51:33 -0400
> Received: from sokol.elan.net (localhost.localdomain [127.0.0.1])
> 	by sokol.elan.net (8.12.5/8.12.5) with ESMTP id h495627W017107
> 	for <[email-masked]>; Thu, 8 May 2003 22:06:02 -0700
> Received: from localhost (william@localhost)
> 	by sokol.elan.net (8.12.5/8.12.5/Submit) with ESMTP id h49562ML017103
> 	for <[email-masked]>; Thu, 8 May 2003 22:06:02 -0700
> X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
> To: [email-masked]
> In-Reply-To: <200305090131.33356@grx>
> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Errors-To: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.12
> Precedence: bulk
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
> 	<mailto:[email-masked]?subject=subscribe>
> List-Archive: <https://www1.ietf.org/pipermail/asrg/>
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 09 May 2003 12:29:26.0747 (UTC)

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 09:24:04 -0400

I've started a new thread to discuss list detectiom just to be search engine
friendly.

There seem to be a variety of methods that lists use including preserving
the original sender as well as sending witht the list's email address.  This
particular list sends with the list's email address.  For C/R systems, this
often works fine because you often have to send to a list-subscribe in order
to join the list.  A C/R will then send a challenge to the list and
subsequently get denied.

For lists that preserve the sender's email address, a C/R system can be a
bit unfriendly.  However, we have seen that most list's use a "Sender"
header somewhere inside the message body.  for example, this list sends:

If we encounter such a header, we will then not challenge the sender but
will require the user to take an action.  I'm not trying to have another C/R
discussion but rather am interested in the various list detection methods
available.  I've sorted through procmail to see what methods are available
to that source and the above was the best I could come up with.

An extremely important issue for large email companies is that spammers send
email to their users using their own domain.  For example, they send to
[email-masked] from [email-masked].  One might say, "Gee, just don't permit
mail from the outside using your domain".  That works everywhere except for
lists that preserve the sender address.

So somehow, we have to prevent someone from spoofing the local domain while
permiting various mailing list types.

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 13 May 2003 14:23:53 +0100

>already part of the message having been added by ietf maillist remailer.

Two points there: first, MUAs can add Sender: headers - there's nothing in
the standard to stop them doing so, and as the intention of this header is
to reflect the case where envelope MAIL FROM does not match content From: it
is preferable for an MUA to add such a header where appropriate; second,
when I said that Outlook might add Sender: when appropriate I was reporting
something I've been told, not something I've observed (I suppose I should
have made that clear) and although I would prefer it to add Sender: where
appropriate it may be that it actually has your prefered behaviour (not add
Sender: even when appropriate).

>transmission and these are really the ones used for actual delivery.

The question for RMX (or the Vixie proposal, which is equivalent so far as I
can see) is not what an end-user sees (whether that's an unsophisticated
user or a sophisticated one) but what the MTA carrying out the check sees.
It sees the envelope MAIL-FROM which is the only thing it can check (an MTA
can't examine the content, it may be encrypted with a key the MTA doesn't
have, it may not conform to any standard the MTA knows about, and so on. It
can prefix the content with a Received From: header, since that doesn't
require understanding the existing content, but it can't reliably do
anything else to the content and in principle it shouldn't try.

<snip>

>This leaves MAIL FROM to be used for RMX validation and

However, it doesn't mater whether MAIL-FROM is seen by end users. All these
RMX and RMX-like proposals offer is assurance that the MAIL-FROM: header was
not invalid for the MTA from which the mail was received, and so far as I
know they have never purported to do any more than that. They provide a
hop-by-hop check, in effect, not a source to destination check.

However this is a defect of the RMX approach, and verification of the
original source would be much more useful.  I have stated my preference for
a cryptographic often enough.  A new DNS record specifying a key would be
much nicer, and there's no need for certificates or TTPs.  It doesn't
require any more change to existing standards than Vixie's proposal does,
provided that one doesn't expect it to carry across list expanders or other
functions that change the envelope MAIL_FROM without some intelligent
processing by the expander, since conformant transmitters could carry the
signature as part of the helo/oleh.

Tom

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 13 May 2003 17:28:19 +0100

> to that source and the above was the best I could come up with.

There's lots of good code in SpamAssassin that I added to detect 
legitimate mailing lists. It would probably be a good starting point 
(and it's easy to find - look for the file called "MailingList.pm").

But I don't quite understand. Spammers don't care much who they send 
to, and the bad ones just want to not have to process bounces (which is 
why they use freemail or forged return paths). Surely if you do this 
the spammers are just going to add enough headers in to look like a 
"legitimate" mailing list, and thus force the user to take the action?

I'm speculating, of course, but I don't think it will take long for 
them to decide to do that if it gets widely implemented (spot the 
number of spammers taking steps to bypass SpamAssassin now).

Matt.

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 14:01:41 -0400

> "legitimate" mailing list, and thus force the user to take the action?

Forcing the user to take an action is not a bad thing.  Everyone wants 100%
of their spam dropped with 100% of their valid mail delivered.  Valid mail
is in the eye of the beholder...therefore, there requires beholder actions.
Dropping spam on a server before it's previewed via a client software or via
a browser has significant advantages.

> number of spammers taking steps to bypass SpamAssassin now).

Some would argue that spammer would prefer receiving challenge messages and
auto-click any links within the message.  Therefore, mimicking a mailing
list, thus disabling challenges, would mean that a user would just drop the
message without the spammer getting on the whitelist.

It can be argued either way..therefore a spammer will do both.

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 13 May 2003 20:17:02 +0100

> APL records. It's a design criterion to avoid this overhead and

Wouldn't it be fairly easy to overcome this problem pretty trivially?

For example 
	- allow wild card characters in the record, or
	- specify the containing domain rather than the fully qualified name, or
	- use the same indirection as the RMX proposal

Tom