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.
