Re: [Asrg] whitelisting server and not users

On 2003-04-02 23:28:14 +0200, Markus Stumpf wrote:

On Wed, Apr 02, 2003 at 04:06:32PM -0500, Kee Hinckley wrote:

Too many ISPs don't provide reverse DNS to their customers, but do 
allow mail servers.  And many of those that do provide reverse DNS, 
reverse it to their own domain, not the sender's domain.


So what? What do you think is a minor problem:
  - adding a DNS record to the reverse zone
  - installing a new system for user administration and lookups


I think the major problem in your proposal is to actually get people to
use it. 

On the receiver's side, I don't want to reject any legitimate mail. So I
cannot use it to reject mail until a very large percentage (say > 99%)
of all sites sending mail to my users are using your scheme to whitelist
their outbound MTAs. Because until then I cannot reliably distinguish
between "this is not a valid relay" and "the postmaster of this machine
has not yet heard about RFC xxxx". Therefore, nobody will use it to
block mail.

On the sender side, it is easy enough to implement, but until people
actually start blocking mail, there is no incentive to do it. 

So there is a vicious circle: Servers cannot implement it until the
clients do and the clients won't until the servers do.

But I think I have an idea how that can be broken. See below.

envelope -> domain -> lookup ip at domain


No, no, no ;-)
In my proposal I want to get rid of all the "I don't want you to be a
mailserver" hosts, i.e.
- workstations that are worm/virus infected
- workstations that are misconfigured and run
  - proxies that nobody knows about
  - SMTP servers that nobody knows about
- hacked DSL users
- thousands of hosts in universities that are not blocked by campus firewalls


I think we can get rid of most of these with the RMX-like schemes, too:
Neither infected nor misconfigured workstations nor random hosts at
universities will have an RMX record pointing to them, so they cannot
send mail (except via their designated smarthost). That leaves proxies
and open relays. For these a spammer has to use his own domain and
operate a DNS server, which makes him traceable, easier to block, and
may also limit the number of proxies he can use (although the latter is
probably only short term until spammers learn to use specialized DNS
servers).

Unlike your WL scheme, the RMX schemes can be implemented gradually and
both senders and receivers have an advantage of doing it:

As a receiver, I won't get false positives, so there is no danger of my
own users lynching be because they didn't get an important mail. In the
beginning, it won't reject much spam, but as it doesn't cost much, even
the little it does is good.

As a sender, I helps me to repudiate spam with forged sender adresses.
"My official servers are listed in DNS, and that isn't one of them. I am
not responsible for that mail". If one of big mail providers starts
using that they can seriously cut into the spam with their addresses,
which is good for them (less mail to abuse, less bounces, better image)
- again, at first only a little, but as more receivers implement it, it
helps them more.

I don't want to look at domain names or email addresses, I just want to
look at IP addresses, like in DNSBLs, but it is a DNSWL and the people
that are in charge of maintaining the reverse zone can whitelist hosts.


What your scheme needs to be deployable is a way to mark an address
range as using whitelists. Lets say I control IP ranges 10.130.16/24
and 10.130.48/20, but not 10.130.32/20. There are three hosts which
can send outbound mail, 10.130.16.2, 10.130.50.18 and 10.130.50.112.

Then I can add 

*.16            IN  TXT   "no smtp"
2.16            IN  TXT   "smtp out"

*.48            IN  TXT   "no smtp"
*.49            IN  TXT   "no smtp"
[...]
*.63            IN  TXT   "no smtp"
18.50           IN  TXT   "smtp out"
112.50          IN  TXT   "smtp out"

to the zone file of 130.10.in-addr.arpa, and an SMTP server trying to
validate a connection from a host would just do a lookup in
<rev.ip>.in-addr.arpa. TXT (as in your scheme). However, because of the
wildcard records he can have four different results:

TXT "no smtp"   - this is definitely not an outbound SMTP relay
                  (reject the connection)
TXT "smtp out"  - this is an outbound SMTP relay
                  (accept the connection)
NXDOMAIN        - we don't know about whitelists.
                  (accept the connection)
SRVFAIL         - dns problem
                  (drop connection with a temporary failure)

Does that sound feasible?


        hp

-- 
   _  | Peter J. Holzer    | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR       | zu Fortran.
| |   | hjp(_at_)hjp(_dot_)at         |
__/   | http://www.hjp.at/ |    -- Alexander Bartolich in at.linux

pgpPB5DYMh8Du.pgp
Description: PGP signature