Re: [Asrg] 0. General - Administrative - for M. Wild

[Steven F Siirila <sfs@tc.umn.edu>]

Ideally, MTA's would identify themselves as such.  For example:

mta5.exchange.microsoft.com	TXT	"ID=MTA,ABUSE=abuse@microsoft.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@microsoft.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@tc.umn.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@umn.edu
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg