Subject: [Asrg] Reverse DNS and mta server together, registered smtp channel

From: [email-masked]
Date: Wed, 26 Nov 2003 19:04:00 +0200

Reverse MX = registered MTA.
Same idea like handling nameservers and networks.

Registered MTA together = registered smtp channel.

Full doc (roaming, dhcp, example, ...)
http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx

We have tested all our customers smtp connection in last days and it 
works allways if sender MTA has reverse dns. Reverse domain = 
in-addr.arpa is also tree, so it must works  ... if NS works.

That page include also shell script example which search ip's network 
and so it's simple to make reverse mx query. Reverse is also nice 
domain-tree .

Ofcource this is not full answer of spam, but I think that it's much 
more easier to communicate with registred nameservers and mta-servers as 
with all servers ...

-jukka-

-- 
______________________________________________________________________
Karjalan ATK-Awot Oy, Jukka Inkeri
Jukka dot Inkeri at Awot dot Fi

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:28:12 -0500

[Subject change per posting guidelines. Mod.]

> more easier to communicate with registred nameservers and mta-servers as 

Take a look at the LMAP, RMX, DMP, SPF proposals:

http://asrg.kavi.com/apps/group_public/documents.php?wg_abbrev=lmap

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"And this too shall come to pass"
-------

---

From: Jukka Inkeri <[email-masked]>
Date: Thu, 27 Nov 2003 09:43:40 +0200

> http://asrg.kavi.com/apps/group_public/documents.php?wg_abbrev=lmap

I have read those proposal (quickly), but if I have understood correct, 
all those ideas based on domain attributes and define new attributes 
using domain database, not real net/ip checking using reverse dns 
attributes as I like todo, same way as all other security / access has 
mostly defined, ip based priviledges. This is only worldwide "trusted ip 
list".

My idea is check senders ip and priviledges to use smtp, not reading 
protocol headers. My idea is control connection (ip) using reverse dns 
lookup database, not dns lookup. My proposal include also method to 
handle roaming mta.

Reverse dns is mostly controlled by operators and "big companies", so we 
have less players as in domain structure and I believe that it is easier 
to make "operator blacklist" as domains.

This idea is simple to add every access control level : firewall, 
proxies, filters, wrappers, smtp servers, ...

Or if this idea was some of those proposal, then I have missed it. That 
is possible, because I'm novice in english and it's heavy job to read 
very formally made technical data. But that is my problem :).

Proposal rMX using rDNS:
http://www.awot.fi/sf/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx

We have to define some smarter as filtering/rbl controlling system using 
current environment and maybe some more smarter in future. Spamming is 
growing up too fast. This rMX+rDNS method is very easy to build up.

For our mail customers spamming is more huge problem as virus mails even 
we use also some spamstop methods. Virus filtering works allmost absolut 
(1 case / year), but spamfiltering only about 90%.

-jukka-
jukka do.t inkeri at awot do.t fi

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 27 Nov 2003 10:44:25 -0500

> > Take a look at the LMAP, RMX, DMP, SPF proposals:
...
> mostly defined, ip based priviledges. This is only worldwide "trusted ip 

  Then you completely missed the point of the proposals.

  None of them claim to have a "worldwide trusted IP list".  Instead,
they determine if a domain has authorized an MTA at an IP to use its
name.  That's a completely different problem than what you're talking
about.

> lookup database, not dns lookup.

  Which is substantially similar to the proposals listed above.

  See also the MTAMark proposal, which lists MTA's in in-addra.arpa

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 27 Nov 2003 11:43:32 -0500

>   See also the MTAMark proposal, which lists MTA's in in-addra.arpa

Copy can be found here:

http://asrg.kavi.com/apps/group_public/download.php/16/draft-irtf-asrg-mtamark-00.txt

Many people prefer the LMAP proposals that deal with regular "forward" 
DNS than the MTA mark proposal that uses reverse DNS, because a usual 
domain owner has control over regular DNS and does not have control over 
reverse DNS.

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 28 Nov 2003 16:59:19 -0500

> domain owner has control over regular DNS and does not have control over 

That's a very important point.

On the other hand, it's IP space owners (er, delegees?) who often
bear the brunt of complaints about how their space is used, and
giving them some degree of authority is not necessarily bad.  It's
not like every proposal provides a complete answer: if one piece
of the puzzle is to give IP space maintainers some say, then that
may be one more positive step.

