SpamSentinel Now Blocks Spam at the SMTP Level
Tags: SpamSentinel
So, in reply to some of my postings, many people replied that they want to stop the spam at the SMTP connection layer, a feature RBLs provide. You want to cut down traffic and work on the Lotus Domino email server.
We hear you loud and clear.
In a frantic week of development and testing, we have enhanced SpamSentinel to reject spam during the SMTP connection.
And the results are truly fantastic!
On our inbound SMTP gateways, SpamSentinel v 7.5 stops over 90% of email received during the SMTP connection but before the mail is accepted. This is a full 10%, better than any RBL (I tested with Spamhaus and Spamcop, which together averaged 78%). The remaining 12% is picked up and caught as spam at the Domino server or as a virus using our Norman anti-virus checking.
There are two ways to stop mail at the SMTP gateway: Silent Delete and Reject. The silent delete does not give any information to the spammers. We let them connect, and 88% of the time, we terminate the SMTP connection without saving the message. The other method is a PERMFAIL (we use the generic 554 PERMFAIL option), which rejects the SMTP connection. Given that most spammers do not really exist, and that our SMTP servers are talking many times to a BOT, I prefer the silent delete.
In our tests, this is blazingly fast, and reduces bandwidth and server activity significantly.
No False Positives in Rejected Mail
v 7.5 also has no false positives in what it rejects. This is based on actual experience for Spam-D classification which is in use across thousands of servers and based on hundreds of millions of messages processed. If SpamSentinel does make a mistake, it would show up in the Quarantine as Spam-B or Spam-C. Because this is a Lotus Notes database, users can retrieve these blocked messages.
Anyone who wants this version right away, email me Frank Paolino and I will get you the software.
Daily Spam Statistics
Here is a snapshot of the daily statistics for one of our actual SMTP inbound servers. The results on this server are better than 88%, as it is the second SMTP server, which gets mostly spam, so 92.5% of messages were silently deleted. Most people should expect 88-90%. The 4,764 messages that our Domino server has to process brings us back to the levels of spam received in early 2005!
So, in reply to some of my postings, many people replied that they want to stop the spam at the SMTP connection layer, a feature RBLs provide. You want to cut down traffic and work on the Lotus Domino email server.
We hear you loud and clear.
In a frantic week of development and testing, we have enhanced SpamSentinel to reject spam during the SMTP connection.
And the results are truly fantastic!
On our inbound SMTP gateways, SpamSentinel v 7.5 stops over 90% of email received during the SMTP connection but before the mail is accepted. This is a full 10%, better than any RBL (I tested with Spamhaus and Spamcop, which together averaged 78%). The remaining 12% is picked up and caught as spam at the Domino server or as a virus using our Norman anti-virus checking.
There are two ways to stop mail at the SMTP gateway: Silent Delete and Reject. The silent delete does not give any information to the spammers. We let them connect, and 88% of the time, we terminate the SMTP connection without saving the message. The other method is a PERMFAIL (we use the generic 554 PERMFAIL option), which rejects the SMTP connection. Given that most spammers do not really exist, and that our SMTP servers are talking many times to a BOT, I prefer the silent delete.
In our tests, this is blazingly fast, and reduces bandwidth and server activity significantly.
No False Positives in Rejected Mail
v 7.5 also has no false positives in what it rejects. This is based on actual experience for Spam-D classification which is in use across thousands of servers and based on hundreds of millions of messages processed. If SpamSentinel does make a mistake, it would show up in the Quarantine as Spam-B or Spam-C. Because this is a Lotus Notes database, users can retrieve these blocked messages.
Anyone who wants this version right away, email me Frank Paolino and I will get you the software.
Daily Spam Statistics
Here is a snapshot of the daily statistics for one of our actual SMTP inbound servers. The results on this server are better than 88%, as it is the second SMTP server, which gets mostly spam, so 92.5% of messages were silently deleted. Most people should expect 88-90%. The 4,764 messages that our Domino server has to process brings us back to the levels of spam received in early 2005!
| Permalink | 
-
Comments
Posted by Vaughan Rivett At 06:04:58 PM On 04/17/2008 | - Website - |
Is really better way stop spam before hit server storage and consume bandwith. Past few years did prove accuracy of SPAM detection by SpamSentinel so I'm not afraid about loosing important e-mails. In rare cases it can be easilly diagnosed by having full logs and using proper white lists.
Posted by Eduard Svarc At 05:06:20 AM On 04/17/2008 | - Website - |
Posted by Greg Nash At 06:45:10 PM On 04/16/2008 | - Website - |
If a single spam-bot sends multiple (separate) messages to the same server, would it give up after a few rejections?
Do spamming networks ever try to clean up their own lists?
A few years ago we had "reject messages addressed to unknown users", but kept getting targeted with dictionary attacks to find valid addresses. We turned that off, but have since added some ex-staff addresses to an explicit "reject" list to reduce volume (a little).
Posted by Greg Nash At 06:38:07 PM On 04/16/2008 | - Website - |
Unfortunately, IP information alone is not enough to maintain the high accuracy levels our customers demand of SpamSentinel. IP reputation is just one component of our spam blocking technology. We also utilize a community of millions of spamfighters to identify spam. Their spam reports are put into a real-time database as message signatures, like checksums. When we peek at the data from an incoming SMTP connection, we take a signature on parts of the data and see if it is in the database. If the data signature is present, that provides critical additional information to make a positive determination of a message as spam.
So, even if a good message comes through a server that has a bad IP reputation, for example, we would not reject it. Conversely, if a spam message comes from a server that does not have a bad IP reputation, we will stop it because we have the advantage of multiple inputs into the "spam/good mail" decision process.
Posted by Frank Paolino At 12:22:35 PM On 04/11/2008 | - Website - |
In response to JR Lillard's question you mentioned that spamsentinel has access to some more antispam information than just an IP Address, what more information is that? Can you please elaborate more on the process?
Posted by Yousuf At 10:28:49 PM On 04/10/2008 | - Website - |
Our problem with the RBLs is that they provide only one piece of data to make a reject determination.
SpamSentinel has access to more anti-spam information than just the IP address. We use that information to examine some of the body, enough to be perfectly confident that we can reject the message. That takes a little more bandwidth. We think the tradeoff for 100% rejection accuracy is well worth it.
Posted by Frank Paolino At 12:49:25 PM On 04/10/2008 | - Website - |
Posted by Francois Koutchouk At 12:08:01 PM On 04/10/2008 | - Website - |
Posted by J.R. Lillard At 11:15:21 AM On 04/10/2008 | - Website - |
Posted by RichG At 04:19:30 PM On 04/08/2008 | - Website - |
Posted by Paul Gagnon At 08:58:42 PM On 04/07/2008 | - Website - |