[9fans] spam rejection after reception does have limits

[9fans] spam rejection after reception does have limits

[ron minnich]

I just got this linuxbios list message rejected from some random host
somewhere due to the racy, dirty subject line:

Subject: New config tool

The naughty word, according the the system that rejected it, was 'tool'.

This situation is impossible. I'm getting truckloads of bounced mail for
no real reason. I think mail as we have known it for a quarter century is
going down, one way or another. (I'm remembering it was just 25 years ago
that Dave Crocker was down the hall from me at Udel working on RFC 822 and
the MMDF stuff -- seems like -- well, 25 years ago -- creak, creak). The
early ARPANET mail work was predicated on the fact the great unwashed
weren't allowed on the ARPANET unless you were vetted, or unless your
buddy gave you the TIP dial-in 800 #.

We have a half-working solution now on 9grid. I agree with everything
everyone has said about the limitations of import /mail/box but I don't
see the current SMTP-based systems lasting a whole lot longer if you can't
even say

Subject: Thank you

in a mail message.

ron

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> We have a half-working solution now on 9grid. I agree with everything
> everyone has said about the limitations of import /mail/box but I don't
> see the current SMTP-based systems lasting a whole lot longer ...

i'm with you captain ...

Re: [9fans] spam rejection after reception does have limits

[Charles Forsyth]

> everyone has said about the limitations of import /mail/box but I don't
> see the current SMTP-based systems lasting a whole lot longer ...

i used to think that about XML
then again, there aren't whole conferences about SMTP
so you might be lucky.  more seriously, what's more likely
is that Microsoft (say) will suddenly leap in to point out
that SMTP clearly doesn't work and therefore everyone ought
to use such-and-such a scheme that, curiously, works
best with their servers everywhere and where the protocol
is lightly documented and hard to match.

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

----- Original Message -----
From: "Charles Forsyth" <forsyth@caldo.demon.co.uk>
To: <9fans@cse.psu.edu>
Sent: Sunday, September 28, 2003 11:08 AM
Subject: Re: [9fans] spam rejection after reception does have limits


> > everyone has said about the limitations of import /mail/box but I don't
> > see the current SMTP-based systems lasting a whole lot longer ...
>
> i used to think that about XML
> then again, there aren't whole conferences about SMTP
> so you might be lucky.

XML what a mess [reaches ...]

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sat, Sep 27, 2003 at 04:46:50PM -0600, ron minnich wrote:
>
> We have a half-working solution now on 9grid. I agree with everything
> everyone has said about the limitations of import /mail/box but I don't
> see the current SMTP-based systems lasting a whole lot longer if you can't
> even say
>
> Subject: Thank you
>
> in a mail message.
>
Choate is quite correct <default disclaimer> that the solution is
not a technological one, but a social one.  It has always been: in
NetNews, the recommended response to unacceptable behaviour was to
ignore it, which still applies, in spades.

Not reject it, not get angry about it, simply ignore it, as early
as possible.

Choate suggests legal recourse, within the existing system.  Again,
harrassment could be used, I think it would work if one could target
the perpetrator rather than some innocent, unwitting victim.

Our job is to provide the tools that make prosecution possible,
together with the features that diminish unprosecuted/unprosecutable
harrassment to a level where communication is not worse than lack
of communication.  But the objective will be to get rid of SPAM
and e-mail viruses altogether, whether attainable or not.

9grid proposes a distributed mailbox.  We have that already, just
a different model, the difference is that the new model is still
under development and does not carry the legacy baggage of RFC821/2
with it.  I don't think it's such a big deal to admit that RFC821/2
are obsolete (I do mean RFC2822 and any other successor as well)
and that a new approach is required.  The difficulties can be
listed:

	- Legacy: can't be helped, that's where the problem lies
	in the first place.

	- Acceptance: critical mass problem, will probably sort
	itself out, possibly making somebody very, very rich.

	- Design: Once the actual issues are properly identified,
	there is really very little left other than redefine the
	concepts of RFC821/2 for a new world order.  One can even
	safely discard all the legacy stuff that RFC822 addressed
	as it no longer exists.  Of course, one can jump into the
	breach and provide a totally new solution (distributed
	fileservices for mailboxes), but that's a technicality.
	I'm sure even Collyer will agree.

So what are the issues?

	- Unsolicited mail: I want to be able to send some, receive
	some, but most of it is unwanted.  Maybe the "Don't speak
	to strangers" rule applies and one ought to get an
	introduction.  Historically, it seems to me this has happened
	before (the Renaissance?).  It puts certain introduction
	agents in an enviable position, but then they probably are
	there because they can be trusted (notaries, that type of
	thing, perhaps?).

	  I think it boils down to identity and I think the PEM
	people and the ITU-T tried to provide a mechanical solution
	to a political problem and we may have to undo this.  As
	long as a technical solution is sought or believed to be
	valid, there will be an option for social enginnering to
	subvert it.

	- Theft of Identity: somebody has hijacked a trusted
	identity.  We've lived with this for a long time, one makes
	it as difficult as possible for the identity to be stolen,
	then makes is as easy as possible to recover from the
	damage.  A Choate solution would report it to the "authorities",
	in my understanding of Choate's opinion more to deter future
	perpetrators than to punish the current one.  It's a
	judgement call, my opinion is more neutral, but doesn't
	conflict with Choate's and certainly requires an "authority"
	capable of prosecuting a perpetrator.

	  How one persuades a sensitive organisation to disclose
	such attacks when it may damage its reputation?  By
	threatening with much more damaging sanctions if it doesn't.
	Yet another social rather than technical solution.  But
	the tools are technological ones and need careful design
	not to become a form of oppression.

I'm sure I ought to list more issues and problems, but this is
boring enough, let someone else add to this list.  Keep in mind
that I believe Ron is right: we don't have a lot of time left.

++L

PS: I don't have a problem with each mail recipient acting as its
own CA and issuing certificates left, right and centre that can be
used to further certify agents on behalf of the sender.  X.509's
certification hierarchy allows for this and it may be best employed
as a certification audit trail.  I'm not (yet) competent enough to
code the tools to create and inspect such a certification audit
trail, but I believe there is ample competence on this list to do
it, and do it timeously.

PPS: Choate, I hope I haven't ruined your reputation irreparably
by agreeing with you.  I certainly could have miscronstrued your
opinions and I apologise in advance if I did.  Please do not hesitate
to correct me (in private would be preferable, I won't hesitate to
issue public corrections if required).

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> Choate is quite correct <default disclaimer> that the solution is
> not a technological one, but a social one.

nonsense, he thinks like an american; litigation being the 'solution'.

> ignore it, which still applies, in spades.

ignore it?  how do do you ignore it whenit is thrown in your mailbox
and some of it is just plain harrassment.

> Not reject it, not get angry about it, simply ignore it, as early
> as possible.

it's a 'no can do'.

> Choate suggests legal recourse, within the existing system.  Again,
> harrassment could be used, I think it would work if one could target
> the perpetrator rather than some innocent, unwitting victim.

you can't target the T -- that is the root of the problem.  the Received:
headers give you a clue, but they are by no means certain.

> Our job is to provide the tools that make prosecution possible,
> together with the features that diminish unprosecuted/unprosecutable
> harrassment to a level where communication is not worse than lack
> of communication.  But the objective will be to get rid of SPAM
> and e-mail viruses altogether, whether attainable or not.

no, i know when to use a technical solution and when to use a
legal/political one.  in this case a technical solution would work.

in any case the courts don't really recognise a stream of, completely
forgable, bits as any form of proof:  eg. al capone finally got done
for _tax evasion_, rather than hist other 'activities'.

litigation is a fools game.  read _the justice game_:

    http://www.portia.org/books/jgame.html

> PS: I don't have a problem with each mail recipient acting as its
> own CA and issuing certificates left, right and centre that can be
> used to further certify agents on behalf of the sender.  X.509's
> certification hierarchy allows for this and it may be best employed
> as a certification audit trail.

you don't understand the the faults of PKI.  issuing certs left right and
center breaks the 'trust'.  paying money to root CA's (which i don't trust)
is a waste of money and time.

look at the bastion of security Verisad (sic).  since the wildcard A records
where installed spam has skyrocketed and so has the discussion about
it on 9fans.

like my man dave [not presotto] told me that 'i' should 'cut that shit out'.

however, since i got spamoff to go [@sdgm.net], which included filling
up dan's proc table once, the thousands of spam just get flung back
at 'em and then they bounce and then they get trashed, rather than
filling up /mail/box/boyd/mbox, which keeps me (and i suppose dan)
happy.  it chews up resources, but it doesn't fill /n/dump.

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sun, Sep 28, 2003 at 10:59:25AM +0200, boyd, rounin wrote:
>
> > Choate is quite correct <default disclaimer> that the solution is
> > not a technological one, but a social one.
>
> nonsense, he thinks like an american; litigation being the 'solution'.
>
Ron agrees with him, too: in the good ole days we cut miscreants
out.  Not a _legal_ solution, a _social_ one.  The tool was
technology, but if no one else gave you a connection or account,
you were out for good.

> > ignore it, which still applies, in spades.
>
> ignore it?  how do do you ignore it whenit is thrown in your mailbox
> and some of it is just plain harrassment.
>
OK, then: receive it, resend it, get it delivered elsewhere and
rejected once again.  It's pity it can't start a loop, I suppose?

> > Not reject it, not get angry about it, simply ignore it, as early
> > as possible.
>
> it's a 'no can do'.
>
Objection, my Lord!  Ignoring it at the door knock level is as
early as one can wish for.  Now, how do we do it?

> > Choate suggests legal recourse, within the existing system.  Again,
> > harrassment could be used, I think it would work if one could target
> > the perpetrator rather than some innocent, unwitting victim.
>
> you can't target the T -- that is the root of the problem.  the Received:
> headers give you a clue, but they are by no means certain.
>
So what's the solution?  Generating traffic and punish everyone
else? Sounds like Pharaoh and the Plagues of Egypt.

> no, i know when to use a technical solution and when to use a
> legal/political one.  in this case a technical solution would work.
>
Both require _new_ tools.  As a technologist, it is easy to think
that politicians are fools.  Which is why no technologist has ever
run a country, into the ground or otherwise.

> you don't understand the the faults of PKI.  issuing certs left right and
> center breaks the 'trust'.  paying money to root CA's (which i don't trust)
> is a waste of money and time.
>
Between you and Choate, you're getting irritating: "You don't
understand..."  Maybe you can explain, if you're so fucking clever!

> look at the bastion of security Verisad (sic).  since the wildcard A records
> where installed spam has skyrocketed and so has the discussion about
> it on 9fans.
>
What's that got to do with X.509?  Mark Shuttleworth explained to
me that there were two official top-level CAs, a third one never
took itself seriously.  The key, apparently, was in the policy
document, which is of course what you now criticise.  It was worth
a whole lot of money, to Mark and associates.

Anyone can be a CA, it's just too late to ride the Netscape bandwagon.
But for private use, all that's needed is a set of easy to use
tools.  Not far from what MS released with Win2K.  I haven't looked
at Shuttleworth's (Thawte's) web of trust model, but it probably
undermines the CA monopoly pretty successfully.

> however, since i got spamoff to go [@sdgm.net], which included filling
> up dan's proc table once, the thousands of spam just get flung back
> at 'em and then they bounce and then they get trashed, rather than
> filling up /mail/box/boyd/mbox, which keeps me (and i suppose dan)
> happy.  it chews up resources, but it doesn't fill /n/dump.
>
Well, it's probably a good solution in the First and New Worlds.
But here in Africa bandwidth is more expensive than disk space or
instruction cycles (we pay for our mail to get to you _and_ your
mail to get to us).  Generating traffic is not appropriate.  It
really never was, and will never be as there will always be some
other use for the bandwidth that is more deserving.

++L

PS: Any bet how long it will take for spammers to figure a way around
Boyd's block?

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> PS: Any bet how long it will take for spammers to figure a way around
> Boyd's block?

i understand its failure modes, but it raises the bar and it's in
the public domain so it's open to scrutiny.

brahma% cd log/mail
brahma% ls -l
alrw--w--w- M 262286 boyd boyd  65712 Sep 28 05:57 audit
alrw--w--w- M 262286 boyd boyd 126632 Sep 28 05:57 errors
alrw--w--w- M 262286 boyd boyd  88174 Sep 28 05:57 rejects
brahma% wc -l errors
   1349 errors
brahma%

so when stuff starts winding up in my mbox, i'll just raise the bar.
that's how security works:

    what have you got to guard?  how much is it worth to guard it?

short of hacking an stmp server (which i'm loathed to do) i'd implement
a stat based black/white list.  you do not, in my beloved corps, screw
up with smtp.

btw:  whoever got snarf/copy/paste right on windows' drawterm did a great job.

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

now is all ISPs enforced the rule that the MGRS coords of the
ISP or the sender were added as the standard sig at least
you could call in a JDAM on them, but this is very open to
blue-on-blue man-in-the-middle attacks.
--
MGRS 31U DQ 52579 12613

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sun, Sep 28, 2003 at 12:50:09PM +0200, boyd, rounin wrote:
>
> now is all ISPs enforced the rule that the MGRS coords of the
> ISP or the sender were added as the standard sig at least
> you could call in a JDAM on them, but this is very open to
> blue-on-blue man-in-the-middle attacks.
> --
> MGRS 31U DQ 52579 12613

ICBMs? :-)  :-)

There's a definite need for delegation of authority with associated
acceptance of responsibility in the sender-exchanger relationship.

ISPs have rules about use, but enforcement by severance is inadequate.
I maintain that the solution has to involve punishment, probably
to the point where the few that are caught will have to pay on
behalf of those who get away.

Our recent legislation (in South Africa) attempted to address the
problem, but lacked the understanding (oops, I'm doing a Choate
here) to arrive at a sensible product (the ECT Act is online
somewhere, but it's frightfully irritating in its ability to get
close to bone without quite ever making it, mail me and I'll look
for it).

What I found immensely annoying is that no one was able to provide
sensible alternatives to even the most inappropriate sections of
the Act.  And it's not through lack of interest, it just seemed
impossible to formulate in legislative terms what was technologically
obvious.  And I don't exclude myself from the list of attempts.
There is a serious communication gap between technologists and
users and it looks insurmountable.  Let's not ignore that in our
quest.

++L

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

JDAM:

    http://www.fas.org/man/dod-101/sys/smart/ppcp97c1.htm

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> Between you and Choate, you're getting irritating: "You don't
> understand..."  Maybe you can explain, if you're so fucking clever!

you need a root CA or some other CA you trust.  this depends on
the DNS, which can be spoofed, hence possiblty giving you a false
public key.

key revocation never worked.

TLS/SSL is so complex that the bugs kept turning up.  someone at the
labs even had a theoretical [impractical, but possible] an attack on it.

that's why we don't use 2DES, 'cos there is theoretical attack where
you meet in the the middle.  sure, it's costly, but the solution is to go
to 3DES.  DES 'died' back in the early '90s (unless you were the NSA,
where it probably died well before that).

once you had encrypted the 'crack' dictionary [~50k 'words'] with all
the 4096 salts busting a password file with a shell script and took
seconds.  generating the dictionary back then took a month.

i did this once, as an experiment and to test internal security.

on that point i'm NDA'd on any further discussion.

# 248 622

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sun, Sep 28, 2003 at 01:05:19PM +0200, boyd, rounin wrote:
>
> > Between you and Choate, you're getting irritating: "You don't
> > understand..."  Maybe you can explain, if you're so fucking clever!
>
> you need a root CA or some other CA you trust.  this depends on
> the DNS, which can be spoofed, hence possiblty giving you a false
> public key.
>
That was the point I was trying to make.  I'll issue you a certificate
(a tiny one, without all the stupid frills).  Not only, I'll issue you
a CA certificate, so you can in turn certify your ISP or your pretty
cousin that acts as your SMTP gateway.  I'll accept their certificates
as being your agent.  I probably won't accept them as proof of their
identity, however.  That's an interesting aside not to be indulged
here.

