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@hjp.at | __/ | http://www.hjp.at/ | -- Alexander Bartolich in at.linux
Attachment:
pgp00080.pgp
Description: PGP signature