Re: Mail-Transmitter RR

[Paul Vixie <paul@vix.com>]

there are three replies contained here, plus a big finish.

--------

> From: Randy Bush <randy@psg.com>
> 
> the problem is that this is really a side-eddy to the spam maelstrom.
> this discussion is about all sorts of hacks to allow one to force the
> source of the mail to be honest about whence it comes.  while this is
> nice, it is indirect and merely gives you a slight leg up on chasing
> ten thousand slimeballs.  it is like trying to use source spoofing
> prevention to stop ddos attacks, a useful tool but not a real solution
> by a long shot.

that's all spam-related and it's from the perspective of the recipient.

this proposal is not about spam, and the primary expected beneficiaries
are domain owners who presently have no power to repudiate forgeries of
their intellectual property.

at the moment, the "abuse@hotmail.com" mailbox is full beyond overflow,
and 98% or more of the traffic is about incidents which hotmail's own
customers and servers had nothing to do with.  this is a DDoS against
an isp abuse/support desk which protects the flow of the other 2%.

> so how much should we mangle the net (prevent direct delivery of mail
> from laptops etc) for a partial approach to being able to assign
> responsibility to spammers who will ignore responsibility anyway?

my laptop will still deliver mail directly, either because i'll send it
from a domain with no MAIL-FROM, or because i'll use RFC2136 dynamic
updates on my own A RR (note: this is not DHCP or PTR related!) when i
travel.

--------

> From: Alan Barrett <apb@cequrux.com>
> 
> >       $ORIGIN isc.org.
> >       MAIL-FROM MX 0 rc
> >                 MX 0 rc1
> 
> I think that the magic label should begin with an underscore
> (e.g. "_MAIL-FROM"), for the same reasons that we use "_tcp" rather
> than just "tcp" as a label for SRV records.

i thought of that, but my concern is the number of extant getmxrr() 
library implementations who "just know" that a leading _ is invalid.
randy and others would be quick to point out that such implementations
are broken, but fixing them is going to add more inertia to the equation
and it's a battle i'd rather postpone.  MAIL-FROM is sufficiently unique
(i grepped a few gig of mail logs and found no occurances) that it ought
not have any collisions.

i still remember the debate over the _ in _tcp and _udp with the SRV RR,
and as an author of SRV i'd like to not tread that ground again so soon.

--------

> From: "Eric A. Hall" <ehall@ehsco.com>
> 
> > More to the point, the patch to sendmail to implement MAIL-FROM is less
> > than 100 lines if MX is used.
> 
> MX is not flexible enough by itself. At the very least, you also need a
> way to map PTR space to the sender domain such that EG anybody with a PTR
> of ehsco.com. is hereby authorized by me to send mail from @ehsco.com.[1]

that's a strictly local configuration issue, as everything PTR-related
must be and in every case will be.

> Also, having the ability to define specific hosts lets mobile users setup
> user.domain.dom mail domains on a dynamic basis, so you need a way to map
> in A/AAAA RRs as well.

see my comments above regarding my own laptop's choices in this scenario.

> I think that all of the above illustrates why you really need a new RR
> using codes (as in the mail I forwarded earlier), rather using a static
> owner name.

i think this debate illustrates why the ietf is so broken -- anyone can say
no and there's nobody anywhere who can definitively say yes (witness A6/DNAME
in IPv6, and RSA/DSA/RSA/DSA/etc in DNSSEC).

my big plan is to get as many good ideas as possible from this community
and then market this proposal in "ietf bypass mode".  it's completely
optional and specifies no wire protocol changes, and when it does
finally come through the ietf it will be as a successful and widespread
method which has become worthy of its own BCP.

you are welcome to roll out a custom RR in parallel.  BIND will support it,
and i will adopt it on my own servers, and if it happens to work, we'll all
be happier for it.  but i rather expect that you'll be shot in the back every
day for three years, told to use IPsec, told to use SSL, told to use PGP,
told to use S/MIME, told you're approved, told you're not, and so on.

--------

i keep thinking of how the world would be different if i'd helped jim miller
get this proposal written and circulated back in 1998 when he thought of it.

--
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/>