This doesn't adequately describe backup relays. If uunet is providing an
alternate relay service, then all or any of uunet's relays might be
providing that service. So it would have to be able to recursively look up
uunets mail-from mx's, and the mail-from mx's of any subdomains listed by
uunet. This process might contain loops.
Additionally, the mail forwarding behavior is highly undesirable. A large
mail site does not want to have to manually configure essentially the
whole of the internet as possible multi-stage mail relays so that its
users can forward mail from other servers to their mailbox. Indeed, even a
relatively small site would not want to do that.
However, even this approach won't stop spam, since a spammer will still be
able to use their ISP's mailservers, with a stolen, or disposable account.
There are plenty of KLEZ viruses out there, and plenty of stolen
passwords. And it won't have any effect at all on spam from real
commercial operators like Exactis who don't forge the from addresses.
Essentially, I'm convinced after years of interaction with some radical
anti-spammers that most of the non-commercial spam (and quite a lot of the
forged-address spam) is sent by anti-spammers trying to essentially
terrorize their way to some kind of technical solution that they think
exists. However, no such solution exists. If there were such a solution,
we could prevent all kinds of evils, like government corruption,
embezzlement, misuse of all kinds of property. But there is no substitute
for honesty and responsibility. If someone has possession of a privilege,
(however that privilege was obtained--it may have been stolen), and they
are so inclined to abuse that privilege, the only way to stop them is to
remove the privilege.
--Dean
On Sat, 7 Dec 2002, Paul Vixie wrote:
> it's difficult to imagine a mailing list for which this thread is on-topic.
>
> > I think it was Steve Bellovin that suggested a procedure for reducing the
> > utility of spoofing source addresses in emails; if not, it was me and I
> > happened to suggest something his favorite algorithm fit into, by having a
> > host in each mail domain (mailid.example.com) be able to assert that its
> > domain had or had not sent an email within a given recent time period
> > whose MD5 hash, when divided by <vector of prime numbers> resulted in
> > <vector of remainders>. I could write that up in an internet draft if folks
> > think it makes sense. That would be a more global procedure that didn't
> > require a PKI and only addressed spoofed addresses. --
>
> here was my attempt at this, which i didn't really know where to go next with:
>
>
>
>
>
>
>
> 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 PROTECTED], 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 PROTECTED]'s account has a
>
>
>
> Vixie Experimental [Page 4]
>
> RFC XXXX Repudiating MAIL FROM May 26, 2002
>
>
> ".forward" file pointing at [EMAIL PROTECTED], 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 PROTECTED]> 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 PROTECTED]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vixie Experimental [Page 6]
>
>
> --
> to unsubscribe send a message to [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
>
