Comments on: Why you need to keep false-positives to a minimum http://www.allspammedup.com/2009/02/why-you-need-to-keep-false-positives-to-a-minimum/ Wed, 08 Feb 2012 11:22:23 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Weekend reading - subject: exchange http://www.allspammedup.com/2009/02/why-you-need-to-keep-false-positives-to-a-minimum/comment-page-1/#comment-1689 Weekend reading - subject: exchange Sun, 08 Feb 2009 12:13:28 +0000 http://www.allspammedup.com/?p=388#comment-1689 [...] Why you need to keep false-positives to a minimum [...] [...] Why you need to keep false-positives to a minimum [...]

]]> By: Zerolove http://www.allspammedup.com/2009/02/why-you-need-to-keep-false-positives-to-a-minimum/comment-page-1/#comment-1676 Zerolove Fri, 06 Feb 2009 04:27:00 +0000 http://www.allspammedup.com/?p=388#comment-1676 So true, nothing worst then B2B email's being marked as spam. This is a big no no at my job. But on a side note, I deal with some very large law offices. One is a bankruptcy office, and when the bankruptcy courts went digital and they started sending auto replies back to the clients they used xxx@something.uscourts.gov this has now changed for obvious reasons. So true, nothing worst then B2B email’s being marked as spam. This is a big no no at my job. But on a side note, I deal with some very large law offices. One is a bankruptcy office, and when the bankruptcy courts went digital and they started sending auto replies back to the clients they used xxx@something.uscourts.gov this has now changed for obvious reasons.

]]> By: Steve Freegard http://www.allspammedup.com/2009/02/why-you-need-to-keep-false-positives-to-a-minimum/comment-page-1/#comment-1674 Steve Freegard Fri, 06 Feb 2009 00:40:00 +0000 http://www.allspammedup.com/?p=388#comment-1674 Interesting article. The root problem is software that discards spam that exceeds a certain threshold or having a quarantine that either isn't checked or has so much mail in it that the user can't see the false-positive amongst all the spam due to the low signal-to-noise ratio common to a lot of spam filters. I've long come to the conclusion that with spam volume exceeding 80% of input at many sites now - the far better way to deal with this is to do anti-spam at the SMTP phase rather than post-queue; if it scores above one threshold then tag the message (e.g. ad [Spam] to the subject and an X-Spam-Status: YES header) and deliver it to the user and if it exceeds another higher threshold then reject it outright. This is far better as it uses SMTP like it was designed - the sending server has the burden of responsibility to deliver the message; if you reject the message at the SMTP level the sender has to generate a non-delivery receipt (NDR) to the sender informing them the message wasn't delivered. If the message was from a 'real' user then they know it wasn't delivered and can take action (the NDR will contain the rejection message that you sent - this could include a URL for whitelisting or a unfiltered address etc.), if the message was spam then the spammer won't care and will move on. No backscatter is caused by this method, false-positives are no longer a big disaster and it avoids the issues referred to in your article. My only wishes are that Exchange could be configured to automatically move messages to the Junk Folder in Outlook based on incoming headers without having to write custom event sinks. And that it doesn't default to mangling incoming NDRs into it's own format losing a lot of the relevant data in the process (e.g. like 'Friendly HTTP error messages' setting in IE). I agree with your sentiments about aggregated whitelists - I've seen many users add 'hotmail.com' to them and then complain about the onslaught of spam that then follows. When aggregating lists now - I only accept full e-mail addresses (e.g. user@domain.com format); not sure if the Safelist Aggregation in Exchange can do that - but if it can; it's definitely the way to go. Interesting article. The root problem is software that discards spam that exceeds a certain threshold or having a quarantine that either isn’t checked or has so much mail in it that the user can’t see the false-positive amongst all the spam due to the low signal-to-noise ratio common to a lot of spam filters.

I’ve long come to the conclusion that with spam volume exceeding 80% of input at many sites now – the far better way to deal with this is to do anti-spam at the SMTP phase rather than post-queue; if it scores above one threshold then tag the message (e.g. ad [Spam] to the subject and an X-Spam-Status: YES header) and deliver it to the user and if it exceeds another higher threshold then reject it outright.

This is far better as it uses SMTP like it was designed – the sending server has the burden of responsibility to deliver the message; if you reject the message at the SMTP level the sender has to generate a non-delivery receipt (NDR) to the sender informing them the message wasn’t delivered. If the message was from a ‘real’ user then they know it wasn’t delivered and can take action (the NDR will contain the rejection message that you sent – this could include a URL for whitelisting or a unfiltered address etc.), if the message was spam then the spammer won’t care and will move on. No backscatter is caused by this method, false-positives are no longer a big disaster and it avoids the issues referred to in your article.

My only wishes are that Exchange could be configured to automatically move messages to the Junk Folder in Outlook based on incoming headers without having to write custom event sinks. And that it doesn’t default to mangling incoming NDRs into it’s own format losing a lot of the relevant data in the process (e.g. like ‘Friendly HTTP error messages’ setting in IE).

I agree with your sentiments about aggregated whitelists – I’ve seen many users add ‘hotmail.com’ to them and then complain about the onslaught of spam that then follows. When aggregating lists now – I only accept full e-mail addresses (e.g. user@domain.com format); not sure if the Safelist Aggregation in Exchange can do that – but if it can; it’s definitely the way to go.

]]>