Couple of comments after reading Reverse MX proposal, RMX records and
MTAMark draft.
There are other proposals too, but they seem to do work
mostly on domain specific configuration where as RMX and
MTAMark concentrate on network specific configuration.
MTAMark draft tells us the problem (from the spam point of view),
and they have done great job, but I think it's a little too complicated
to maintain. It may require configuration per domain if virtual
domains have their own MX setup (this does not apply to all setups).
Also, I don't like parsing TXT records (Parsing == bugs == troubles).
Bind and Tinydns seem to differ in TXT records, too. Some Bind versions
send extra character (space or ") (parser bug?) whereas Tinydns doesn't.
Conclusion: I'm against TXT records.
RMX records (Do not confuse with Reverse MX records) is domain specific.
It's simply a list of IP addresses that can send email from some domain.
In reality, some of the users may use just about any sending SMTP
server [depending on their ISP]. For example, I have a client that
operates in couple of countries, each using different ISP, yet the
incoming MTA is always the same, outgoing MTA is never the same.
They could be using SMTPAUTH, but instead they use email server
of ISP to send out messages. Do you think I could do something
about it? Should I administrate a list of outgoing mail servers for my
client in this case? No. It's not my job, so I'm against it and I believe
most of the administrators are against it. Also, RMX requires new
record type, that some bind versions refuse to send out.
Reverse MX records tell one thing:
List of SMTP server IP addresses that are trusted to communicate
to outside networks. It's up to the receiving MTA to use that information.
Every administrator can choose whether they utilize that information or
not.
Network owner does not block outgoing smtp connections.
RMX is simple to administrate. It's just a list of IP addresses.
It's simply a MX record in reverse zones.
Example:
Network administrator of 1.2.3.* network sets up a list of the
smtp servers [aka: trusted MTAs] that are supposed to talk
to outside networks. The list containst: 1.2.3.5 and 1.2.3.6
MTA Administrator at 4.5.6.7 (mailslave.company.dom) -chooses- to add
rmxsmtpd [imaginary software at this point] to his set up.
User at 1.2.3.10 sends out an email message. Message is first
transmitted to 1.2.3.5 [users outgoing mail server] which
contacts 4.5.6.7 (MX for company.dom)
MTA at 4.5.6.7 checks for Reverse MX records for the contacting
IP address [3.2.1.in-addr.arpa] and finds a list that containst
1.2.3.5 and 1.2.3.6. The contacting IP address [1.2.3.5] is on the
list and message is accepted. [Other checks, like RBL may
ofcourse block the service after that, too]
Scenario 2:
A virus infected users machine [1.2.3.10] and tries to send email
using its own smtp server (tries to send email to everybody on the
users contact list).
MTA at 4.5.6.7 checks for Reverse MX records, finds a list
and determines that this ip is not trusted. Message is not accepted
for delivery.
Scenario 3:
User at 1.2.3.10 chooses to spam 10 million users (to get sales leads!)
and uses special purpose smtp server on his machine to do the job.
MTA at 4.5.6.7 checks for Reverse MX records, finds a list
and determines that this ip is not trusted. Message is not accepted
for delivery.
Scenario 4:
MTA Administrator at 6.7.8.9 has not (yet) set up the smtp server
to check for Reverse MX.
Messages will be accepted (other passes, like RBL, may deny
the access).
Scenario 5:
MTA Administrator at 4.5.6.7 sets up the reverse mx check,
but network administrator for 1.2.3.* has not yet set up a list
of trusted smtp servers in his network.
User at 1.2.3.10 sends out a message using 1.2.3.5 (his
outgoing MTA).
MTA at 4.5.6.7 tries to check for reverse mx but doesn't find
anything. Currently, I think MTA should accept the delivery,
but after 1st of June 2004 (reasonable time to set up the list)
the MTA utilizing reverse mx check may not accept the delivery.
MTA should respond; "Your IP [1.2.3.5] is not listed in Reverse MX!
Contact your mail or your network administrator. See
http://www.reversemx.org/";.
Implementing (technology):
Users of qmail can utilize RBLSMTPD to block out open relays etc,
and after a quick look to the code I think it should be reasonably
easy to modify code for this purpose (RMXSMTPD)
Implementing (the people):
I think this reverse mx must be made mandatory for all networks.
However, I believe people will be educated by their users better -
in other words, when the policy change comes (1st of June 2003)
administrators will get a hell of a lot calls from their users and
will be forced to set up a list.
Blocking out evil people (spammers with own network):
It's easy enough to block them out using RBL.
References:
Reverse MX
http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx
<http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx>
MTAMark http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt
RMX Records http://www.mikerubel.org/computers/rmx_records/
--
Tomi Panula-Ontto, Koodia Ltd.
E-mail: tomi AT panula-ont DOT to