I am curious (though I can guess, see below) why MTAMark chooses to
overload the TXT result from a single DNS record rather than using DNS
in a more natural way.  For an address 10.0.0.1 MTAMark shows an
example like:

  $ORIGIN 0.0.10.in-addr.arpa.
  1   IN  PTR  mail.example.com.
  1   IN  TXT  "ASRG.MTA=yes"
  1   IN  TXT  "ASRG.CONTACT=mailto:[email-masked]"

etc

whereas it would seem to me more natural to use subdomaining:

  $ORIGIN 0.0.10.in-addr.arpa.
  1              IN  PTR  mail.example.com.
  mta.1          IN  TXT  "yes"
  contact.mta.1  IN  TXT  "mailto:[email-masked]"

making it easier to retrieve individual result records without
overloading the results, sifting through and parsing the results,
worrying about oversized DNS records, etc.

My guess is that the proposal wants to include wildcards, but if that's
the case I think that's not a great tradeoff, nor does it address anything
smaller than /24 delegations (e.g. RFC2317).  Besides, one could always
handle the /24 wildcard entry in another way, such as:

  $ORIGIN 0.0.10.in-addr.arpa.
; default txt record(s) for this zone
  mta            IN  TXT  "no"
; specifics per IP
  1              IN  PTR  mail.example.com.
  mta.1          IN  TXT  "yes"
  contact.mta.1  IN  TXT  "mailto:[email-masked]"

Interestingly, an extended version of this sort of scheme could
conceivably do away with the dyndns style dnsbls voluntary
registrations.

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 28 Nov 2003 18:53:54 -0500

>   contact.mta.1  IN  TXT  "mailto:[email-masked]"

Or even:

  $ORIGIN 0.0.10.in-addr.arpa.
  ; defaults
  *.mta          IN  TXT  "no"
  *.contact      IN  TXT  "mailto:[email-masked]"
  ; specifics per IP
  1              IN  PTR  mail.example.com.
  1.mta          IN  TXT  "yes"
  1.contact      IN  TXT  "mailto:[email-masked]"

mm

---

From: Markus Stumpf <[email-masked]>
Date: Sat, 29 Nov 2003 03:30:06 +0100

> That's a very important point.

And it's a different approach to what should be accomplished ;-)

> may be one more positive step.

Let's have an example:
My company is example.COM. I have a publicly accessible company network
say (example! ;-) 10.0.1.0/32.
I can now use the LMAP approach and make one designated MTA for my
domain: mail.example.com on IP 10.0.1.25.
This saves me from joe jobs (if other participate in LMAP) as no MTA
will accept eMails with addresses @example.com from any other IP address
than 10.0.1.25 (or according to the LMAP configuration of course).
Perfect.

Now there is another company, let's call it example.ORG. They do not
have LMAP records in place, so any MTA will accept messages with
addresses @example.ORG from any IP. It will accept the messages also
from 10.0.1.0/32, even if I use LMAP. So if a workstation in my
net is compromised it can be abused as a spam relay. Same holds for
viri.
There is no chance to tell other mailservers: don't accept eMails from
10.0.1.1. MTAmark fills that gap and gives (optionally) a contact address.
We don't see MTAmark as a concurring proposal to LMAP. Those two fit
together and complement themselves.

> handle the /24 wildcard entry in another way, such as:

Your guess is right ;-)
With your example there are more DNS queries involved, as one has to
lookup "mta.1" and "contact.mta.1" but with our proposal it can be
handled with one lookup, as a TXT query will be answered containing all
TXT records.
However you are right that this may often be unnecessary.

>   1.contact      IN  TXT  "mailto:[email-masked]"

This will not work in case of e.g.
   $ORIGIN 0.10.in-addr.arpa.
whereas the wildcard example from our proposal would. You would have
to specify
   $ORIGIN 0.10.in-addr.arpa.
   *.mta.1          IN  TXT  "no"
   *.contact.1      IN  TXT  "mailto:[email-masked]"
   *.mta.2          IN  TXT  "no"
   *.contact.2      IN  TXT  "mailto:[email-masked]"
which could be solved with BIND's COMPUTE statement, but that's specific
to BIND.

Anyway, I'll think about that over the weekend ;-)

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 28 Nov 2003 23:37:46 -0500

> together and complement themselves.

Agreed- I tried to say that too :-)

> > My guess is that the proposal wants to include wildcards
> > [etc]
> Your guess is right ;-)

Right, considering that you don't always need to lookup the contact
address.

