On Tue, 17 May 2005, Matt Fretwell wrote: > > True, but it could helo with its hostname and then it would match > > connecting back to check its 220 string. Even if its a sending server, > > it should listen on 25 to verify that it is a mail server, even if it > > doesn't accept mail. If it doesn't listen on 25 (or isn't accessable) > > then it is a client and should be using some type of smtp-auth with the > > server to relay through it, or to one of its recipients. IMO, If you > > send a lot of mail, you should listen on port 25, even if you don't > > accept mail. > > > By that theory, we should ban most large providers and mailing lists. > There are a countless number of companies that allow outgoing connections > only from their servers. That theory is vastly flawed and will not work. > Period. Also, any sending server is a client, irrelevant of whether it > works in client and server mode. The connecting machine is *always* a > client.
What I am saying is that if you can't do some type of verification, whether it is connect-back (remember the old dialup callback-verification-system?) to the sending server or SPF or some other type of authentication mechanism, then you can't trust the sender. Really even SPF isn't great because DNS can be spoofed. Unless the source can can prove its origin, it can not be trusted. In fact, most spam is a form of false identification and that, in of itself, is the problem. Authenticate all of the MTAs in a way that MTA's trust each other and you have fixed much of the problem. Setting up DNS properly is a step in the right direction since most spammers/virus pushers do not properly implement DNS. The ultimate goal is only to send email from real addresses to real addresses. That way spammers would need real accounts to send through. Currently, most spam comes from addresses which do not exist. Many MTA's fail to require that an MX exists for the MAIL FROM domain and accept huge amounts of spam. To really fix the problem we would need to talk about a trusted third party and certificates for mail servers, much as https is handled to avoid repudiation of origin attacks like spam. I think that is where Microsoft is going, but I don't like it. I'm hoping for a simpler solution and SPF is heading in the right direction though it is not right for all situations. The hard part is that SMTP is the worlds least secure protocol so we are trying to patch it with DNS and other mechanisms, but the reality is that it is a broken design from a security standpoint. What I am arguing will reduce the exposure to the problem, not eliminate it. I'm not sure what is next, but I look forward to the RFC which replaces SMTP as a standard. In the next ten years, this will all be different and it may take less time than that. -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
