Re: Mail-Transmitter RR

[Paul Vixie <paul@vix.com>]

> From: David Green <green@couchpotato.net>
> 
> Paul, your proposal is thought out much better than mine. However, I
> don't agree with overloading the MX RR to make this happen. I think
> that using an SRV RR would be a better choice, as this might lead to
> domain authentication of other services in the future: [...]

We would be overloading SRV just as much as the current proposal does MX.
More to the point, the patch to sendmail to implement MAIL-FROM is less
than 100 lines if MX is used.  Given the number of disparite code bases
out there, ease of implementation will translate directly to the growth
of an installed base.

>     out.smtp.tcp SRV 0 0 smtpsender.asdf.com
>     out.http.tcp SRV 0 0 httpproxy.asdf.com
> 
> Perhaps even put source port-numbers in there as well...

Unless there's something _needed_ that SRV provides (load balancing,
port numbers) I think it would be better to avoid it.  And I speak as
an author of the SRV RR when I say that in this case.

> From: Derek Atkins <warlord@MIT.EDU>
> 
> The problem with this proposal is that only the first-hop can actually
> check the message.  All the spammer needs to do is find an open relay
> that does not implement the "remove the Authorized-by header" and they
> are home free, and even this MAIL-FROM technique wont help.
> Considering that spammers are already utilizing open relays, this
> isn't really a big change for them.  So even if people opt-in to this
> proposal, I don't see it actually helping.

I've strengthened the wording on [MAILFROM 2.2] which now reads:

   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.

I think that there's a LOT of help to be had from this, amongst anonymous
but cooperating domain owners and relay owners.  I'm not pushing this as
the one true way to stop all spam for all time, because I don't think there
is any such.  It's an optional, low-impact way to protect folks like hotmail
from widespread forgery.  Probably it won't slow spam down one whit, but it
will reduce the overall injury from spam.

> Unfortunately second-hop mail proxies can't perform the same check on
> the MAIL-FROM, because all they have is the Received-By headers.  In
> fact, how is an MTA supposed to know whether it is the first-hop or not?

For the record, I'm against header munging and against Received: parsing by
MTA's.  Both are layering violations, though of different kinds.  The right
solution is to know and trust the configuration of your @ MX relays and also,
if you choose to use MAIL-FROM, of your MAIL-FROM MX relays.  The text above
strengthens the case for this requirement, which is in fact already present
in the existing mail system in any case.

> Also, without DNSsec the spammer could try DNS forging attacks as well.

OK, so I hate it when I have to quote something you've already seen, but:

   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.

You can call the above a cop-out if you want, but since we're moving a
problem from a solutionless arena (end-to-end MTA authentication) to a
solutionful arena (deploy DNSSEC) I consider the movement to be "progress."

> From: David Green <green@couchpotato.net>
> 
> > The problem with this proposal is that only the first-hop can actually
> > check the message.  All the spammer needs to do is find an open relay
> > that does not implement the "remove the Authorized-by header" and they
> > are home free, and even this MAIL-FROM technique wont help.
> 
> There should only be a single hop between separate logical entities on the 
> public Internet. The final sending host of the sending entity would need 
> to be marked as an authorized mail transmitter for the domain. Inside of 
> each entity, they can set up any rules they like.

If a cooperating set of MX's (inbound @ or outbound MAIL-FROM or both) wants
to implement such a scheme then it falls under the general category of
"knowing and trusting the configs of your domain's MX relays".  It's out of
scope for this proposal, but implementation experience, open source patches,
and a BCP would go a long way toward advancing this particular form of trust.

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