VS> Because those networks are dynamically addressed, an ISP with users on
VS> networks that allows third party sending (including AOL, Yahoo, and
VS> Hotmail) must set their RMX 'bits' to say "authorized" for all addresses
VS> in such a network.
Vernon,
If AOL, Yahoo, or Hotmail wanted to implement RMX, they would cease to allow
third party sending; senders would have to send the mail through the
official relays (which is the way it's normally done anyway). If an
organization doesn't want to forward through one of a limited number of
outbound relays, it would not adopt RMX.
Right now, a lot of people are blocking all mail claiming to come from
AOL, Yahoo, or Hotmail. This is a big problem for those sites, and it's
not their fault, since the spam that arrives "from" them is all forged.
RMX would give these sites the ability to earn (or spurn) their
reputations as honorable, spam-diligent netizens on their own terms.
VS> The only fix is to prohibit sending from any mail systems but those
VS> of the ISP that owns the IP address. However, if you want to enforce
VS> that rule, you don't need any new RMX or other bits. You need only
VS> compare reverse DNS and envelope sender domain names. (Yes, reverse
VS> DNS can be faked, but that can be reasonably reliably detected by
VS> doing an extra forward lookup of the reverse name.) (Yes, in some
VS> cases you must do a little more than just comparing the PTR and A RRs,
VS> such as fetching all PTR RRs or all A RRs for the PTR name.)
Right, except that right now, if I'm a recipient, I can't reject email on
the basis that it doesn't come from a machine in the sender's netblock.
That's because, a lot of sites (including mine) use the lazy man's
solution: send directly from localhost, because there's no reason not to.
But RMX gives us a reason to change: by posting RMX records, I'd be saying
to the world, "I am choosing to send my mail only from my official relays,
and here they are--if you get mail from anywhere else, rest assured that
it's a forgery!"
If only 0.2% of canvassers or your incoming email have an ID, would
you bother checking?
Depends who it is. If the person claims to be an agent from my bank, or the
government, or a business partner, then damn straight I'd check the ID. A
better analogy in this case is that I'd actually call up the sender's
organization and verify that the person at my door was one of their agents.
Not a completely foolproof check, but pretty good.
Not everyone has to be using RMX to make it useful.
Today, as a domain owner, I have no way of telling people 'Mail from my
domain will only come from these IPs. Any other source is a forgery.'
Wouldn't be simpler to tell everyone to compare your sender domain name
with your reverse DNS?
That's basically all RMX is! It's an organized way for you to tell
recipients, "Hey, go ahead and check my reverse DNS--I've actually
configured my system in such a way that checking it will be meaningful."
Do you run sendmail with more than 10,000 messages/day and if so, do
you turn on IDENT? My guess is if you answer the first "yes," then
you answer the second "no," because you don't like the costs (especially
delays) of IDENT given its near uselessness against spam or other abuse.
Since the worst spammers (proxy abuses) can have good RMX bits, why
would you bother with extra DNS chatter to get RMX bits?
Is your argument is that IDENT is useless against spam, therefore RMX is
useless against spam? They're completely different animals...
It looks like your message came from CalTech. Has CalTech never had
a spammer or an open relay? Are you confident that you know and will
continue to know the IP addresses of CalTechs outgoing mail servers?
If you fail to authorize the right address, the RMX idea would have
your mail bounce. If you configured the RMX bits for mikerubel.org
to authorize all 65534 addresses in 131.215.0.0/16, you'd be vulnerable
to any spammer or open relay at CalTech. (Never mind that I can't
find an A or MX RR for mikerubel.org just now, so by RMX-like thinking,
your message should have been rejected.)
If RMX were available, I would use it. Caltech's mail servers are only
relevant for the .caltech.edu domain, which would set its own RMX records;
they have no bearing on mail sent from mikerubel.org. I control the DNS
records on the latter. The fact that it's currently part of 131.215/16 is
irrelevant.
If I were using RMX records for mikerubel.org, then any message you receive
from me would arrive from 131.215.118.32/32, or be a forgery.
If caltech were using RMX records, then any message from .caltech.edu would
arrive from one of the designated outbound caltech mail servers.
When you want to send mail to an address at caltech.edu, you look up its MX
records and send to one of those; you don't send to just any machine at
131.215/16. Why should receiving mail from caltech.edu be any different?
So you would prohbit sendmail mail except from the mail systems of the
sending domain? If so, why bother with RMX? Why not just enforce matches
between reverse DNS and sending domain?
Exactly! RMX records give mail systems a reason to shunt all of their
mail through a few specific servers. Think about the migration path--if
we just start checking reverse DNS now, it usually won't work (because a
lot of sites don't follow the convention). By introducing a new resource
record, you give sites a way to declare that they are now following that
convention.
So... have I sold you on RMX records yet? :)
Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg