Re: Mail-Transmitter RR

["Eric A. Hall" <ehall@ehsco.com>]

Paul Vixie wrote:

> We would be overloading SRV just as much as the current proposal does MX.

Moreover, it overloads SRV in a bizarro way, defining a client rather than
a server. Avoid mangling the interpretation of SRV please, adoption is
slow enough as it is.

> 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]
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.

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.

[1] Two subordinate issues with PTRs. First of all, there must be a
mandatory forward-path verification of the PTR data, otherwise any idiot
can add a PTR to their in-addr space and spoof me, which solves nothing.
Second, remember that this option would only be definable by the owner of
the domain, so it couldn't be used as a casual attack even when the
forward lookups were not used.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

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