From: "Tom Thomson" <tthomson(_at_)neosinteractive(_dot_)com>
The RMX check as I understand it is intended to ask the people who own
the envelope sender domain name if the IP address of the SMTP client is
authorized to send mail with that sender name. If the HELO value matches
the sender name, and if one of the IP addresses of the HELO value is that
of the SMTP client, then the SMTP client is authorized.
So you are implyng an SMTP protocol change: the HELO line must specify a
domain name. If you are going to assume changes like that in your replies to
other peoples proposals, lets see your properly worked out proposal
containing all such changes.
When you write it up (if ever)
Why would I write it up when the authors of RFC 821 and RFC 2821
already did? Or have I misunderstood section 4.1.1.1 of RFC 2821 and
section 3.5 of RFC 821?
Please also consider the possibility that since I do not favor RMX,
I also do not favor this check. If the requirement that the HELO
value be the MTA's domain name were not more than 20 years old, I
would be unlikely to spend much time documenting it.
My point was that those who want to make the RMX check can achieve
about the same effect by by checking data that is already present,
standardized, and requires no new protocols or actions by 80% of the
Internet. Most mail already satisfies such a check, while it would
be many years if ever before a significant amount of mail would meet
a check involving a new DNS RR. This check is already well understood
by people familiar with dealing with spam. It is common among the
MTAs of those who prefer not receiving spam to failing to receive
legitimate mail; it causes significant false positives.
please remember to note that an MTA acting as
sender for several domains would have to terminate its connection and
reconnect with a new HELO each time a mail item isn't from the same domain
as the previous item - this may be a significant operational change for some
providers. (I wonder why Postel took this particular <host> parameter of
helo out when he upgraded RFC788 to RFC821. Could it have been to cater for
MTAs serving multiple domains, I wonder?)
That change does some to make it easier to compare the HELO domain
name against the sender domain. However, it might also only reflect
the general jargon drift from "host" or "host name" to "domain" or
"domain name." In IETF standard language, "domain" or "domain name"
can refer to something with an IP address and so can be a "host name."
The reason to check reverse DNS name is to cover the case when the
SMTP client is authorized to send mail for more than one domain name.
Some MTAs will need (tens of) thousands of rDNS answers - quite a big DNS
transaction to get all those back (unless of course you are proposing that
no host can act as outgoing MTA for more than one domain - now that would
cause quite an upheaval, probably do more economic damage than all the
spammers in the world).
Yes, MTAs processing lots of mail make many reverse DNS lookups, but
checking reverse DNS names would not require additional DNS lookups
for most mail. The reverse DNS name of the SMTP client for most mail
is already checked by SMTP servers. That is how SMTP servers add
Received: headers naming the SMTP client.
Even then, it just doesn't work: the MTA you see is the ISPs outbound MTA
(many ISPs block port 25, of course, so their users have to relay through
the ISP's outbound MTA), not the originator's mail client machine, and the
originator's mail client machine will not have the same domain name as that
MTA (unless of course part of your proposal is to allow lots of hosts owned
by lots of different organisations all to have the same domain name instead
of having domain names connected with the organisations, which is rather a
big change to the internet as we currently understand it).
What's that about "doesn't work" and "big changes"? Common MTA software
including sendmail can say "possibly forged" or similar comments when
confronted with mismatches. It is also trivial to tell sendmail to
reject mail that fails such checks among sender address, reverse DNS
name, and HELO value, because sendmail already makes the DNS lookups
and then checks the values.
Maybe you think
that you can adapt your idea to use MX records - but I have news for you
buddy, outbound MTAs are often not inbound MTAs so they won't have MX
records.
To me, what you are describing is a half-baked attempt to do what rMX would
do by using mechanisms that are just not capable of doing it.
Many messages ago in this mailing list Paul Vixie pointed out that MX
records can do today exactly what rMX might do someday with a new, to
be defined RR. He pointed out that most outbound MTAs are also inbound
MTAs and so are named by MX RRs (or there are no relevant MX RRs and
their A RR serves the same purpose). Outbound MTAs that are not
inbound MTAs and so do not answer port 25 need only have new MX RRs
defined with very large preference.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg