----- Original Message -----
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: <security1(_at_)awot(_dot_)fi>
Sent: Friday, November 28, 2003 7:06 PM
Subject: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX] proposals
[cut]
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.
A bug in the TXT part of software that has known security holes and MUST
be replaced anyway isn't a deal breaker, IMO; I'm assuming these bugs
are only in old versions.
It's easy to say "must", but lot harder to get all the servers upgraded.
It isn't deal breaker; MTAMark has very good qualities (and I think I had
a little misunderstanding on my side here about it).
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.
Argument built on a false foundation. Your client isn't using "just
about any sending SMTP server". A short list of the IPs of the SMTP
servers of the two (or 20) ISPs your client uses is 0.0% of the SMTP
servers on the 'net.
Well, I'll give an example: client operates in more than 20 countries, has
travelling salesmen and agents in many countries. Yet, they all use same
email domain and everyone uses their current ISP to send out messages.
Notice: Travelling salesman maybe connecting even from hotel network.
From my point of view; outgoing MTA can be any server in the world.
How could I know I should temporarily add record for MTA of some
ISP the hotel is using ?
I agree that domain specific configuration would be better, but it's
simply another layer of control. I think we should have network
level control (legitimate MTAs for some network) AND we should
have domain level control. The whole problem of SMTP is that
it has had no control mechanisms at all. Anyway, at this point I think
the network is nearest (and easiest; IMHO) control mechanism
and at this point my interest is on the network centric approach.
When IP addresses get restricted, the spammers will have to use
those servers that are "trusted" and it's lot easier to point the spammer
from a known IP list than from approx. 2^32 IP addresses.
Spammers are a moving target, changing their sending MTA all
the time and I'd like to make them a sitting target. Bad behaving
networks can be blocked out using RBL.
Under the "rMX and rDNS co-operate" scheme, this list is of IPs trusted
(i.e. listed) by people who have often proven untrustworthy.
This is true, we will have problems if the network administrators are
untrustworthy. However, if 20% of network administrators are untrustworthy
and 80% are trustworthy then I'll be happy to RBL the untrustworthy
networks away.
Reverse MX
<http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=d
ns&doc=reverse_mx>
MTAMark http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt
RMX Records http://www.mikerubel.org/computers/rmx_records/
LMAP:
<http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap
-discussion-00.txt>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg