Awot koulutuspalvelut

DNS - nimipalvelut osaksi spam-torjuntaa - Spam more difficult using DNS

rMX and rDNS together make spamming more difficult ? Registered smtp sender ?

Proposal rMX and rDNS co-operate

updated: 2003-12-02

Registered smtp sender = registered MTA

Spamming is more difficult

Background

Awot is "the smallest operator in Finland" or not. We have only some C-class networks and also we are ISP and ...

I was thinking what I can do more to limit unwanted smtp trafic ? Smtp - only not controlled routing protocol ? = reason for problems ?

Today spam is bigger and bigger problem.

We allready use many checking for sender and destination, we can stop or mark mail for rerouting to some folders and so on.

But allmost every day we add new rules ...

We was thinking method which would be easy to make, allmost everyone can understand it, and server make decision to use this or not. Only mta's must do registration.

We have thought next idea for put together smtp sender (=mta) checking using ip and reverse DNS without big changes.

Main idea is like firewall: stop everything except...
No changes for rfc, software, ...

I have read many proposal (quickly), but if I have understood correct, all those ideas based on domain attributes and define new attributes using domain database, not real ip checking using reverse dns attributes as I like todo, same way as all other security / access has mostly defined, ip based priviledges. My idea is only worldwide "trusted mta list". Lot of same as RBL but reverse ... not blacklist, database which tell is this mta registered. Release 2 include also posibilities to register blocked mta.

Ofcource we can use this idea also to build simple distributed "trusted clint/server" database in any services but that is other story.

Today

Today many smtp receivers check spam mails/sender/... using
To:
From:
MAIL FROM
RCPT TO
Subject:
and other headers, MIME-types, .... + lot of rbl-servers.

Problems are with new open relays, using dynamic ip "selfmade" smtp-servers, ..., new spam ideas,... so we add more and more rules.

Why do not translate method ? Same idea like firewall. Stop everything except from registered MTA. Controlling connection, not only protocol.

Operators have to define registered MTA's same way like NS (and MX) are for domains.

Today every services based mostly on domain rules, but mostly smtp sending has done using operator's networks smtp-server, not domains. Ofcource operator can add more power to check all outgoing smtp session open function. Only registered MTA's can open connection. That it is other very powerfull method.

Need to check: Do we trust for this caller (MTA)? This checking is done with reverse lookup, based on host reverse lookup, not domain's rules. If we use reverse MX like we use MX in domain ? Every dns work now. Today many server allready make reverse lookup for mta's. If we define one step more ? Reverse will tell also that operator has defined this mta is "well known", trusted, ...

Today we have done lookup for record PTR, next step is todo MX. Still only one lookup, using MX, not PTR. Or we can extend rDNS and create new subhosts. in-addr.arpa. -domain is domain, so we can make also extension like smtp.103.204.197.194.in-addr.arpa.. Which mean that ip has subdomain and we can use that to define addon rules for ip using defined QTYPEs (TXT,PTR,A,MX,...).

Use MX record in reverse dns

Query result format ? Something like RBL use = very easy to add new feature or some text string. It's very slow method to add new QTYPE to DNS, but using old QTYPE adding new subdomain, it's very easy systemto add and works also with old bind4.

Example:

103.204.197.194.in-addr.arpa.    IN    PTR bim1.awot.fi.
                                 IN    MX    10 127.0.0.2.
121.204.197.194.in-addr.arpa.    IN    PTR ts2.netstar.fi.
                                 IN    MX    10 127.0.0.2.
101.204.197.194.in-addr.arpa.    IN    PTR ts2.netstar.fi.
                                 IN    MX    10 ok.

Maybe we can also handle those MTA's which has blocked by reverse DNS ? If ex. we saw / get alert that some MTA from our net use smtp not acceptable way, we can add record which will tell that block that ip.
Example if ip 194.197.204.104 is open relay and what ever:

104.204.197.194.in-addr.arpa.    IN    PTR ts2.netstar.fi.
                                 IN    MX    98  127.0.0.3.
                                 IN    MX    99  open.relay.
;-or- many other posibilities, MTAmark has produced also many other
; method to use rDNS
smtp.103.204.197.194.in-addr.arpa.    IN    PTR bim1.awot.fi.
smtp.100.204.197.194.in-addr.arpa.    IN    PTR not.allowed.
smtp.100.204.197.194.in-addr.arpa.    IN    TXT "not allowed"
smtp.100.204.197.194.in-addr.arpa.    IN    TXT "0 not allowed, open relay"
smtp.100.204.197.194.in-addr.arpa.    IN    TXT "1"
;--

