Subject: [ASRG] 0 - General, Reliability of Transport

From: "Chris" <[email-masked]>
Date: Sun, 23 May 2004 11:03:12 +0930

Is there a mention in our Charter about the *reliability of transport*?

From what I have seen over the months there is two camps within this group

1/ Those that believe Spam should be stopped at any cost
2/ Those that believe Spam should be countered but not at the expense of
losing possibly important messages

I am quite solidly in the second group (am I alone).

It seems to me that this is a paramount consideration. and this group should
support one or the other to the exclusion of the other. As I see it as a
major sticking point amongst proponents.

As a mail user I want to see a message that I send reach its destination
without wondering if it ever made it because I somehow triggered a spam
filter.

This should include that any system must have a suitable reporting system
(bounce) so that I am made aware of any errors in transit. This reporting
system must of course not be useable by spammers to probe the filter to
break it. Which I understand is a major risk.

Regards
Chris

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Sat, 22 May 2004 22:47:24 -0400 (EDT)

> I am quite solidly in the second group (am I alone).

There are a few others with you.

There are a few in group 1.

Most of us are somewhere around 1.5.  The simple reasoning: anything
that blocks no real email isn't going to block most spam.  Therefore,
the user's mailbox will be full of spam.  The user, paging through a
mailbox containing mostly spam, will accidentally delete some fraction
of real messages because they look too spammy.  Therefore, it's better
for the filter to block a (smaller) percentage of real email and a lot
more spam, so that more real email actually ends up in the user's
brain (the true destination).

Given the choice between a message of mine being accidentally deleted
because the Subject header wasn't instantly screaming "I'm not spam"
and a message being rejected by an overly zealous filter, I'd
instantly choose the second because that way I _know_ there was a
problem.

Seth

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 23 May 2004 07:57:56 -0400 (EDT)

> I am quite solidly in the second group (am I alone).

A third group includes:

3/ Those who believe that mail should be delivered or rejected at the SMTP
stage, but not discarded or returned to the envelope from.

A demand that spam detection never make a type II error is hardly
different from a demand that spam be tolerated. The 3rd group ensures that
mail will not be lost, even if some is not delivered. It does rule out (1)
spam detection at the MUA level, (2) spam detection as a low priority
background process on the MTA and (3) the sending of discard notices to
forged envelope from addresses.

---

From: der Mouse <[email-masked]>
Date: Sun, 23 May 2004 12:37:08 -0400 (EDT)

> 2/ Those that believe Spam should be countered but not at the expense
> of losing possibly important messages

> I am quite solidly in the second group (am I alone).

I doubt there is anyone here in camp 1; they can just turn off their
SMTP servers and go home, their goal achieved.  (There may be some who
_say_ they're in camp 1, but if they haven't just shut off their
mailers, they apparently don't actually mean it.)

As Daniel pointed out, there's a third group, those who believe that
spam should be SMTP-level rejected, never silently dropped, thereby
avoiding losing ham.  I hold myself to belong to this group.

There's a fourth group, too, those who believe spam should be countered
to the point at which the chance of the defenses mistaking a ham for a
spam is less than the chance of a human, deleting spam, making the same
mistake.  I hold myself to belong to this group as well.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Chris" <[email-masked]>
Date: Mon, 24 May 2004 11:25:43 +0930

> stage, but not discarded or returned to the envelope from.

Initial filtering CAN and should be done at the SMTP level such as
DomainKeys SPF etc. the assumption is forged return addresses = spam. thats
an acceptable assumption (domain validation must also account for
forwarding).

I also believe that virus filtering be added at the SMTP stage. I received
over 200 viruses today alone.
Other filtering can be at the SMTP stage to keep blatant spam off the
network.

> but not discarded or
So who holds the mail if its not discarded and for what purpose?

>  or returned to the envelope from.
Failing to return the mail helps stop spammers from probing the system, it
also prevents legitimate senders from knowing their mail failed to go
through. Spammers will always be able to probe the system by simply setting
up some test accounts so nothing is gained at all.

> forged envelope from addresses.

What you are describing is group 1.
(1) To rule out spam detection at the MUA is to say "we know better than
you" to the recipient. so is firmly group 1.

(2) Spam detection has to become priority at all steps MUA and MTA,
currently its mostly at the MUA level some of that burden should be lifted.

(3) With Domain Keys or SPF (etc.) forged return addresses are not an issue.
If my machine has been zombified and is sending out spam I would WANT TO
KNOW so I can fix it. Even if domain validation is only good to the ISP
level if I start receiving spam alerts I can ask my ISP whats going on and
they can use their logs to trace the real culprit. either way the source is
quickly identified.

Both the group 1 and group 2 camps are broad in their implementation. its
the overriding emphasis that concerns me.

I personally see group 1 as a holier than thou approach. (no offense
intended) but it assumes that the filter writer knows better than the end
user as to whats good for them.

Chris

---

From: "Chris" <[email-masked]>
Date: Mon, 24 May 2004 11:25:44 +0930

> mailers, they apparently don't actually mean it.)

I disagree some seem to agree with RTBL's and that is a camp 1 initiative

> avoiding losing ham.  I hold myself to belong to this group.

See my response to Daniel

> mistake.  I hold myself to belong to this group as well.

Well lets call this 1a, You are saying drop all spam that reasonably *looks*
like spam because the user may confuse it as spam as well and drop it
anyway.

Shouldn't that grey area spam be passed on to the user for final
determination (i.e. camp 2). how do you know whether or not an end user
reads all his spam to make sure he doesnt miss anything important. I do.

For me all obvious spam gets dropped. but I cannot afford to drop an email
from a customer just because that customer says "hi there" in the subject.
With source validation (DK,SPF etc) I would not need to worry about scanning
as many spams as I currently have to, as this would be done at the SMTP
level.

Chris

---

From: der Mouse <[email-masked]>
Date: Mon, 24 May 2004 01:30:17 -0400 (EDT)

[Replying to two different messages here, but both from "Chris"
<[email-masked]> and in the same thread.]

[Chris (replying to me)]

>> SMTP servers and go home, their goal achieved.  (There may be some
>> who _say_ they're in camp 1, but if they haven't just shut off their

Let's go back and check out just what camp 1 is.

>>> 1/ Those that believe Spam should be stopped at any cost

You appear to be confusing "at any cost" with something more like "at a
cost I think is unreasonable".

[six lines quoted from Chris replying to "Daniel Feenberg"
<[email-masked]>]

> (1) To rule out spam detection at the MUA is to say "we know better
> than you" to the recipient. so is firmly group 1.

> I personally see group 1 as a holier than thou approach.  [...] it
> assumes that the filter writer knows better than the end user as to
> whats good for them.

This is not an issue of which camp someone falls into, but rather an
issue of whether the mail admin chooses to give users control.  _Every_
spam filtering technique has false positives - yes, even DK, SPF, etc;
people make configuration mistakes and software has bugs, even if the
procedures are theoretically perfect (and while I don't believe they
are, I can't cite examples off the top of my head).  Strictly, thus,
camp 2 ("Those that believe Spam should be countered but not at the
expense of losing possibly important messages") must do no filtering at
all, including human JHD filtering, because any such filtering will
eventually lose a "possibly important message".  (Such people will
presumably be taking non-filtering tacks on spam, such as legal
approaches; while such things have value, I'm not sure this is the
place for discussing them.)

"At any cost" means "at any cost", and the simplest, easiest, and most
effective way to stop spam is to stop all email.  There, problem solved
- for people who really do mean "at any cost".

RTBLs are not camp 1.  They are for people who think some costs, like
dropping all email, are too high, but who also finds find the costs of
not risking any ham stoppage to be too high as well, and are trying to
find a point that stops enough spam to keep them happy at a low enough
cost to keep them happy.  That they find that balance point on the side
of rejecting or dropping more mail than you do does not mean that they
want to stop spam "at any cost".  Just at a cost you find unacceptable.

>> avoiding losing ham.  I hold myself to belong to this group.
[see below for why I quoted these three lines in full]

>> There's a fourth group, too, those who believe spam should be
>> countered to the point at which the chance of the defenses mistaking
>> a ham for a spam is less than the chance of a human, deleting spam,
>> making the same mistake.  I hold myself to belong to this group as
>> well.

> Well lets call this 1a, You are saying drop all spam that ...

No.  Go back and reread my "third group" (this is why I quoted it in
full above).  I am arguing for dropping _nothing_.  Reject, or accept
and deliver; do not drop.  (And I believe that's what my filters do.)

In view of my "fourth group"'s description, I can see how you made this
mistake, because I was comparing the chance of ham being _lost_ due to
human error to the chance of ham being misidentified as spam, and thus
dropped, bounced, or whatever, due to software tripping on ham.  Unless
all identified-as-spam is silently dropped, contrary to my position
(per my self-identification with my "third group"), these are not
really as comparable as I made them sound; my apologies for the
confusion.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign