Spam filtering bcps [was Re: Open Letter to D-Link about their NTP vandalism]

Thu Apr 13 01:56:44 UTC 2006

> How does one properly report delivery failure to a guerrilla spammer?

If you accept the message, you can presumably deliver it. In this day and
age, anyone accepting mail for a domain without first checking the RCPT TO
- even (especially?) on a backup MX - should have their head examined. In
the event that the RCPT TO is valid but the message truly can't be
delivered for some other reason, you should bounce the message and fix the
problem.

My point was that when it comes to spam, it should either be rejected
inline or delivered. Unless your spam scanner has 100% accuracy, 100% of
the time, there is no justification for sending anything not addressed to
you to /dev/null.

> "Please automatically delete anything that might be spam.  They'll call
> me if it's important.  I know I'll lose some mail, but that's okay."

If you have an agreement with a customer that specifically allows for such
behaviour, great. We can get into individual cases for any concievable
scenario, but that would be silly. It was pretty clear, to me at least,
that we were discussing this as it would pertain to a system-wide
configuration.

> As for MUST bounce using return-path... perhaps you've never experienced
> blowback from a joe job.  It can be unpleasant.

Yes, I have. And yes, it is. However, I never suggested bouncing spam, as
my last message clearly stated. My position is that if you accept the
message (250 OK), you have an obligation to deliver it. If you can't scan
it during the SMTP transaction, do it after and mark up the headers, drop
it in a junk folder - whatever - but don't delete it.

St-