We can use priority attribute or host attribute ...
After our customer fix mta, then we can remove block record or set registered status on.

How it works ?

After server get connection, server looks sender ip, make reverse check:

make reverse dns - record MX, you will get some answer
check lookup answer and if you get answer okay then continue session ...
if not, give some standard smtp answer like 551 5.7.1 your MTA is not registered
or drop connection. Smtp error message will be better, because it'll tell the reason why connection has dropped.

If you like to contact for dns manager, then make soa query. No need to add any other contacts. Maybe txt field for ns/domain level, where is some url or some other helpfull information.

SMTP-server / fw / ... todo list

First look, is this ip from my network ?
If not, check is this sender registered. (Look previous section).

In this idea every mta which make smtp connection to Internet, must be registered. So if you have not registered mta, then you must use smart relay / proxies like normal mail clients works.

Example:

dig @194.197.204.121  103.204.197.194.in-addr.arpa. mx

- if you get record, then it's registered

Same way like use to found mail route using MX record, in reverse "world" you can lookup octet's MX-records and get the list of trusted mta's.

Example:

dig @194.197.204.121  204.197.194.in-addr.arpa. mx

and you will get answer like something:


204.197.194.in-addr.arpa.   IN MX  10 194.197.204.101.
204.197.194.in-addr.arpa.   IN MX  10 194.197.204.121.
204.197.194.in-addr.arpa.   IN MX  10 194.197.204.194.
204.197.194.in-addr.arpa.   IN MX  10 194.197.204.103.

Or using nslookup:

Cmd > nslookup
> server 194.197.204.121
> set q=MX
> 101.204.197.194.in-addr.arpa

And guess what you'll get? You got it! answer, is this registered or not.

Roaming client

If use dhcp or some other dynamic method, how about those mta clients?

smtp-server check reverse mx -> no priviledges -> must use smart relaying, it's also simple because dhcp option 69 give posibilities to tell smtp-server(s).
RFC 2132

Example script

I have made script rmx which can check ip hostname, ip netdomain, ip mx

Using: 
  rmx 194.197.204.103 hostname
  rmx 194.197.204.103 net
  rmx 194.197.204.103 mx
  rmx 194.197.204.101 mx
  rmx 194.197.204.101 contact
  rmx 194.197.204.104 mx   	;# ex. blocked mta
or using some nameserver like in dig ex.
  rmx @194.197.204.121 194.197.204.101 mx

Update software, firewalls, ...

Simple feature add to tcpwrapper, smtp-proxy, smtp-server and so on. Control connection, and after open connection maybe look also inside smtp data = current filter method. Just like in real life, we have only some postoffice, not in every home/office.

We think that this is possible to do worldwide very quickly, using ex. whois databases and apnic+arin+lacnic+ripe databases. I mean add those reverse MX records for MTA hosts.

no need to update dns software
only reverse mx record have to update = reverse dns operators job
no need update mailservers, but if you like control caller, you can add simple method
on mailservers you can give standard answer like 5xx your smtp server is not registered
more powerfull & simple to update than update rbl, spamrules, ...

ReverseMx.org include some examples to use RMX.

Base using is check the caller and if we can trust that every mta router make same checking, then we have registered mta route.

Ofcource we can parse smtp header and check all mta routers from source mta to last router. But then we get maybe wrong results, because even mta has public ip, it has used smart relaying using registered mta. So control works same way like other routing protocols, we have to communicate with next router and operator of that router will communicate with next and so on. On some step we found problem and maybe add that net/mta/... to some blacklist (RBL, RMX, ...).

But as we have seen, everybody are not understand what is good and what is really stupied. Still we need blocking, blacklist, ... to blockout those who don't understand why have made some rules. Even we are using LMAP, RMX,.. methods ...

-jukka-

Too simple to be true ? That I'm asking.

Comments ? security1 at awot do.t fi

PS. as you see, english is not my primary language (ksh is), but I hope that idea has understood.

Static:
About 25% senders ip has not name in reverse nameservices.

Comments

27 Nov 2003 I got mail, which include hint to look MTAmark
It's give lot of same ideas as this document.
MtaMark draft.

29 Nov 2003 changed to make only one lookup, based on MTA's IP.