ietf-asrg
[Top] [All Lists]

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

2003-05-09 06:04:39
On Friday 09 May 2003 12:06 am, william(_at_)elan(_dot_)net wrote:
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:".
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.

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.
Not often.  and the list admins have corrected that behavior by now.

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.
That is current behavior.  It will not be made any better or worse by this 
design.

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.
I don't understand why not to do something simple.

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.
Good error messages are good for everyone.  But I think you are guessing about 
their actions.

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.
When I get some free time I'm going to be harming my network then.


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)

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

_______________________________________________
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