> key revocation never worked.
>
I accept that.  It doesn't look like it could conceivably be taken
seriously by anyone.  We've had our banks (we have only a few here as
the entrance qualifications are absurdly steep) fall foul of expiry.
But why I should trust Veristupid (sic) in preference to a bank that's
more or less managed my overdraft for the past 25 years, I fail to
understand.  Yet everyone jumped in horror when MSIE raised the alarm.

More of that lack of communication between tech and non-tech.  Even
within one's brain, seemingly, as the only squawkers I heard were
techies.

But when I revoke the certificate I issued to you, I will (hopefully)
know about it.  That type of revocation had better work.

> TLS/SSL is so complex that the bugs kept turning up.  someone at the
> labs even had a theoretical [impractical, but possible] an attack on it.
>
That was addressed and fixed.  I assume that real cryptographers know
what they are doing, the maths is too convoluted (life is too short)
for me to do it myself.  But I'm prepared to respect the experts with
a reputation (Steve Bellovin come to mind, but there are plenty
others).

If there is a preferable approach, it hasn't made any dent in my
awareness.  And I accept I'm not on the coal face, nor does "good"
imply "successful", nor do all clever schemes get published for the
health of the Internet (think NSA), still, if SSL could migrate to
TLS against entropy, maybe further migration towards greater entropy
is possible.

> that's why we don't use 2DES, 'cos there is theoretical attack where
> you meet in the the middle.  sure, it's costly, but the solution is to go
> to 3DES.  DES 'died' back in the early '90s (unless you were the NSA,
> where it probably died well before that).
>
DES has yet to be shown not to be intentionally back-doored.  But
respected encryption algorithms are ten-a-penny, to the great
confusion of those who have to make decisions and cannot possibly be
expected to know everything cryptographic.

I thought TLS used blowfish and that rijndael had been picked as the
final word in international trusted encryption schemes?

> once you had encrypted the 'crack' dictionary [~50k 'words'] with all
> the 4096 salts busting a password file with a shell script and took
> seconds.  generating the dictionary back then took a month.
>
Cracking the Unix security to read /etc/shadow or /etc/master.passwd
takes a different approach.  As you suggest, the solution should
be less expensive than the problem.  You forget that the price you
pay has little in common with the gains of your enemy.  That is
also an important factor.  I'm upgrading a site of some two hundred
users right now, with the option to change from DES to RC5 for
login passwords.  The trauma involved in the migration is going to
offset any possible security gain by orders of magnitude, specially
as the sharing of passwords seems more the norm than the exception
around here.  Why bother?

++L

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> Why bother?

at the time i had a small concern about virii turning up in the dynamically
loadable microcode.

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sun, Sep 28, 2003 at 01:58:56PM +0200, boyd, rounin wrote:
>
> > Why bother?
>
> at the time i had a small concern about virii turning up in the dynamically
> loadable microcode.

Life was a lot easier for those of us who, like me, admired in
wonderment the behaviour of the ping-pong virus without giving it
much more of a thought because it had only so far affected the
computers of other, less sophisticated users.

I guess my security days started when my PC was eventually compromised
and I had to figure out what was going on.

++L

Re: [9fans] spam rejection after reception does have limits

[Douglas A. Gwyn]

boyd, rounin wrote:
> that's why we don't use 2DES, 'cos there is theoretical attack where
> you meet in the the middle.  sure, it's costly, but the solution is to go
> to 3DES.  DES 'died' back in the early '90s (unless you were the NSA,
> where it probably died well before that).

DES was never authorized for protecting classified information
(except in a true emergency).  AES, however, is authorized for
two levels of protection (e.g. SECRET in an unclassified
environment), and since AES is much faster than 3DES it seems
a much better choice.

Re: [9fans] spam rejection after reception does have limits

[boyd]

     DES was never authorized for protecting classified information
     (except in a true emergency).

