Ideally, MTA's would identify themselves as such. For example:
mta5.exchange.microsoft.com TXT
"ID=MTA,ABUSE=abuse(_at_)microsoft(_dot_)com"
(or whatever format makes the most sense)
I suppose the same could be done using just the reversed IP address, e.g.:
3.2.1.10 TXT
"ID=MTA,ABUSE=abuse(_at_)microsoft(_dot_)com"
Either of these would allow a site to determine if a given connection is
coming from a known MTA. Over time, one could be more and more restrictive
as to how they treat MTA's with no such record (as we presently are doing
with the absence of rDNS). Obviously, sites with large numbers of client
workstations would NOT put an MTA designation on those IP addresses, nor
would a site put them on dialup/dynamic lines. If successfully implemented,
this would do away with (over time) DNSbls which list dynamic/dialup lines,
most cases of open proxies, and trojanned IP addresses never meant to run
an MTA.
The main reason we want rDNS along with this is to allow us to associate
a valid domain name with the MTA (instead of trusting its HELO value).
Strictly speaking, it wouldn't be required along with the above.
What the "MTA designator" does is finally start allowing sites to identify
known MTAs (whether they are direct spammers or not, doesn't matter).
On Fri, Aug 29, 2003 at 03:10:21PM -0700, Bob Atkinson wrote:
Perhaps I'm being slow this Friday afternoon, but can you elaborate on
why you feel both rDNS and another DNS id is necessarily required to
deter Trojans? The reasoning you are using isn't clear to me.
Thanks much.
Bob
-----Original Message-----
From: Steven F Siirila [mailto:sfs(_at_)tc(_dot_)umn(_dot_)edu]
Sent: Friday, August 29, 2003 12:22 PM
To: Bob Atkinson
Cc: Hector Santos; Anti-Spam
Subject: Re: [Asrg] 0. General - Administrative - for M. Wild
Until we require both rDNS -AND- add another DNS identifier declaring
the
sending MTA as an MTA, we will continue to see trojan software
masquerading
as MTAs. While it may be a slow, painful process, I don't see any good
alternatives (at least not in our environment). We continue to employ
rDNS checking, adding more networks to the mix all the time. The key to
implementing rDNS for us has been:
1) It is not done for all IP addresses, but rather on a per-netblock
basis
(with the count of addresses having this requirement increasing each
day)
2) Users can opt-out of this requirement (the blocking occurs after
RCPT TO processing)
3) Even with the blocking in place, we return a URL to the sender to
allow them to request a block exception from our user who can then
either grant, deny, or ignore the request
On Fri, Aug 29, 2003 at 10:38:15AM -0700, Bob Atkinson wrote:
There's a much simpler reason why rDNS is unreliable.
In order for rDNS to work, the domain owner must have a DNS
relationship
with their ISP (as opposed to hosting DNS themselves). There are many,
particularly the small folk, who do not, esp. as it costs ongoing $ to
maintain such a relationship.
Having such a relationship is not today pragmatically necessary to
participate in the Internet, and we ought to think carefully before
giving ISPs such a win-fall and shift in power.
Bob
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: sfs(_at_)umn(_dot_)edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg