Mailing List Archive: NANOG: users

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

Index | Next | Previous | View Threaded

ops.lists at gmail

Apr 11, 2006, 7:50 PM

Post #1 of 20 (2730 views)
Permalink

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

On 4/11/06, Matthew Black <black [at] csulb> wrote:
>
> Are you suggesting that we configure our e-mail servers to notify
> people upon automatic deletion of spam? Frequently, spam cannot be
> properly identified until closure of the SMTP conversation and that
> final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection
> should be held open until the message can be scanned for spam and
> viruses just so we can give a 550 MESSAGE REJECTED error instead of
> silently dropping it?
>

You can reject right after DATA, at the <CR><LF>.<CR><LF> stage, before QUIT

That's still an in line smtp reject rather than an accept + bounce DSN.

Exim with the spamassassin patches (sa-exim) does this, for example.

-srs

dot at dotat

Apr 12, 2006, 2:40 AM

Post #2 of 20 (2655 views)
Permalink

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

On Wed, 12 Apr 2006, Suresh Ramasubramanian wrote:
>
> Exim with the spamassassin patches (sa-exim) does this, for example.

SpamAssassin support is built in to Exim since version 4.50.

Tony.
--
f.a.n.finch <dot [at] dotat> http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7
LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.

matthew at sorbs

Apr 12, 2006, 5:11 AM

Post #3 of 20 (2649 views)
Permalink

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

Suresh Ramasubramanian wrote:

>On 4/11/06, Matthew Black <black [at] csulb> wrote:
>
>
>>Are you suggesting that we configure our e-mail servers to notify
>>people upon automatic deletion of spam? Frequently, spam cannot be
>>properly identified until closure of the SMTP conversation and that
>>final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection
>>should be held open until the message can be scanned for spam and
>>viruses just so we can give a 550 MESSAGE REJECTED error instead of
>>silently dropping it?
>>
>>
>>
>
>You can reject right after DATA, at the <CR><LF>.<CR><LF> stage, before QUIT
>
>That's still an in line smtp reject rather than an accept + bounce DSN.
>
>Exim with the spamassassin patches (sa-exim) does this, for example.
>
>-srs
>
>
Of course Postfix can be setup (using spampd) with spamassassin to do
exactly the same.

I believe Sendmail+MimeDefang+Spamassassin will also reject inline if
set to do so.

Regards,

Mat

jmaimon at ttec

Apr 12, 2006, 6:11 AM

Post #4 of 20 (2660 views)
Permalink

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

Matthew Sullivan wrote:

>
> Suresh Ramasubramanian wrote:
>
>> On 4/11/06, Matthew Black <black [at] csulb> wrote:
>>
>>
>>> Are you suggesting that we configure our e-mail servers to notify
>>> people upon automatic deletion of spam? Frequently, spam cannot be
>>> properly identified until closure of the SMTP conversation and that
>>> final 200 mMESSAGE ACCEPTED...or do you think that TCP/IP connection
>>> should be held open until the message can be scanned for spam and
>>> viruses just so we can give a 550 MESSAGE REJECTED error instead of
>>> silently dropping it?
>>>
>>>
>>
>>
>> You can reject right after DATA, at the <CR><LF>.<CR><LF> stage,
>> before QUIT
>>
>> That's still an in line smtp reject rather than an accept + bounce DSN.
>>
>> Exim with the spamassassin patches (sa-exim) does this, for example.
>>
>> -srs
>>
>>
> Of course Postfix can be setup (using spampd) with spamassassin to do
> exactly the same.
>
> I believe Sendmail+MimeDefang+Spamassassin will also reject inline if
> set to do so.
>
> Regards,
>
> Mat
>
>

As will sendmail+spamass-milter+spamassassin

In fact there are quite a few milters that can be used in between
sendmail and spamassassin

Joe

black at csulb

Apr 12, 2006, 7:45 AM

Post #5 of 20 (2653 views)
Permalink

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

Several people kindly contacted me off list with laborious
explanations of how to implement delayed 550 rejections using
sedmail, et al. We gave up sendmail years ago in favor of a
competing solution.

I haven't seen any succinct justification for providing a
550 message rejection for positively-identified spam versus
silently dropping the message. Lots of how-to instructions
but no whys.

matthew black
california state university, long beach

ops.lists at gmail

Apr 12, 2006, 8:00 AM

Post #6 of 20 (2674 views)
Permalink

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

On 4/12/06, Matthew Black <black [at] csulb> wrote:
>
> I haven't seen any succinct justification for providing a
> 550 message rejection for positively-identified spam versus
> silently dropping the message. Lots of how-to instructions
> but no whys.
>

For viruses - fine. But you are not going to find any spam filter in
the world that doesnt have false positives. And in such cases its
always a good idea to let the sender know his email didnt get through.

Like for example - you see a large webmail provider whose hosts and
domains keep getting forged into spam, misread the headers and block
that provider. In such cases, its your users who arent getting a lot
of valid email from their friends and relatives who are using that
provider, and 550'ing instead of trashing email saves the senders, and
their provider, quite lot of time that'd otherwise be spent
troubleshooting the issue.

Plus, 5xx smtp rejects tend to save your bandwidth a bit compared to
accepting the entire email (not that it matters on a small university
domain where your userbase is going to be fairly small, and bandwidth
available quite generous .. but for larger sites, or sites with
bandwidth issues, that's definitely a concern)

--srs

--
Suresh Ramasubramanian (ops.lists [at] gmail)

dot at dotat

Apr 12, 2006, 8:03 AM

Post #7 of 20 (2643 views)
Permalink

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

On Wed, 12 Apr 2006, Matthew Black wrote:
>
> I haven't seen any succinct justification for providing a
> 550 message rejection for positively-identified spam versus
> silently dropping the message.

If you are wrong about the message being spam, then the sender gets a
bounce.

Tony.
--
f.a.n.finch <dot [at] dotat> http://dotat.at/
BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7
LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE.

black at csulb

Apr 12, 2006, 8:30 AM

Post #8 of 20 (2656 views)
Permalink

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

On Wed, 12 Apr 2006 20:30:16 +0530
"Suresh Ramasubramanian" <ops.lists [at] gmail> wrote:
>
> On 4/12/06, Matthew Black <black [at] csulb> wrote:
>>
>> I haven't seen any succinct justification for providing a
>> 550 message rejection for positively-identified spam versus
>> silently dropping the message. Lots of how-to instructions
>> but no whys.
>>
>
>For viruses - fine. But you are not going to find any spam filter in
> the world that doesnt have false positives. And in such cases its
> always a good idea to let the sender know his email didnt get through.

Agreed, but we're willing to live with an error rate of less
than one in a million. This isn't a space shuttle. I don't think
the USPS can claim 99.9999% delivery accuracy. Nonetheless, to
allay worries, we are considering spam quarantines to allow
recipients an opportunity to review spam messages themselves, much
like Yahoo! Mail.

Complaints about e-mail not getting through won't be solved
with a 550 versus silently dropping spam because most users aren't
willing to sift through e-mail errors to find the specific cause
for delivery failure. Members of this list are a rare exception.

> Like for example - you see a large webmail provider whose hosts and
> domains keep getting forged into spam, misread the headers and block
> that provider. In such cases, its your users who arent getting a lot
> of valid email from their friends and relatives who are using that
> provider, and 550'ing instead of trashing email saves the senders, and
> their provider, quite lot of time that'd otherwise be spent
> troubleshooting the issue.
>
> Plus, 5xx smtp rejects tend to save your bandwidth a bit compared to
> accepting the entire email (not that it matters on a small university
> domain where your userbase is going to be fairly small, and bandwidth
> available quite generous .. but for larger sites, or sites with
> bandwidth issues, that's definitely a concern)

We already reject most connections with a 550 or TCP REFUSE
based on reputation filtering and blacklists, et al.

Where is the bandwidth savings once we've accepted an entire message,
scanned it, determined it was spam, then provided a 550 rejection
versus silently droping?

matthew black
california state university, long beach

ops.lists at gmail

Apr 12, 2006, 8:42 AM

Post #9 of 20 (2644 views)
Permalink

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

On 4/12/06, Matthew Black <black [at] csulb> wrote:

> Agreed, but we're willing to live with an error rate of less
> than one in a million. This isn't a space shuttle. I don't think
> the USPS can claim 99.9999% delivery accuracy. Nonetheless, to

I'm not even saying five nines. Spam filtering - even with heuristics
etc - is less than perfect, and per user spam filtering, however idiot
proof, sometimes turns out to be like giving Acme Inc gadgets to Wile
E Coyote. [.users having fun with procmail and .forwards should
already be a familiar story I guess?]

> We already reject most connections with a 550 or TCP REFUSE
> based on reputation filtering and blacklists, et al.

That works just fine. I dont have any argument with it

> Where is the bandwidth savings once we've accepted an entire message,
> scanned it, determined it was spam, then provided a 550 rejection
> versus silently droping?

If you can scan it inline, you can stop, issue a 550 and drop the SMTP
connection any time you want. Like for example, midstream when you
discover a fake header pattern.

You'd start with whatever can be rejected in session - fake HELOs,
blocklist listed IPs, random faked headers, dodgy attachment types
that are more likely to be viruses than not

Then apply the heavier and more cpu intensive filters later, on a much
smaller volume of spam

Maybe not all that much of a bandwidth / cpu saving, but saving remote
postmasters the hassle of troubleshooting lost email is always a good
idea.

--
Suresh Ramasubramanian (ops.lists [at] gmail)

black at csulb

Apr 12, 2006, 8:53 AM

Post #10 of 20 (2654 views)
Permalink

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

On Wed, 12 Apr 2006 21:12:44 +0530
"Suresh Ramasubramanian" <ops.lists [at] gmail> wrote:
> On 4/12/06, Matthew Black <black [at] csulb> wrote:
>
>> Where is the bandwidth savings once we've accepted an entire message,
>> scanned it, determined it was spam, then provided a 550 rejection
>> versus silently droping?
>
> If you can scan it inline, you can stop, issue a 550 and drop the SMTP
> connection any time you want. Like for example, midstream when you
> discover a fake header pattern.
>
> You'd start with whatever can be rejected in session - fake HELOs,
> blocklist listed IPs, random faked headers, dodgy attachment types
> that are more likely to be viruses than not
>
> Then apply the heavier and more cpu intensive filters later, on a much
> smaller volume of spam

We already do this.

> Maybe not all that much of a bandwidth / cpu saving, but saving remote
> postmasters the hassle of troubleshooting lost email is always a good
> idea.

After all said methods have been performed and the message gets
through reputation filtering; blacklists; forged/munged headers,
e-mail addresses, domain names the message comes in and then
there's that final dot. Up to this point, the message hasn't
proven to be spam until it can be scanned using BrightMail,
SpamAssassin, Baysian filters, DCC lists, or other methods.
All I'm saying is that once the full DATA submission has completed,
there's no bandwidth savings from silently dropping the message
versus providing a 550 rejection. In the best of all worlds,
it would be nice to give feedback. No system is perfect and a
false-positive rate of less than one in a million "220" accepted
messages seems pretty small.

matthew black
california state university, long beach

jmaimon at ttec

Apr 12, 2006, 9:03 AM

Post #11 of 20 (2664 views)
Permalink

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

Matthew Black wrote:
>

> there's no bandwidth savings from silently dropping the message
> versus providing a 550 rejection. In the best of all worlds,
> it would be nice to give feedback. No system is perfect and a
> false-positive rate of less than one in a million "220" accepted
> messages seems pretty small.

I thought I had already participated in beating this dead horse
sufficiently in multiple threads in multiple forums on multiple
occasions. Maybe I am in your killfile or something. If I post again on
this topic, I certainly will deserve to be.

Let me ask you this simple question:

If you know at close of DATA whether you are going to actually perform
final delivery, what does it cost you to follow standards and issue a
550 instead of a 220 and discard it?

If you use a 550, a real live person sending an email that somehow gets
FP will actually benefit.

I am with Suresh on this, just like in the past threads. Search the archive.

nanog2 at sthomas

Apr 12, 2006, 10:16 AM

Post #12 of 20 (2645 views)
Permalink

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

> I haven't seen any succinct justification for providing a
> 550 message rejection for positively-identified spam versus
> silently dropping the message. Lots of how-to instructions
> but no whys.

RFC 2821?

...the protocol requires that a server accept responsibility
for either delivering a message or properly reporting the
failure to do so.

...

If an SMTP server has accepted the task of relaying the mail
and later finds that the destination is incorrect or that
the mail cannot be delivered for some other reason, then
it MUST construct an "undeliverable mail" notification message
and send it to the originator of the undeliverable mail (as
indicated by the reverse-path).

Unless you're the final recipient of the message, you have no business
deleting it. If you've accept a message, you should either deliver or
bounce it, per RFC requirements.

Valdis.Kletnieks at vt

Apr 12, 2006, 11:18 AM

Post #13 of 20 (2660 views)
Permalink

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

On Wed, 12 Apr 2006 10:16:53 PDT, Steve Thomas said:
>
> > I haven't seen any succinct justification for providing a
> > 550 message rejection for positively-identified spam versus
> > silently dropping the message. Lots of how-to instructions
> > but no whys.
>
> RFC 2821?
>
> ...the protocol requires that a server accept responsibility
> for either delivering a message or properly reporting the
> failure to do so.

Elsewhere in 2821 (6.1, to be specific):

When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage.

OK? Got that? You '250 OK' it, you got a *serious* responsibility. Losing the
message because the whole damned machine crashes is considered a frivolous reason.

And throwing it away because you don't like the way it looks is OK? Man,
you're in for some severe karmic protocol payback down the road... ;)

nanog2 at sthomas

Apr 12, 2006, 11:40 AM

Post #14 of 20 (2665 views)
Permalink

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

Earlier today, I said:
> Unless you're the final recipient of the message, you have no business
> deleting it. If you've accept a message, you should either deliver or
> bounce it, per RFC requirements.

I just want to clarify that I was in no way suggesting that anyone bounce
spam - I was merely pointing out that if you choose to 250 a message, you
have to deliver it. The much better option is to 550 it after DATA if you
don't like what you see. Silently deleting other people's e-mail should
never even be considered.

Returning to lurk status...

St-

henry at AegisInfoSys

Apr 12, 2006, 12:38 PM

Post #15 of 20 (2664 views)
Permalink

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

On Wed, Apr 12, 2006 at 12:03:51PM -0400, Joe Maimon wrote:
> Matthew Black wrote:
>
> > there's no bandwidth savings from silently dropping the message
> > versus providing a 550 rejection. In the best of all worlds,
> > it would be nice to give feedback. No system is perfect and a
> > false-positive rate of less than one in a million "220" accepted
> > messages seems pretty small.
>
> Let me ask you this simple question:
>
> If you know at close of DATA whether you are going to actually perform
> final delivery, what does it cost you to follow standards and issue a
> 550 instead of a 220 and discard it?
>
> If you use a 550, a real live person sending an email that somehow gets
> FP will actually benefit.

In today's world, at least with the spamtorrent I see at my clients,
that's just untrue. If your filtering is set up well, and you mark
an e-mail as SPAM, it almost certainly is (yes, I'll certainly concede
FP's exist, but again, it almost certainly doesn't matter that much in
that teensy number of occurrences); and 99-plus-percent of spam
is emitted from spambots who don't give a $expletive about return
status one way or another. If you're worrying about "no-status" in
the context of FP's, then your filtering isn't set up well, which really
means you've got larger problems.

> I am with Suresh on this, just like in the past threads. Search the archive.

Though not contradicting what I just wrote, so am I. However, header-forged
and multi-chained spam from firehose-like spambots don't play by any of our
rules; all they do is blast away in a largely one-way transaction (guess
which direction!). A 550 now-a-days has nowhere to "go" (and those
"commercial" akak "legit") spamhouses don't wash their lists even on 550's.

--
Henry Yen Aegis Information Systems, Inc.
Senior Systems Programmer Hicksville, New York

black at csulb

Apr 12, 2006, 1:35 PM

Post #16 of 20 (2666 views)
Permalink

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

On Wed, 12 Apr 2006 14:18:24 -0400
Valdis.Kletnieks [at] vt wrote:
> On Wed, 12 Apr 2006 10:16:53 PDT, Steve Thomas said:
>>
>> > I haven't seen any succinct justification for providing a
>> > 550 message rejection for positively-identified spam versus
>> > silently dropping the message. Lots of how-to instructions
>> > but no whys.
>>
>> RFC 2821?
>>
>> ...the protocol requires that a server accept responsibility
>> for either delivering a message or properly reporting the
>> failure to do so.

Your statement is open to multiple interpretations. I argue that
anytime our system identifies a message as spam that it gets
delivered to the system bit bucket.

RFC-821 and netiquette also "mandate" e-mail be properly addressed.
System manufacturers and administrators make compromises because
strict adherence to the rules is not always possible from an
operational perspective.

> Elsewhere in 2821 (6.1, to be specific):
>
> When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
> message in response to DATA), it is accepting responsibility for
> delivering or relaying the message. It must take this responsibility
> seriously. It MUST NOT lose the message for frivolous reasons, such
> as because the host later crashes or because of a predictable
> resource shortage.

Lost me on that part about crashes being frivolous reasons.
This is a political statement not an indisputable matter of fact.

> OK? Got that? You '250 OK' it, you got a *serious* responsibility. Losing
>the
> message because the whole damned machine crashes is considered a frivolous
>reason.
>
> And throwing it away because you don't like the way it looks is OK? Man,
...............................***
> you're in for some severe karmic protocol payback down the road... ;)

I'm not the one throwing them away and never look at them; watch
the finger wagging. And thanks for the karma heads up, Bhudda.

matthew black
california state university, long beach

matthew at sorbs

Apr 12, 2006, 4:48 PM

Post #17 of 20 (2649 views)
Permalink

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

Steve Thomas wrote:

>Earlier today, I said:
>
>
>>Unless you're the final recipient of the message, you have no business
>>deleting it. If you've accept a message, you should either deliver or
>>bounce it, per RFC requirements.
>>
>>
>
>I just want to clarify that I was in no way suggesting that anyone bounce
>spam - I was merely pointing out that if you choose to 250 a message, you
>have to deliver it. The much better option is to 550 it after DATA if you
>don't like what you see. Silently deleting other people's e-mail should
>never even be considered.
>
>

This policy I whole heartedly agree with, and I strive where ever
possible to enforce this in every place I work, where ever people get
listed in SORBS for backscatter, I work with them telling them how they
can do this....

With the current technologies available there is no reason a
small-medium organisation cannot virus and spam scan mail inline at the
SMTP transaction stage. (Even the barracuda's can spamassassin scan at
around 8 messages per second - my previous employment were receiving
around 4 messages per second - which translated to 1-2 million emails
per day)

It is possible to do inline scanning in larger ISPs (I personally have
configured a 'system' to handle upto 90 message per second inline
scanning) - though it requires a lot more planning, thought, and careful
consideration.

Regards,

Mat

eddy+public+spam at noc

Apr 12, 2006, 6:27 PM

Post #18 of 20 (2646 views)
Permalink

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

ST> Date: Wed, 12 Apr 2006 10:16:53 -0700 (PDT)
ST> From: Steve Thomas

ST> RFC 2821?
ST>
ST> ...the protocol requires that a server accept responsibility
ST> for either delivering a message or properly reporting the
ST> failure to do so.

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

ST> Unless you're the final recipient of the message, you have no business
ST> deleting it. If you've accept a message, you should either deliver or
ST> bounce it, per RFC requirements.

"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."

Throwing RFC 2821 at that user probably would not have made them happy.

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

RFCs are for maintaining interoperability. They are not infallible.
When a system is clearly broken, it's time to examine alternatives --
not to say that the RFC was handed down from on high.

Proposal:

MXes can say "2xx message queued with ID blahblahblah". They also can
return 4xx "try back later codes". Yes?

How about some return code that says "poll by $deadline if you want to
know whether message ID blahblahblah was accepted or rejected"? No need
to retransmit the entire message, and the sender can learn whether the
message was actually accepted.

Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc [at] brics -*- jfconmaapaq [at] intc -*- sam [at] everquick
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

nanog2 at sthomas

Apr 12, 2006, 6:56 PM

Post #19 of 20 (2654 views)
Permalink

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

> 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-

davids at webmaster

Apr 13, 2006, 9:59 PM

Post #20 of 20 (2646 views)
Permalink

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

> I haven't seen any succinct justification for providing a
> 550 message rejection for positively-identified spam versus
> silently dropping the message. Lots of how-to instructions
> but no whys.
>
> matthew black
> california state university, long beach

Because your father may forward a copy of a Nigeria scam from a new email
address he just got with his new ISP and ask if you if he should send them
money.

Because a machine you own may be responsible for the spam, and someone may
be forwarding you a copy of it along with the tracking information to
demonstrate that you were responsible for it.

Because the spam may include a trademark you own and you may need to notify
your legal department about it. The spam may have been helpfully forwarded
to you by someone familiar with your trademarks.

Because if you say you are going to deliver a message, that's what you
should do.

Because being spam is not the same as being unimportant.

All of these things really do happen.

>Agreed, but we're willing to live with an error rate of less
>than one in a million. This isn't a space shuttle. I don't think
>the USPS can claim 99.9999% delivery accuracy. Nonetheless, to
>allay worries, we are considering spam quarantines to allow
>recipients an opportunity to review spam messages themselves, much
>like Yahoo! Mail.

It is one thing to have an error rate of one in a million, it is quite
another thing to choose to have an error rate of one in a million instead of
one in a billion for no rational reason at all. If the measure is what
fraction of positively-identified spam the recipient would probably rather
receive than not receive, it's probably more like one in 5,000. If the
measure is what fraction of positively-identified spam the recipient would
rather the sender get a reject than silently discard, it's probably more
like one on 20,000.

The argument on the other side is if the positively-identified spam comes
from a business-critical mailing list that unsubscribes people if they have
too many bounces. This probably isn't an issue for viruses and malware
because these rarely get past the filters these lists already have. It is a
big issue for spam and one of the few for which there is no good solution I
know of. (Other than having the recipient whitelist the list at the MTA,
which is hard to do.)

DS

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads