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

From: Steven F Siirila <[email-masked]>
Date: Fri, 29 Aug 2003 17:55:03 -0500

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

mta5.exchange.microsoft.com	TXT	"ID=MTA,ABUSE=[email-masked]"

(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=[email-masked]"

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:[email-masked]] 
> 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: [email-masked]
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 29 Aug 2003 18:49:11 -0400

I'm new to this mailing list so I don't know all that has been discussed. So
please excused any ignorance I may show.

I agree with Steven.

In my view,  I believe ultimately the "mail server" concept will need to be
part of some official "registry" system.    Whether that's going be done at
the HELO/EHLO state,  one way or another,  the system can not simply to
continue to work using the "honor" system and accept open-ended unauthorized
transactions.

At the same time, I don't think that is the complete solution either.

Before I go further, I would like to note that the cards may be already been
dealt for us.  With more of the larger ISPs controlling access and limited
who can connect via HELO/EHLO and the peer IP,  the developers, such as
myself, will follow their lead.    So their actions may pre-empt any work
done here.  Nonetheless, I am hoping to be part of any new specification
process and make sure I get my technical expertise and opinions heard.

In my view, we need a stronger handshake between the server and the client.

One way to accomplish this is using a "challenge string" as part of the
welcome.

        250 domain, [vendor, version] [challenge string]

The compliant client will then use the challenge string as part of the EHLO
command.  It can be a simple echo:

        EHLO clienthosthame [challenge string]

At the very least, this will tell the server that the client is compliant
and ready for new commands that are engineered to complete an authorized
mail transaction.

or we can have a new command such MAILER that says:

        MAILER clienthost [vendor, version]  [challenge string]

regardless,  we need to make this stronger and while we are at it,  we use
the opportunity to enhance SMTP state machine.

Even if we consider to make stronger use of rDNS on the HELO/EHLO,  we need
to make it strong enough to suggest that not everyone can just setup a mail
server to send mail.   The larger ISPs are forcing the issue for us in this
regard

----

Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com

----- Original Message ----- 
From: "Bob Atkinson" <[email-masked]>
To: "Steven F Siirila" <[email-masked]>
Cc: "Hector Santos" <[email-masked]>; "Anti-Spam"
<[email-masked]>
Sent: Friday, August 29, 2003 6:10 PM
Subject: RE: [Asrg] 0. General - Administrative - for M. Wild

Thanks much.

 Bob

---

From: "Bob Atkinson" <[email-masked]>
Date: Fri, 29 Aug 2003 15:10:21 -0700

Thanks much.

	Bob

-----Original Message-----
From: Steven F Siirila [mailto:[email-masked]] 
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

relationship

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Aug 2003 17:55:24 +0200

>  3.2.1.10			TXT	"ID=MTA,ABUSE=[email-masked]"

	I think we can take the previous example of WKS records, and the 
current example of PTR records, as predictors of accuracy and success 
of this concept.  In short, I don't see where this is going to work.

	If you're a spammer, and you own your own domain (as so many do), 
you can create your own DNS records, so that you can by-pass checks 
like this.  Indeed, many spammers register domains, spam from them 
for hours or maybe a few days, and then throw them away.  You'd be 
causing legitimate senders to jump through additional hoops to send 
you e-mail, but since spammers adapt very quickly, you wouldn't 
really be hurting most of them.

	If you were using forward records, you wouldn't even slow down 
people using viraspam-based distributed spam networks (e.g., those 
created by a more sophisticated and less obtrusive version of 
SoBig.F), because you could just list wildcard records in the DNS, 
and anyone from any IP address could make an apparently valid claim 
that they should be allowed to send e-mail through this mechanism.

	The situation for reverse DNS is even worse.

	I see similar problems for RMX-like proposals.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Steven F Siirila <[email-masked]>
Date: Sat, 30 Aug 2003 19:58:45 -0500

> really be hurting most of them.

You missed the point.  Spammers do NOT control the DNS for trojanned PC's
and open proxies which appear to be our primary problem now.  Direct spammers
are the easiest ones to catch already; who cares if they want to better
identify themselves?

> that they should be allowed to send e-mail through this mechanism.

That is only true if you don't require rDNS in addition.  I'm not 100% sure
that everyone is going by the same definition of rDNS I am either.  By rDNS
I am strictly speaking of the connection IP address, it's associated PTR
record, and the A record of the name returned by the PTR.  Not the HELO.
Not the sender domain in MAIL FROM.  Both are easily forgeable.

