Re: Bouncing spam vs. Blackholing spam
On Aug 10, 2006, at 9:00 PM, jdow wrote: From: "John Rudd" <[EMAIL PROTECTED]> On Aug 10, 2006, at 1:58 PM, Marc Perkel wrote: I've been blocking a lot of spam at connect time that I am 100% sure is spam. However I'm wondering if that is the best idea because it gives spammers feedback as to what works and what doesn't. If I silently absorb the spam and let the spammers think it's delivered then they have no way to know if the spam is getting through or not. Thoughts? My thought is: silently deleting email (spam, virus, etc.) a violation of RFCs, and I'm not interested in doing that. I'm more interested in correctly handling the false positives than what happens with true positives (I know, you said you're 100% sure it's spam, but I don't believe in such a thing as automated detection of spam that results in a 100% confidence value). So, the next generation anti-spam mechanism I'm working on for work will reject spam during the SMTP session with a 5xx code. I'm planning on rejecting at a score of 10. This means that if it's a directly attached spam zombie, it will just disappear ... but in a way that doesn't make me an RFC violator. If it's a false-positive, then the sender will know that their mail disappeared. If it's being submitted by an intermediate relay (such as the spam-zombie's ISP's mail server), then it may get bounced back to an innocent third party. But I don't consider that to be _my_ fault/responsibility. I consider that to be the fault/responsibility If I receive a message in my mailbox from a site bouncing email I did not send I place that ENTIRE ISP on my /dev/null list ucsc.edu or not. It simply turns YOU into a spam relay. If you simply reject it that's a somewhat different ballgame. That's what I said: I reject the messages. During the smtp session. It gets a 5xx SMTP response. The "it may get bounced back" comment was specifically that the intermediate relay might bounce it. I'm not bouncing it, I'm rejecting it. of the intermediate relay for not having spam-scanned and rejected the message themselves. By not accepting the message, I am not accepting responsibility for the message's fate, either. If I were to accept the message, THEN it becomes my responsibility to ensure that the message doesn't disappear nor get bounced back to an innocent third party. It is not the intermediate relay job to spam scan. Its job is to forward HUGE amounts of email to its proper destination. If it has to filter as well then the problem magnifies exponentially. I disagree. It is _every_ mail server's responsibility to be accountable for any email it accepts, even mail that isn't ultimately destined for them. If you're relaying spam, you're relaying spam. If you're relaying viruses, you're relaying viruses. No rationalizations count. Not even the "I'm relaying for my customer" nor "I'm the final destination's MX server" rationalizations count. Relaying spam and/or viruses is relaying spam and/or viruses. Of course, part of that responsibility is letting people who use you as a relay know what your policies are (so that if they don't like your policies they can move to a different service), but ... I stand by the assertion that it is the fault of the intermediate relay for bouncing spam back to a third party, and not the fault of the destination which rejected the spam. If the intermediary doesn't like getting black listed for it, then they shouldn't have accepted it into their queue in the first place.
Re: Bouncing spam vs. Blackholing spam
From: "John Rudd" <[EMAIL PROTECTED]>
On Aug 10, 2006, at 1:58 PM, Marc Perkel wrote:
I've been blocking a lot of spam at connect time that I am 100% sure
is spam. However I'm wondering if that is the best idea because it
gives spammers feedback as to what works and what doesn't. If I
silently absorb the spam and let the spammers think it's delivered
then they have no way to know if the spam is getting through or not.
Thoughts?
My thought is: silently deleting email (spam, virus, etc.) a violation
of RFCs, and I'm not interested in doing that. I'm more interested in
correctly handling the false positives than what happens with true
positives (I know, you said you're 100% sure it's spam, but I don't
believe in such a thing as automated detection of spam that results in
a 100% confidence value). So, the next generation anti-spam mechanism
I'm working on for work will reject spam during the SMTP session with a
5xx code. I'm planning on rejecting at a score of 10.
This means that if it's a directly attached spam zombie, it will just
disappear ... but in a way that doesn't make me an RFC violator. If
it's a false-positive, then the sender will know that their mail
disappeared.
If it's being submitted by an intermediate relay (such as the
spam-zombie's ISP's mail server), then it may get bounced back to an
innocent third party. But I don't consider that to be _my_
fault/responsibility. I consider that to be the fault/responsibility
If I receive a message in my mailbox from a site bouncing email I did
not send I place that ENTIRE ISP on my /dev/null list ucsc.edu or not.
It simply turns YOU into a spam relay. If you simply reject it that's
a somewhat different ballgame.
of the intermediate relay for not having spam-scanned and rejected the
message themselves. By not accepting the message, I am not accepting
responsibility for the message's fate, either. If I were to accept the
message, THEN it becomes my responsibility to ensure that the message
doesn't disappear nor get bounced back to an innocent third party.
It is not the intermediate relay job to spam scan. Its job is to
forward HUGE amounts of email to its proper destination. If it has to
filter as well then the problem magnifies exponentially.
{^_^}
Re: Bouncing spam vs. Blackholing spam
On Aug 10, 2006, at 1:58 PM, Marc Perkel wrote: I've been blocking a lot of spam at connect time that I am 100% sure is spam. However I'm wondering if that is the best idea because it gives spammers feedback as to what works and what doesn't. If I silently absorb the spam and let the spammers think it's delivered then they have no way to know if the spam is getting through or not. Thoughts? My thought is: silently deleting email (spam, virus, etc.) a violation of RFCs, and I'm not interested in doing that. I'm more interested in correctly handling the false positives than what happens with true positives (I know, you said you're 100% sure it's spam, but I don't believe in such a thing as automated detection of spam that results in a 100% confidence value). So, the next generation anti-spam mechanism I'm working on for work will reject spam during the SMTP session with a 5xx code. I'm planning on rejecting at a score of 10. This means that if it's a directly attached spam zombie, it will just disappear ... but in a way that doesn't make me an RFC violator. If it's a false-positive, then the sender will know that their mail disappeared. If it's being submitted by an intermediate relay (such as the spam-zombie's ISP's mail server), then it may get bounced back to an innocent third party. But I don't consider that to be _my_ fault/responsibility. I consider that to be the fault/responsibility of the intermediate relay for not having spam-scanned and rejected the message themselves. By not accepting the message, I am not accepting responsibility for the message's fate, either. If I were to accept the message, THEN it becomes my responsibility to ensure that the message doesn't disappear nor get bounced back to an innocent third party. As for giving spammers feedback: I'd be somewhat surprised if spam zombies actually give feedback to the source. If they do, then more likely than not, I'm actually going to be catching the zombies with my DNS checks (which happen before the spam and virus checks), so the feedback they'll get is: you don't have properly configured DNS, or your DNS makes you look like a dynamic/dialup host. Two things the spam zombie and the spammer can't control. For those that do get past that, sure, they'll see it was rejected because "it looks like spam". But they wont know what score they got (except if they read this thread and see my 10 cutoff), but they wont know what mechanism I used (I'll be using 2 anti-spam engines, so the 10 only matters for SpamAssassin). And, over time, they're going to be evolving around different engines anyway, so it's just part of the ongoing escalation and upgrade cycle.
RE: Bouncing spam vs. Blackholing spam
Marc said: >I've been blocking a lot of spam at connect time that I am 100% sure is >spam. However I'm wondering if that is the best idea because it gives >spammers feedback as to what works and what doesn't. If I silently >absorb the spam and let the spammers think it's delivered then they have >no way to know if the spam is getting through or not. >Thoughts? I give most incoming spam a "554" (rejected) response. I think that a "250" response code would cause the spammer to think it worked and got through. But I've often considered giving spammers a "550" "unknown user" response code in the hopes of motivating them (even more) to remove my addresses from their lists sooner. I do see a marked reduction in the amount of spam per user for customers I've had for a while in comparison to new customers. I attribute this mostly to (1) all the "554" response codes receive over the months during their attempts to spam my customers (2) lack of my users loading "image bugs" in their spams which alert spammers since there don't make it to my clients anymore (compared to before they were my mail hosting clients) Another consideration is that you put yourself more at risk if you say that you received it successfully and then a FP occurs. Of course, I know that this is next to impossible with YOUR system... and I don't mean that sarcastically... ;) But sending a "554" to a FP does serve a purpose in that it alerts the sender that something went wrong while a "250" response to a FP gives false confidence to the sender. In a sense, you've then "broken the contract". I "554" the 85% highest scoring spam and "250" the 15% "just barely caught stuff"... but then I take full responsibility for that 15% and do extensive auditing on it (mostly through automated tools) so that I can be confident that I haven't created FPs (and so that I can deliver rare FPs in a timely manner, as well as adjusting the filtering to prevent future FPs) Hope this helps! Rob McEwen PowerView Systems
Re: Bouncing spam vs. Blackholing spam
> I've been blocking a lot of spam at connect time that I am 100% sure is > spam. However I'm wondering if that is the best idea because it gives > spammers feedback as to what works and what doesn't. If I silently > absorb the spam and let the spammers think it's delivered then they have > no way to know if the spam is getting through or not. > > Thoughts? I don't know whether these zombies record success/failure from SMTP sessions, and/or report this to a 'central database'.. Nevertheless I switched during the last two years from REJECT-ing to DISCARD-ing in my postfix rules. At least in the rules I'm 100% sure about. Indeed I too don't want to give the spammers feedback. Regards Menno van Bennekom
Re: Bouncing spam vs. Blackholing spam
My personal opinion is that the spammers don't care either way. My guess would be that they probably don't even bother checking the logs of what worked and what didn't on the zombie PCs they hijack to send the crap in the first place. Probably far easier to just fire and forget. -Mike Marc Perkel wrote: I've been blocking a lot of spam at connect time that I am 100% sure is spam. However I'm wondering if that is the best idea because it gives spammers feedback as to what works and what doesn't. If I silently absorb the spam and let the spammers think it's delivered then they have no way to know if the spam is getting through or not. Thoughts?
