Kevin
Much depends on your SMTP server.
Does your server validate or check recipients (RCPT TO) immediately at
SMTP? Or is your server accepting the RCPT TO: and then validating the
destination in POST SMTP mode?
If the latter, here lies one of the exploits for the SORBIG-based generation
virus relying on your system to bounce the unknown recipient address back to
the MAIL FROM address which is spoofed.
If more systems validated the RCPT TO: address, we would have less of a
bounce problem. A bounce is reduced to a relay situation only which is
authorized by your system anyway. That is not problem bounce.
Systems who don't validate the user at RCPT say it protects against
harvesting. That is a red herring. In fact, spammers could care less as
long as you do accept it. In their book, that's one foot in the door and
good enough to kept hitting your system. And the virus writers, well, they
just love systems that don't validate RCPT TO to help in their 2nd tier
distribution - the bounce.
On my system, my anti-spam stats show a 25-30% rejection at RCPT TO: If
you have a big bounce problem, then you will also have a high rejection too
at RCPT TO: Turn it on your software, if you can, and you will begin to
address a major part of the problem.
Now for valid RCPT TO:, this is where you want to add SPF to add another
level of protection for your legitimate users.
Note: The problem with performing POST SMTP validation in this day of age is
basically what you are seeing now. With just spam, it was a big issue, but
spam didn't kill anyone per se. When SORBIG was released, the spam SMTP
exploitation was now used maliciously. That was the last straw for us.
SPF works, but because everyone is not using it and you certainly can't
count on spammers/hackers to be SPF compliant, if they were is only to
further lie to you, you simply can't use this as a basis for POST SMTP "bit
bucket" rejection. You really got to stop that from sending the junk in
the first place.
--
Hector Santos, Santronics Software, Inc.
WIN Server - Wildcat! Interactive Net Server
wcSAP - Wildcat! Sender Authentication Protocol
http://www.santronics.com
----- Original Message -----
From: "Kevin Kolk" <kkolk(_at_)cng(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, April 30, 2004 5:20 PM
Subject: [spf-discuss] SPF & Bounced Emails
I've been reading over the SPF site and articles regarding the system
however one thing isn't entirely clear to me - how well the system can
help me block bounced email messages.
While I understand that this system will allow supporting domains to
validate if the email came from my systems and block receipt without
generating a bounce message to me, I'm not sure how it deals with bounce
messages from non-supporting hosts. Is there a way that I will be able
to examine incoming bounce messages using this system to validate if
they actually came from my system originally and filter those that did
not?
I'm looking for a way to combat the increasing number of false bounced
messages we are receiving and will still be receiving for domains not
supporting SPF. It's clear to me that this will reduce them somewhat,
however I'm quite interested in knowing if it can block them completely
or nearly completely with additional filtering on my side. I'm working
on writing a proposal to submit to my management regarding implementing
SPF and I definitely have plenty of flexibility to suggest fairly
significant changes to our current email system if it will reduce or
eliminate these false bounced messages.
Is there a way for me to use this to be able to filter out bounce
messages that are sent to my systems due to forged emails being sent to
non-SPF supporting domains?
(Note: I also sent this to the help distribution list, however after
reading the description of the lists I'm not sure if it's better to send
it to this one or not. Sorry for the double posting)
Thanks,
Kevin Kolk
Network Security Technician
The CyberNET Group