At 10:10 AM 6/29/03 -0700, william(_at_)elan(_dot_)net wrote:
[edited]
On Sun, 29 Jun 2003, Richard Rognlie wrote:
RMX (et al) deal with the envelope from address. This proposal has
nothing to do with the envelope. It is an attempt to sanitize the
hostname specified as the HELO/EHLO when connecting to a remote
MTA.
IOW, If I connect to a remote MTA and my MTA sends the greeting
EHLO play.gamerz.net. That MTA can do a lookup of
my_ip_ad_dr._relays_._email_.play.gamerz.net and see immediately
that if it gets my.ip.ad.dr as the response, that, indeed, I am
a DRIP subscribed host. If any other host attempts to connect
and claim to be play.gamerz.net, the IPs will not match (or there
will be no record at all).
You can already do this by setting proper reverse dns ip for the record
and reverse dns does allow for multipe names for the ip. So this is a
a proposal that indends to allow equvalent of reverse dns check for
when company running mail server does not have access to set reverse
dns as it wishes.
That's not /entirely/ correct.
There's a way to do more than one reverse rDNS, but it
isn't generally practiced, and there's no way to deal with a machine
that has more than about 40 domains associated because of the
512 byte packet size limit in DNS. (Yes, there's a way to send
packets that are bigger, but that's even more broken.)
I suspect though, it would be easier to standardize
a way to handle that case, than get DMP/RMX/DRIP accepted.
(And yes, there are lots of IPs on the internet right now
that handle more domains than fit in a single packet.)
To illustrate another problem with multiple rDNS records,
consider the following hypothetical;
I run a mail server on my IP and it lists 10 rDNS records.
one is "mx35.yahoo.com" and the other nine are domains that
point to my IP.
That IP sends you an email that claims to be from yahoo.com.
Do you mark it as a probably forgery?
What about email that claims to be from loser(_at_)pacbell(_dot_)net and
originates from adsl-10-10-10-10.dsl.snfc21.pacbell.net?
These problems are not insurmountable, but they are problems.
a good rDNS implementation would need to deal with them,
and to do that means changes.
[...]
And going futher on this, I'v thought about it for a while actually and
came to conclusion that reverse dns records should be used to authenticate
servers (like now) but stronger authentication methhods should be used,
I'd favor SSL certificates, self-signed and tied to special reverse dns
record. And for those who can not control reverse dns a workaround can be
provided by having well known certificate authority also sell similar
certificates. I'll provide details on this and number of my other proposals
some time in the future, when I think through research group is a little
better organized...
Why rDNS? If you insist on digital signatures, then it shouldn't
be necessary to examine the transport layer /at all/.
Scott Nelson <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg