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

["Chris" <asrg at rebel.com.au>]

> [Chris (replying to me)]
>
> >> 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.)
> > I disagree some seem to agree with RTBL's and that is a camp 1
> > initiative
>
> 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".

The camp I speak of does not mind collateral damage and includes rtbl's
to them "any cost" is acceptable even if it means blocking swathes of the
internet.

This can only be described as a "stop spam at any cost" attitude.

If an rtbl blocks an entire IP range, then no mail gets thru no matter who
sends it or what it is.
(for those subscribed to the rtbl)


>
> [six lines quoted from Chris replying to "Daniel Feenberg"
> <feenberg at nber.org>]
>
> > 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.
>
> > 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.)

You are taking the camp 2 statement to an unreasonable extreme

Mail will be lost for all sorts of reasons but that is well and truly out of
the scope of the discussion.
To include mail lost due to configuration errors as a way to legitimise
overzealous software and/or admin is not correct.

Camp 2 is simply block and drop all obvious spam. pass on any dubious spam
so the recipient gets a final say.
if they make a mistake so be it.

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

(see above for rtbl's)

A cost "who" finds acceptable. my argument is the end user is the one who is
in final control. and that apart from blatant spam and viruses broadcast
indescriminantly we should not be trying to wrest that control away from the
individual user.

To do so opens the way for "censorship" of mail, which is a far cry from the
mandate of reducing spam.

It of course is possible now at various levels, but how would you like a
system that allows an individual or government block all emails that mention
"Nelson Mandela" or "Martin Luther King" or "Human Rights"

>
> >> 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.
> [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.)

>From Daniels original post which is what I responded to...

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

!!Firstly let me state I am all for MTA LEVEL (smtp) rejection of blatant
spam!!

The third group appears to hold on to the mail. what happpens to it after
that is not specified.

Daniel specifically states it is not returned to the "envelope from", its
not discarded NOR is it sent on to the final recipient.

So what happens to it?

if it doesnt get delivered thats the same as dropping it, is it not?

Also it SPECIFICALLY STATES "It does rule out (1) spam detection at the MUA
level"

I am assuming that the MUA he speaks of is the recipients. in other words
there is no allowance for a user to tailor his spam preferences.

Now if the user is allowed to have personal configuration files at the MTA
so that he can tailor the MTA's response I would go along with *that part*.
but Daniel did not appear to mean that. For a large ISP it is probably
impractical and too expensive. Why not let the user use his own cycles to do
the final clearing out.


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

Does this mean you are recinding the fourth group?

>
> /~\ The ASCII				der Mouse
> \ / Ribbon Campaign
>  X  Against HTML	       mouse at rodents.montreal.qc.ca
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>
> _______________________________________________
> Asrg mailing list
> Asrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg