On Wed, Mar 13, 2002 at 11:13:07AM -0500, Mark Komarinski wrote: > I had an interesting thought today, but it's a real strange one, so > follow along: > > Most spam shows up with bad headers like the From: line saying > "[EMAIL PROTECTED]". Is there any way for an MTA to reverse-VRFY > a sending account before allowing the communication to continue? I > know a lot of mail systems disable VRFY, since it allows a spammer > to find out who is there, but that's pretty much dead anyway since a > spammer can just send e-mail to [EMAIL PROTECTED] through [EMAIL PROTECTED] > and filter out the bounces. Given all the null e-mails on my yahoo.com > account, this is being done. > > So back to the idea. When "[EMAIL PROTECTED]" wants to > deliver something to me, why can't the MTA hit the MX for mail.com > and VRFY that the account is valid? If it's valid, it comes > through. If not *wham* gets immediately flagged as spam and goes > to an alternate box or whatever. > > Or can procmail do this? > > -Mark
Unfortunately, I don't think this will work. Many organizations use a mail relay through which all of their internal mail hits before it goes outside the organization. Sometimes they strip headers and such for security reasons, but in almost all cases like this, no account for the user exists on the relay. (Note, I'm not talking about OPEN relays here, just a relay that forwards stuff from the internal net out to the wider internet.) In these cases, vrfy will fail. I do think smtpblock (as mentioned in my mail last week), in general is a good idea. The problem still remains whether or not it's acceptable to do relay-checks. I think that it should be okay, provided the software is smart enough to not continuously and/or incesantly checking a relay that it has already determined as closed (ala ORBS). For open relays, I almost don't care because these dolts should be locking down their boxes, anyhow. Once they do, my relay check should return a negative and stop checking them for a while. Regardless, though, once I find an open relay, I have no problem blocking mail from it for, say, two weeks, and only then checking it again. Incidentally, what I *really* like about smtpblock is that it takes the firewall approach to blocking mail. This can keep the load on smtp server down significantly. I'm sure that as the number of entries in the iptables/ipchains list goes up, the time spent in the kernel actually determining whether or not the packet should be accepted can go up, but from personal experience, I can say that the tradeoff is in favor of using iptables over smtp rejection. That's, of course, anecdotal, not scientific. A better way to implement an smtpblock like strategy, however, might actually be to use sendmail's libmilter (if you're using sendmail). I'm actually looking at that possibility now. With milter, you could actually run filters on separate machines that do the actual relay checks. That way you could perhaps let a few messages from open relays slip through while you hand off the smtp peer IP address to a milter that does the check. All future mail from the IP could be rejected (by another milter) for a specified period of time until another relay check is done. (Or, you could use the firewall approach described above.) Doing it this way could also keep some of the load off of your MX machine. What I do like about your idea is it takes an approach that I've been advocating for a while that a large percentage of the anti-spam approaches don't. You acknowledge the need to reject the mail before it even shows up in your organization's mail queues. If I'm going to reject spam, I don't want it even entering my machine -- I want to slam the door in the face of the spammers. AND those that make it easy for spammers to spew their garbage -- the open relays. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