yup.  but the point is that is that if mere mortal only has DES
then go for 3DES.

Re: [9fans] spam rejection after reception does have limits

[ron minnich]

On Sun, 28 Sep 2003, Lucio De Re wrote:

> Ron agrees with him, too: in the good ole days we cut miscreants
> out.

I wouldn't go that far. In the good 'ole days, DARPANET was an elitist
institution: nobody got in unless DARPA said ok. The boundaries were both
institutional and economic -- getting a DARPANET link at your site was
costly. We didn't cut them out; they never had a chance to get in.

ron

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> I wouldn't go that far. In the good 'ole days, DARPANET was an elitist
> institution: nobody got in unless DARPA said ok.

bingo.

it was designed to be a closed, fault tolerant, net for the military.

run by bob <guess>?

Re: [9fans] spam rejection after reception does have limits

[ron minnich]

On Sun, 28 Sep 2003, boyd, rounin wrote:

> Ron sez:
> > I wouldn't go that far. In the good 'ole days, DARPANET was an elitist
> > institution: nobody got in unless DARPA said ok.

> body sez:
> it was designed to be a closed, fault tolerant, net for the military.
>
> run by bob <guess>?

yeah. I saw Dave Crocker at SGI about ten years ago and we were talking
about the inappropriate uses that "the great unwashed" were putting the
internet to -- uses never envisioned when it was "elite net" and only
certain folks got to use email, much less hook up to it.

He had seen cases of people sending billing and payment notices for their
business, in the clear, over email, with sensitive bits in them. We were
both kind of amazed (appalled) at how things had worked out. But why not?
The protocols were all designed with one assumption: if you were on the
net at all, you had passed some sort of barriers already.

Now, of course, it is tending to collapse so this may be less of a problem
in a short while.

"Your message was rejected as Spam. The subject was: Your new tool has
arrived. The word which caused the rejection was: tool"

Second try: Subject: That you-know-what is here at the you-know-what

"Your message was rejected as ..."

Third try: Subject: U got thing here now cum get it

"You message ..."

[[ recipient of email goes out of business waiting for email about their
new tool ]]

ron

Re: [9fans] spam rejection after reception does have limits

[boyd]

funny old world.

Re: [9fans] spam rejection after reception does have limits

[Charles Forsyth]

>> PS: I don't have a problem with each mail recipient acting as its
>> own CA and issuing certificates left, right and centre that can be
>> used to further certify agents on behalf of the sender.  X.509's
>> certification hierarchy allows for this and it may be best employed
>> as a certification audit trail.

>you don't understand the the faults of PKI.  issuing certs left right and
>center breaks the 'trust'.  paying money to root CA's (which i don't trust)
>is a waste of money and time.

there has been quite a bit of work done and published before and after
x.509 (and PGP as well for that matter).

i recently discovered
http://www.anu.edu.au/people/Roger.Clarke/EC/Bled03.html, which
is quite a good brisk survey, with trenchant observations.

Carl Ellison has a good web site with lots of useful links:
to other good web sites:
http://world.std.com/~cme/html/spki.html.

aside: the parent site has a link that takes a good whack at ASN.1
``ASN.1 is viewed differently by writers of standards and implementers.
Neither group is unanimous in its evaluation, but it tends to be predominantly
favoured by the former and predominantly despised by the latter.''
http://world.std.com/~cme/P1363/asn1.html
``... for a total code size [for ASN.1] of 55085 characters, as compared
to the original 48 characters [for the obvious if less flexible C version] ... an expansion
in code by a factor of 1148''

Re: [9fans] spam rejection after reception does have limits

[boyd, rounin]

> is quite a good brisk survey, with trenchant observations.

'tranchant' [cutting] now that's a good present participle.

'double tranchant' == double edged sword

Re: [9fans] spam rejection after reception does have limits

[salomo3]

>> is quite a good brisk survey, with trenchant observations.
>
> 'tranchant' [cutting] now that's a good present participle.
>
> 'double tranchant' == double edged sword