Plus the caching nature of DNS reduces the DNS traffic between any
mail servers that communicate frequently.  Extra queries sound like
(and are) more work - but the mere fact of extra work does not mean
it's unreasonable.  (You'd have to consider the current load and the
likelihood of the new load: if there is currently one DNS lookup per
connection, and you are adding one, the DNS load doubles.  But if
there are currently five lookups and you add one more 10% of the time,
the DNS load increases by a factor of about 2%, some of which goes
only as far as the local cache.  I am not trying to give numbers, just
suggesting that it's not obviously a severe penalty.)

My initial reaction is that I'd probably prefer a little more DNS
traffic if it meant a cleaner database.  (Everyone has opinions,
right?  anyway that's mine.)  Opinion aside, one question is what
would be the real burden imposed by an extra DNS lookup, contrasted
with the (IMHO) gain in data organization.

>    *.contact.2      IN  TXT  "mailto:[email-masked]"

Yeah, I see what you mean.  But again what's the real burden?  How
many in-addr.arpa delegations are there where the same organization
that is delegated the in-addr.arpa zone corresponding to a /16 is the
same organization that is delegated the in-addr for a /24 ?  And for
them, how much of a problem is it to populate each of the
in-addr.arpa's for each /24 ?  If it's an issue, it's probably
somewhere down at the noise level.

> which could be solved with BIND's COMPUTE statement, but that's specific

hmm, $generate maybe?  I think that's a hack that's better solved
by zone generation tools :-)

> Anyway, I'll think about that over the weekend ;-)

Thanks,
-mm-

---

From: Jukka Inkeri <[email-masked]>
Date: Sat, 29 Nov 2003 15:55:12 +0200

I have updated our ideas. Now it is more simple "one dns query" -method.
No need anymore to take care of networks.
It also include posibilities to handle blacklist in own net. It give to 
operators posibilities to block/control some "not so good" mta.

-jukka-
-keep it simple-

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 29 Nov 2003 10:49:03 -0500

> net is compromised it can be abused as a spam relay. Same holds for

  Absolutely.  That isn't a problem that LMAP is trying to solve.  The
spammers can forge association with example.ORG, because the admins of
that domain have agreed to permit such forgery.

  You're responsible for the use of your own network, but you're not
responsible for abuse of another domain name.

  The MTAMark proposal addresses the problem of "owned" machines
originating SMTP traffic.  But I don't recall if it includes
information about which domain that MTA can claim association with.
That would be hard, as some IP's host hundreds of thousands of
domains.

  The two proposals are related, but solve different problems.

  Alan DeKok.

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 29 Nov 2003 15:31:07 -0800

On 11/28/2003 6:30 PM, Markus Stumpf sent forth electrons to convey:

> If a workstation in my
I see this or rDNS and rMX as complementary to LMTP, but I think it's a 
less useful scheme than LMTP.
Also, http://www.dnsbl.au.sorbs.net/DUL-FAQ.html is essentially a 
centralized version of MTAmark, and it's an existing system that doesn't 
need any new software or evangelism effort to be supported.
In terms of priorities, I don't see 'em at the top of the list, when 
adopting them would, like LMTP, require a large evangelism effort, but 
for a relatively small gain. Also, they don't provide the selfish 
motivation to implement that LMTP benefits from.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 29 Nov 2003 18:57:25 -0500

> need any new software or evangelism effort to be supported.

A centralized system can be subject to a DDOS attack like we have seen. 
Also, centralized systems confer power on those who run them, and that 
power can be abused. It is easier to let the rDNS owners do this.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"One who watches the wind will never sow, and one who keeps his eyes on 
the clouds will never reap" (Ecclesiastes 11:4)
-------

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 29 Nov 2003 23:41:19 -0500

> http://www.awot.fi/sf/browser/showfile?cust=awkoulutus&subdir=dns&doc=reverse_mx

It's hard to read because it doesn't wrap properly in my browser
(probably because I'm still using an antique Netscape).  

But in summary it looks like this would modify the "MTA" portion
of MTAMark to use MX records instead of TXT.  And (if I read this
right) it looks like you intend that the return value has special
meanings (much like the values of various DNSBLs have special
meanings).  So e.g.:

   <no result> --> This IP address does not participate in MTAMark/MX
   127.0.0.1  -->  This IP address is NOT an MTA
   127.0.0.2  -->  This IP address IS an MTA
   <other values> --> future definition

This certainly addresses the wildcard concern in MTAMark.

One question is: does this conflict with any existing use of MX records
in in-addr.arpa ?  I think that would be hard to tell, which may be
why MTAMark chose to use a unique new subdomain/keyword scheme.

-mm-