> 	The situation for reverse DNS is even worse.

With rDNS I can at least be assured that the owner of the in-addr.arpa space
is the owner of the domain named in the PTR (or at least an agreement exists
between the two).  BTW, having this domain makes it easier to determine an
abuse address to send reports to, too.

> 	I see similar problems for RMX-like proposals.

We could never use RMX due to its tying in with the MAIL FROM domain.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 31 Aug 2003 03:46:44 +0200

>  are the easiest ones to catch already; who cares if they want to better

	No, but they control their own DNS.  Depending on how this sort 
of system would be expected to work, anybody could claim to be an MTA 
in {HE|EH}LO, and when you look up the IP address under that domain, 
lo-and-behold you find that they are authorized to send mail on 
behalf of them -- through a wildcard that you know nothing about.

>  record, and the A record of the name returned by the PTR.

	To make his work, you've got to handle the possibility of the PTR 
returning multiple names, and each name returning multiple IPs. 
You've got to follow that chain to it's complete logical conclusion.

	This can lead to its own form of DDoS attack on your servers.  In 
fact, all it takes is a slightly hacked nameserver which generates 
new records on the fly, and which returns two names for every IP 
address and two IP addresses for every name.  In short order, you're 
going to have more names and IP addresses to track than you have 
memory or disk space.

>  abuse address to send reports to, too.

	The rDNS chain gets broken far, far too often.  In most cases, 
the entity handing out the name has nothing to do with the entity 
owning the network space, and vice-versa.

	Moreover, you are dependant on the RIRs and LIRs doing their job. 
Until recently, RIPE was always backed up on getting rDNS delegations 
done, to the order of multiple years.  During the time I worked 
there, Skynet had applied for rDNS delegations for several netblocks 
that RIPE had issued to them in the recent past, and as of the time I 
left a couple of years later, they still hadn't been done.

	Then there are all the spammers operating out of stolen netblocks 
or netblocks that haven't been issued yet, and for which they 
convince some poor sod ISP to give them network connectivity.

	At best, rDNS checks might stop naieve open proxies and 
SoBig-like viraspam networks if they've infected machines that don't 
have reverse DNS set up, but it would also catch a lot of SOHO 
operators that have their own mail servers and have few options for 
upstream connectivity (among others).

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 30 Aug 2003 23:08:15 -0400

First of all, please keep in mind the posting guidelines 
(http://www.irtf.org/asrg/asrg_mailing_list_information.htm) - change the 
subject when necessary. This would apply under RMX and related proposals in 
item #6.

Second, please take a look at the DNS-based proposals from the work item 
list 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06938.html):

Designated Senders Protocol:  A Way to Identify Hosts Authorized to Send 
SMTP Traffic (http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt)
Hadmut Denish's proposal 
(http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt)
DRIP proposal (not listed in the work item list yet)

Also, check the mailing list archive - there have been numerous discussions 
on DNS-based proposals and many of the things are being repeated again.

Yakov

At 09:46 PM 8/30/2003, Brad Knowles wrote:
> of system would be expected to work, anybody could claim to be an MTA in 
> {HE|EH}LO, and when you look up the IP address under that domain, 
> lo-and-behold you find that they are authorized to send mail on behalf of 
> them -- through a wildcard that you know nothing about.
>
> returning multiple names, and each name returning multiple IPs. You've 
> got to follow that chain to it's complete logical conclusion.
>
> fact, all it takes is a slightly hacked nameserver which generates new 
> records on the fly, and which returns two names for every IP address and 
> two IP addresses for every name.  In short order, you're going to have 
> more names and IP addresses to track than you have memory or disk space.
>
> the entity handing out the name has nothing to do with the entity owning 
> the network space, and vice-versa.
>
> done, to the order of multiple years.  During the time I worked there, 
> Skynet had applied for rDNS delegations for several netblocks that RIPE 
> had issued to them in the recent past, and as of the time I left a couple 
> of years later, they still hadn't been done.
>
> or netblocks that haven't been issued yet, and for which they convince 
> some poor sod ISP to give them network connectivity.
>
>
> SoBig-like viraspam networks if they've infected machines that don't have 
> reverse DNS set up, but it would also catch a lot of SOHO operators that 
> have their own mail servers and have few options for upstream 
> connectivity (among others).
>
>--