Yup, Like the scottish claymore. None of your wimpy M60s or whatever you
carry. These are weapons for *real* men - the scourge of spammers, etc..
:-)

joel

Re: [9fans] spam rejection after reception does have limits

[boyd]

effective, but no 'stand off' range.

Re: [9fans] spam rejection after reception does have limits

[Lucio De Re]

On Sun, Sep 28, 2003 at 11:32:09PM -0400, boyd@sdgm.net wrote:
>
> effective, but no 'stand off' range.

Real fighters are not afraid to face their enemy.  Read "Dune" by
(need I say it) Frank Herbert (avoid the sequels).

++L

Re: [9fans] spam rejection after reception does have limits

[boyd]

real fighters [Sun Tsu] are smart enough to want to live to fight
another day, UNLESS they are placed in 'death ground'.  in that case
_all bets are off_.

what is the value of a dead warrior who could have tactically withdrawn
to grease more of them the next time?

look at the VC or the 'muj'.

Re: [9fans] spam rejection after reception does have limits

[Joel Salomon]

boyd@sdgm.net said:
> effective, but no 'stand off' range.
>
that's for the bagpipe to do.

--Joel

Re: [9fans] spam rejection after reception does have limits

[Douglas A. Gwyn]

boyd, rounin wrote:
> in any case the courts don't really recognise a stream of, completely
> forgable, bits as any form of proof:  eg. al capone finally got done
> for _tax evasion_, rather than hist other 'activities'.

Al Capone predated the digital age.  Tax evasion was within
Federal jurisdiction, whereas most of his crimes were not.
It is true that tax evasion was relatively easy to prove.

Re: [9fans] spam rejection after reception does have limits

[Douglas A. Gwyn]

Lucio De Re wrote:
> Choate suggests legal recourse, within the existing system.  Again,
> harrassment could be used, I think it would work if one could target
> the perpetrator rather than some innocent, unwitting victim.

Not really, since perpetrators can spring up so much more
quickly than the legal system can move to punish them.
If you think that "setting an example" would help much,
look at previous prosecution of hackers and see what a
deterrent it was.

> 	- Legacy: can't be helped, that's where the problem lies
> 	in the first place.

Indeed, if you want to leave your mailbox open to receive
mail from people using other systems, you're stuck,
because there is no reliable way to distinguish between
legitimate mail and proxy mail.  The only technical fix
for that would have to be at those systems, which need to
stop acting on directions received remotely.

Re: SPAM: Re: [9fans] spam rejection after reception does have limits

[Charles Forsyth]

>>If you think that "setting an example" would help much,
>>look at previous prosecution of hackers and see what a
>>deterrent it was.

clearly it didn't deter them all,
but how can we know that that
detection and prosecution didn't deter
some, perhaps even quite a few, from attempting it?

Re: SPAM: Re: [9fans] spam rejection after reception does have limits

[Douglas A. Gwyn]

Charles Forsyth wrote:
> but how can we know that that
> detection and prosecution didn't deter
> some, perhaps even quite a few, from attempting it?

The problem is, it just drives the worst offenders deeper into
the underground.  Drug trafficking and terrorism have been
targets of detection and prosecution, and overall this appears
to have made those problems worse, in some ways, than they might
otherwise have been.  Of course that's a judgment call, and there
is no way to perform the experiment to find out for sure.

I would prefer to see development of a social climate in which
it is so universally acknowledged that such attacks are not
acceptable that ordinary people take steps to stop it when they
detect it, instead of delegating the problem to government
agents.

Re: SPAM: Re: [9fans] spam rejection after reception does have limits

[Joel Salomon]

> I would prefer to see development of a social climate in which
> it is so universally acknowledged that such attacks are not
> acceptable that ordinary people take steps to stop it when they
> detect it, instead of delegating the problem to government
> agents.
>
Boyd, you may fire when ready.

--Joel

Re: SPAM: Re: [9fans] spam rejection after reception does have limits

[boyd]

    Boyd, you may fire when ready.

aquire, target, verify [with a 3rd party], shoot.

we'd prefer a lot of things, but it's not gonna happen.