[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] Re: RMX evaluation / Paul Vixie's procedure
On Friday 09 May 2003 12:06 am, william@elan.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@ietf.org on behalf of paul@vix.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@ISC.ORG, the following DNS MX RR's
> > > should be entered:
> > >
> > > $ORIGIN isc.org.
> > > MAIL-FROM MX 0 rc
> > > MX 0 rc1
> > >
> > > In this example, hosts RC.ISC.ORG, and RC1.ISC.ORG are given as
> > > appropriate places to originate mail from @ISC.ORG. Note that this
> > > differs from the normal inbound MX RRset for this example domain:
> > >
> > > $ORIGIN isc.org.
> > > @ MX 0 rc
> > > MX 0 isrv4
> > >
> > > So, the inbound mail server set partially overlaps with, but differs
> > > from, the example outbound mail server set. This is quite common in
> > > the Internet, and is the reason why the normal inbound mail server set
> > > described by a domain's apex MX RRset cannot be used for repudiation
> > > purposes.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Vixie Experimental
> > > [Page 2]
> > >
> > > RFC XXXX Repudiating MAIL FROM May 26,
> > > 2002
> > >
> > >
> > > 2.2. Second-stage relays such as ISP mail servers are often used and
> > > can be described by adding as many relays as necessary to the MAIL-FROM
> > > MX RRset. In our example, if ISC sometimes used UUNET for outbound
> > > mail services, the DNS data describing this relationship might be as
> > > follows:
> > >
> > > $ORIGIN isc.org.
> > > MAIL-FROM MX 0 rc
> > > MX 0 rc1
> > > MX 0 uunet.uu.net.
> > >
> > > Let it be noted that a domain owner's power to repudiate forged
> > > e-mail is only as strong as the security policy of its registered
> > > inbound and outbound mail relays, and that if such a relay is (for
> > > example) open to third party relay, then no value will be added by
> > > registering a domain MAIL-FROM MX containing that relay, and no inbound
> > > MAIL-FROM checking will be possible on final delivery relays for a
> > > domain @ MX containing that relay. Multistage relays (both inbound and
> > > outbound) are a breeding ground for anonymity unless they are very
> > > carefully configured.
> > >
> > > 2.3. SMTP receivers wishing to attempt repudiation on inbound e-mail
> > > would check the SMTP (see [RFC2821]) MAIL FROM payload at the time
> > > of receipt. The precise method to be used is as follows:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Vixie Experimental
> > > [Page 3]
> > >
> > > RFC XXXX Repudiating MAIL FROM May 26,
> > > 2002
> > >
> > >
> > > on (MAIL FROM mailfrom) {
> > > switch (repudiated(mailfrom, ipsource))
> > > case tempfail:
> > > smtpreply(450, "temporary dns failure, try again
> > > later") break
> > > case repudiated:
> > > smtpreply(550, "surely you're joking")
> > > dsn("5.7.1", "delivery not authorized")
> > > invalidate() // reject all but QUIT and RSET
> > > break
> > > }
> > > }
> > >
> > > repudiated(mailfrom, ipsource) = {
> > > (lhs, rhs) = parse_addr(mailfrom);
> > > // handle "MAIL FROM:<>" somehow
> > > mxset = get_mx("MAIL-FROM" "." rhs);
> > > if (mxset == NULL)
> > > return nonrepudiated;
> > > mxset += configured(perimeter_relays);
> > > foreach mx (mxset) {
> > > aset = get_a(mx.server);
> > > if (ipsource IN aset)
> > > return nonrepudiated;
> > > }
> > > return repudiated;
> > > }
> > >
> > > (EDITOR'S NOTE: need to establish a value for 5xx.)
> > >
> > > The method amounts to "if there's a MAIL-FROM for the purported
> > > domain and if the IP source isn't on the resulting list, then reject
> > > the mail". Multistage inbound relays are allowed for, by implicitly
> > > appending one's own outer perimeter relay names to every extant
> > > MAIL-FROM.
> > >
> > > 3 - Impact
> > >
> > > 3.1. This specification is optional, and will only affect
> > > cooperating parties. Any domain owner who does not enter a MAIL-FROM
> > > will be unaffected, and any SMTP receiver who does not look for a
> > > MAIL-FROM at time of receipt will be unaffected. However, both parties
> > > working together CAN work to repudiate forged e-mail return/source
> > > information.
> > >
> > > 3.2. Transport-level e-mail forwarding must be more explicit under
> > > this specification. For example if VIXIE@NETBSD.ORG's account has a
> > >
> > >
> > >
> > > Vixie Experimental
> > > [Page 4]
> > >
> > > RFC XXXX Repudiating MAIL FROM May 26,
> > > 2002
> > >
> > >
> > > ".forward" file pointing at VIXIE@ISC.ORG, then e-mail sent to the
> > > former will be received by the latter, but with no change in the
> > > payload of SMTP MAIL FROM. Thus, ISC's inbound relays would have to be
> > > configured to implicitly add NETBSD's outbound mail relays as
> > > "multistage inbound relays." This could scale poorly and may add
> > > pressure toward transport remailing (with a new envelope) rather than
> > > transport forwarding (reusing the old envelope.)
> > >
> > > 3.3. Roaming hosts such as laptop computers will probably not be
> > > able to be listed in the MAIL-FROM MX RR for their return address
> > > domain name, and may be forced to use an intermediary for outbound
> > > e-mail. STARTTLS or an SSL/SSH tunnel back "home" may become a
> > > necessary first hop for mobile e-mail.
> > >
> > > 3.4. The likely endgame for this behaviour is to force senders of
> > > unwanted bulk e-mail to stop lying about who they are, which is
> > > illegal in meatspace anyway -- but such laws are unenforceable due to
> > > the nature of the Internet's mail system. Under this proposal, any
> > > domain owner who is the victim of forgery can respond by adding
> > > MAIL-FROM data to their DNS zone, and any relay owner who is the victim
> > > of forged unwanted e-mail can respond by checking for MAIL-FROM data
> > > upon receipt of all incoming e-mail.
> > >
> > > 3.5. The DNS TTL for MAIL-FROM MX RRsets ought to be shorter than
> > > for the corresponding domain's apex MX RR, since the cost of widely
> > > cached wrong information is much higher for outbound repudiation data
> > > than for inbound delivery data. Consider that an incomplete apex MX RR
> > > can cause mail to be delivered by a suboptimal path, whereas an
> > > incomplete MAIL- FROM MX RR can cause valid mail to be rejected by
> > > relays who attempt repudiation.
> > >
> > > 4 - Security Considerations
> > >
> > > In the continuing absence of widely deployed security for DNS, this
> > > proposal effectively places an access control list for forged
> > > source/return information in a place where it can be attacked.
> > > However, it must be noted that the current senders of forged unwanted
> > > bulk e-mail are typically not technologically capable of attacking the
> > > DNS to insert forged MAIL-FROM data.
> > >
> > > 5 - Acknowledgements
> > >
> > > This idea originated with Jim Miller <jmiller@jcmco.com> in 1998.
> > >
> > >
> > >
> > >
> > >
> > > Vixie Experimental
> > > [Page 5]
> > >
> > > RFC XXXX Repudiating MAIL FROM May 26,
> > > 2002
> > >
> > >
> > > 5 - Author's Address
> > >
> > > Paul Vixie
> > > 950 Charter Street
> > > Redwood City, CA 94063
> > > +1 650 779 7000
> > > paul@vix.com
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Vixie Experimental
> > > [Page 6]
> > >
> > > _______________________________________________
> > > Asrg mailing list
> > > Asrg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/asrg
> >
> > _______________________________________________
> > Asrg mailing list
> > Asrg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/asrg
>
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg