On Mon, 16 May 2005, Bill Taroli wrote: > Matt Fretwell wrote: > >plenty of legitimate MTA setups running on dynamic IP's. [...] What > >really does amaze me though, is that these are generally the admins who > >will turn around and say, 'Don't block (variable), you will lose too > >much legitimate mail'. Where is the logic in that? They will allow a > >crappily configured multinational corporation or ISP to connect, yet not > >give dynamics the slightest chance to prove their reliability. > > > I don't think it's a matter of reliability... it's more an issue of > accountability and traceability. How can one trace back to a dynamically > IP'ed MTA when it's dynamic? DynDNS doesn't prove itself in the majority > of cases, or isn't even used. Some of these are even worse because the > mail is coming from a NAT'ed host from behind a dyn IP firewall, which > won't even allow return messages -- and I suspect this is extremely > common. Kind of like an inverse roach motel for email. > > I don't disagree that there may well be many people running wholesome > MTAs on dynamic IP's that suffer for the rest. But it's that rest we're > all concerned with. I honestly wonder whether an authorization framework > such as SPF would be the salvation of such setups... permitting them to > prove themselves worthy without the need for static IP addresses. > > But until that time comes, any host who appears to lie about it's > identity by giving a host name that doesn't match it's visible IP > address is getting the door slammed in it's face by my MTA.
Once upon a time, email was simple. It carried text. Later people got smart and started UUEncoding binary data into emails and other proggies like shar (still text) were born to transfer data across email. Since then, email has blown up and we have lost much of the MTA standardization which existed when during a younger Internet. The encoding mechanisms (base64, etc) are all RFC standards and MUA's follow them, but the MTA's need to be setup a little bit stricter. Requiring forward-and-back dns lookups is a good idea if everyone would cooperate. Back in the early 90's, most addresses would forward-and-back dns lookups and certainly all MTA's or servers offering a real service (http/ftp/rdiff) did. It seems that we have moved away from a consistent Internet with rules which were followed as a courtesy to sysadmins. We have now moved into a much more liberal (broken?) Internet where we try to make anything go and still have it function. Remarkably, it does for the most part despite all the garbage that floats across the line (just tcpdump a cable line sometime and see whats there). For email transfer and MTA's alike, putting SPF in DNS to help "authenticate" the source is a step in the right direction. If SPF is a good idea, and it is dns based, then so should forward-and-back lookups. If additional mail standardization can take place (again) then spam can be reduced to a certain degree. I much like Brian Read's idea of blocking mail xfer from sites which are not authenticated (SASL) or who cannot give a proper reverse lookup. Every ISP we have worked with have been happy to create or change a PTR entry in their dns, even if it took a lot of work to get the ISP to do so (I even offered to do it for one isp and they finally did it themself). If we can standardize the set of rules and protocols required for an MTA to accept an email, then spam will reduce. Either that or we need to build a better mousetrap. This is jut my $0.02. Your thoughts? -Eric -- Eric Wheeler Vice President National Security Concepts, Inc. PO Box 3567 Tualatin, OR 97062 http://www.nsci.us/ Voice: (503) 293-7656 Fax: (503) 885-0770 _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
