Subject: Re: Fwd: Re: [Asrg] 6. Email Path Verification

From: "Eric S. Johansson" <[email-masked]>
Date: Sat, 13 Sep 2003 11:59:17 -0400

Fearghas McKay forwarded:

> --- begin forwarded text
> Subject: Re: [Asrg] 6. Email Path Verification 
> 
> 
>> You might want to check out the camram.org project.
>> 
>> http://camram.org/
> 
> 
> (Above URL is broken, use http://www.camram.org/ instead.)
> 
> I like the idea of hashcash as an increase-spammer-costs strategy, but 
> there's one big fly in the ointment.  The computational requirements 
> effectively make a hashcash-based system impractical for small, 
> ultra-portable or autonomous devices.

this problem has been fully acknowledged and dealt with.  Ultraportable or
autonomous devices are highly unlikely to be end SMTP nodes on the net
delivering e-mail to other end nodes.  This may change in the future but it's a
reality for the near term (i.e. next five years).  We're choosing to deal with
the problem by deferring the stamp generation phase to the actual MTA.  The load
shouldn't be too horrible because the white listing process will reduce the
number of stamps it will need to generate.  keep in mind that you only generate
stamps when you are talking to a stranger.  If it does become a problem, then
there should be enough money to pay for purchasing additional compute power.
After all, how many e-mails will people send using crippled keypad devices (AKA
telephones)  :-)

> A modern PC might only take a few seconds to generate a 20-bit hashcash, but
> an ARM-based PDA or mobile phone might take a lot longer (burning battery
> power all the while), and a toaster would take forever.  Not to forget the
> old Macs (usually 68030 based) that are commonly resurrected to help elderly,
> disadvantaged or disabled people establish lines of contact.  (Yes, I know
> someone who actually does this.  Old Macs are amazingly durable.)

there are two solutions.  first: defer processing to upstream machine (back of
the envelope numbers look plausible.  Need to do some empirical tests on real
mail servers).  The second solution is to look at a memory based POW which
exercises the memory bus instead of just the cache and CPU which reduces the
effect of Moore's Law inflation at a potential cost of stalling the entire
machine as you flush the cache hard.

> How long is it acceptable for a hashcash algorithm to take on such a low-end
> box?  That's the limiting factor when deciding how much each mail will
> "cost".

not surprisingly, I disagree.  The limiting factor is how long you are willing
to keep the machine on for.  Properly done stamp generation happens in
background away from user visibility.  If the system is interrupted by a
shutdown, then stamp generation restarts from its last checkpoint.  Think
reliable mail delivery.  also keep in mind that you only generate stamps when
talking to a stranger.  It's not a continual process.

> A 20-kilogate FPGA development kit costs $300, individual 20Kgate FPGAs cost
> in the $tens, and a set of custom PCBs can be had for $hundreds at worst.
> So, let's say the incremental cost is of the order of $25 per FPGA, giving
> perhaps 25 hashcash tokens per second on average (yes, I'm being faintly
> optimistic).  Even allowing for one-off development and equipment-manufacture
> costs, spam would appear to be worth enough to make such a system affordable.
> That puts Granny and her long-suffering Mac*[1] at even more of a
> disadvantage.

that's why we need to develop a repertoire of proof of work stamps, postage due
notices which handle rejection classes (insufficient postage, wrong postage,
etc.), and widespread availability of accelerators built actually into
motherboards and available at CompUSA on plug-in cards for $25.  You see, if a
spammer can develop such a device, Taiwan Inc. can develop a faster device that
cost less and get it distributed further which means postage costs takes a huge
jump upward (further encouraging sales of accelerator's) and the arms race needs
to go in a different direction.

seriously, I do believe that the additional stamp definitions and proper postage 
due notice system can handle most of the attacks caused by spammer specific 
hardware acceleration.

being a strong advocate of recycled machines for things like firewalls (IPCop,
another one of my crimes against humanity), I have learned that sometimes 
certain classes of old machines just aren't worth the effort anymore.  You need 
to learn when to go for higher quality junk instead of wasting your time 
swearing and bleeding over a cantankerous 486.

> However, a system that uses hashcash as a fallback for other authentication
> methods would be an interesting concept.  For example, use hashcash only to
> initiate "stranger" communications, and use a strongly-authenticated
> whitelist otherwise.  Reading the rest of that site, I see that's in fact
> what it suggests.

yes it does.  I haven't had the time to rewrite and clarify because I been
working on the prototype.  Apologies.  Remember, strangers cost, friends fly free.

> It still doesn't help Granny if it takes her (say) 4 hours to make hashcash,
> even if she only needs to do that once in a blue moon.

I think you exaggerate.  A four-hour stamp is around 31 bits on a Pentium II/333
MHz and I don't think we'll need stamps that big anytime soon.  when you put
stamp generation in background, you find yourself really not caring how long it 
takes to make a stamp.  It just gets done.  I will say however that that is 
spoken with the bias of someone who leaves machines on 24 by 7 by 365 modulo 
power failures.

> However, there's another problem with CAMRAM, though it's less obvious. Users
> will build up a list of public keys over time, presumably stored on their own
> machine.  Their private keys will also presumably be stored locally.  It's
> reasonably trivial for a worm to pick up a selection of these keys as it
> propagates, and deliver them to the black-hats by any of a variety of means.

problem understood and quite frankly, there is no camram specific solution to
this.  Any time someone can get their code to run on your machine outside of the
sandbox, you are well and truly fucked.  As we place more and more important
piece of data on known vulnerable machines, they become increasingly attractive
to attackers hoping to profit from this data or system resources.

One solution would be to use a stored value key (i.e. USB flash+) to hold
private keys and other kinds of important data.  Accessing the data requires
specific acknowledgment and you take the key with you when you leave the
machine.  Such a device could also hold accelerator for proof of work puzzles.
Two problem solved at once..maybe...

However, you cannot overcome laziness and any attempt to do so will be met with
resentment and firm resistance.  People will demand features that will enable 
them to get screwed because it is convenient to or increases the effectiveness 
of how they work.  Short of a major eugenics program, that part of human nature 
isn't going to change.

> Suddenly, they have the means to send spam to a lot of people - and even
> better (in the case of a mass-mailing attachment-based worm), these are
> mostly the clueless types who are most likely to respond positively to spam
> and scams.  Oh dear.

why work so hard to steal keys and generate correctly forged e-mail?  It's far
more convenient and less traceable to generate stamps and send spam directly
from the person's PC.  This is one of the failings of any distributed defense
against Spam especially with large numbers of easily compromised machines such
as the ones compromised over the past few weeks.  there are no ready solutions
for this problem.  In time, Linux or any other popularized OS will suffer from
similar compromises as a result of the trade-offs triggered by ease-of-use.

the only benefit of such an attack is that there'll be an even stronger
incentives to identify the compromised machines and get them off the net.

Additionally, it would be interesting to see if you could bring numerous charges
of theft of service against the advertising party.  (I.e. legal muscle backing
up the technological solution)

> This second problem is the main reason why any mainstream authentication
> solution requires the authentication to be done via third-party,
> (semi-)trusted servers.  It's much harder to pick keys off a dedicated server
> than some newbie's desktop, and if they are, that server can be de-listed
> quite quickly until it fixes the problem.

that doesn't solve the problem either.  Third party servers can be either
compromised or removed from the picture in a variety of ways which cause
different types of failures, all of which are painful.

I wish there was some way to easily protect a private key without requiring
passphrases.  Passphrases are death to cryptography from a human factors
perspective.  Any other identification mechanism that can be put into a USB fob
would be infinitely preferable to a pass phrase.  Whatever solution we develop
must be able to deal with the fact that people will leave machines on all the
time with USB fob inserted.

to tell you the truth, the solution doesn't even need to be person specific.
The question asked is more along the lines of "is there someone there" rather
than "is the correct person there".  It's just something to simply stop or
slowdown automated attacks and theft.  And it has to be dirt cheap and
infinitely replaceable without losing the private key.  I know, I don't want
much. :-)

> disadvantaged folks in the American desert.  So, if someone wants to know
> exactly how long a given algorithm will take on that machine, there's at
> least half a chance I'll run it and let them know.

Please run the C hashcash code found at hashcash.org.  I would appreciate seeing
the performance numbers.  I would also like to see them for any non Intel
machines as well like Sparc and Alpha.

---eric

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

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 13 Sep 2003 20:55:00 +0100

>> I like the idea of hashcash as an increase-spammer-costs strategy, 
>> but there's one big fly in the ointment.  The computational 
>> requirements effectively make a hashcash-based system impractical for 
>> small, ultra-portable or autonomous devices.
>
> delivering e-mail to other end nodes.

I suppose that's true, but they are still effectively MUAs in the 
e-mail system.

> After all, how many e-mails will people send using crippled keypad 

SMS "texting" is wildly popular here in Europe, despite the 
inadequacies of the phone keypad.  Someone I knew a couple of years 
ago, was already complaining loudly about the inadequate "free minutes 
/ texts" allowance on his mobile tariff - both of these allowances were 
well into the hundreds per month.  It's only a tiny user-interface step 
away from full e-mail, and I believe certain "super phones" do in fact 
have e-mail and limited Web capabilities.

To say nothing of PDAs, which actually have less powerful CPUs because 
they don't have to do DSP (voice compression).  I don't know how many 
Newtons there are still in circulation, but those were certainly 
capable of Internet stuff.

> machine as you flush the cache hard.

Memory speeds haven't scaled so well with Moore's Law, that's true - 
but memory sizes have.  A memory POW that properly exercises a 
large-cache Opteron (or, worse, POWER or Itanic) is going to overflow 
the memory of these tiny old Macs, which probably don't even have 
virtual memory to contain it.  And don't tell me spammers can't afford 
even one Itanic or POWER, expensive though they might be.

So, offloading it to an upstream machine, or dedicated hardware, looks 
more plausible.  I suppose it's not entirely infeasible to make an ADB 
version of the accelerator to complement the USB one.  I think I even 
found a chip vendor who could supply a single interface chip which had 
USB, ADB, PS/2 and serial support, limited only by the physical cable 
you chose to stick on it.

> background away from user visibility.

Still, Granny is used to hitting "Send" and having the modem dial out 
immediately, then cutting off again a minute or so later and shutting 
down the machine.  Changing that habit, especially to one where the 
modem dials out (mails * 50 minutes) later, is going to be painful.  
Better hope she has access to one of these accelerators.

And yes, I understand the point about it only happening for strangers, 
but we can't really lump people's mail habits into one box based on 
what class of computer they use.  For all we know, Granny could be the 
hub of an outreach program, talking to similarly-disadvantaged 
strangers every day.

>> in the $tens, and a set of custom PCBs can be had for $hundreds at 
>> worst. [...]
> seriously, I do believe that the additional stamp definitions and 
> proper postage due notice system can handle most of the attacks caused 
> by spammer specific hardware acceleration.

This is a fair point.  But I don't think we really want an arms race...

> another one of my crimes against humanity), I have learned that 
> sometimes certain classes of old machines just aren't worth the effort 
> anymore.  You need to learn when to go for higher quality junk instead 
> of wasting your time swearing and bleeding over a cantankerous 486.

You might have noticed I was talking about "old Macs", not "old PCs".  
:-)

Because old Macs are mostly very similar, and are durable enough to 
have few to no physical problems after 10 years' service in (say) a 
school, you can get them on the net using an involved, but still 
routine procedure.

Mostly, this involves installing and configuring system, driver and 
application software (all of which are free to use), and plugging in a 
modem (doesn't need to be fast, can be really cheap, from ebay).  A RAM 
upgrade may also be needed, but that's not difficult.

This makes them highly suitable for recycling in this manner.  You 
could easily go through 20 LC-IIIs (a popular model in schools, similar 
to but smaller than the IIcx) in a week once you knew what to do, and 
that means 20 people who now have outside-world contact they didn't 
have before.

> I think you exaggerate.

I was out by one or two orders of magnitude - in a follow-up post I 
calculated that a one-second task on an Athlon would be a 50-minute 
task on the IIcx.  I think my point survives this inconsistency.

> I will say however that that is spoken with the bias of someone who 
> leaves machines on 24 by 7 by 365 modulo power failures.

As do I, but I know my mother doesn't.  In fact, my mother makes a 
really good example of an utterly clueless luser (she has trouble using 
a Mac after years of experience), so expect to see her pop up 
gratuitously in future discussions.  ;-)

Fortunately, I don't think she's fundamentally realised that opening 
attachments is even possible.  Even more fortunately, her Windoze 
machine helpfully screwed up it's modem drivers last year, and I never 
bothered fixing it - just told her to use the Mac instead.  Thank 
goodness for small mercies.

I'll use my dad as a representative example of a none-too-clueful but 
intelligent and half-competent user - he's been using e-mail, in one 
form or another, ever since his university got it.

> to attackers hoping to profit from this data or system resources.

Indeed.  But that's why my authentication scheme placed responsibility 
for throttling on the MAA, which has enough of a business relationship 
with the user to warn him if something's not right, but enough 
flexibility to cater for different users' needs.  Centralising 
responsibility at the MAA also allows for better security than the user 
can (on average) provide himself, though I'm willing to accept that it 
still won't be perfect.

How is the MAA's responsibility managed?  By the trust directory - if 
the MAA is compromised or doesn't do it's job, it will be delisted.  
How is the trust directory's responsibility managed?  By recipients who 
can switch if they're not happy.  I think there's as much 
checks-and-balances in that scheme as is reasonable.

> resentment and firm resistance.  People will demand features that will 
> enable them to get screwed because it is convenient to or increases 
> the effectiveness of how they work.  Short of a major eugenics 
> program, that part of human nature isn't going to change.

Which is why I think holding the actual authentication keys on a user's 
machine, in any form (even a physical token) is a Bad Idea.  Even if 
you make a device that has a "confirm" button on the front of it, 
someone else will eventually come along and make one that doesn't have 
a button, it'll be cheaper so everyone will buy it (especially OEMs 
that influence what most consumers get in the first place), and we're 
back to square one.

At most, we want to store the user's dial-up and MAA passwords in his 
own machine.  Once again, it's the MAA's responsibility to prevent 
abuse of their service, since they're in a position to do so.  That 
means stealing a user's password using a worm isn't such a big threat 
as stealing his private key would be.

Stealing his CPU time for hashcash would be a more serious problem.  A 
typical luser's machine isn't terribly fast, but having lots of them at 
the spammer's command (a future Sobig variant?) means they can be quite 
powerful in combination.  To guard against this, if we use hashcash, it 
*must* be in combination with authentication, not as a standby 
replacement for it.

> machines as well like Sparc and Alpha.

I'll see what I can pull together.

I might have access to a Sparc machine of some description, though I'm 
less sure of it's spec (it's the all-access university UNIX system).  
Aside from that, I have the handful of x86, 68K and PPC boxen I 
mentioned earlier.  No Alphas, I'm afraid.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 13 Sep 2003 21:20:38 +0100

> I'll see what I can pull together.

First, a 1600MHz Athlon-XP:

chromi@hydrogen hashcash-0.27 $ ./hashcash -s -b 20
time estimate: 2 seconds
chromi@hydrogen hashcash-0.27 $ ./hashcash -s
speed: 649351 collision tests per second

Second, a 200MHz Pentium-MMX:

chromi@lithium hashcash-0.27 $ ./hashcash -s -b 20
time estimate: 15 seconds
chromi@lithium hashcash-0.27 $ ./hashcash -s
speed: 69396 collision tests per second

Both of the above are using GCC3 with default compile options, no 
architecture or CPU specific stuff.  Surprisingly, the scaling looks 
linear with clock speed, an old Pentium isn't usually this good when 
compared with an Athlon.  I'll have to examine the algorithm and figure 
out why.

It doesn't compile first time on the Macs, will need to hack on it a 
bit.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 00:14:00 +0100

> compared with an Athlon.  I'll have to examine the algorithm and 
> figure out why.
>

Got it to compile on a Classic Mac, mostly by hacking out all the 
option parsing.  The below is using CodeWarrior Pro 5, optimised for a 
PPC601 or 68020.

400MHz G3:    270000 collisions/sec
400MHz G3:    114000 when emulating 68K code
  80MHz 601:    36100
  80MHz 601:    13700 when emulating 68K code
  80MHz 68040:   5500
  16MHz 68030:   1000

Plus, I had to un-stiction the HDs on the two 68K machines.  They'd 
been sitting around for a while.

So, broadly speaking, the IIcx will take about 20 minutes to make a 
20-bit hashcash, on average.  That's a lot better than I expected, and 
it *might* just be acceptable to patient old Granny, as long as it 
doesn't happen while she's already online, and she has the presence of 
mind to go make a pot of tea or something while she waits.

It looks like the '030 isn't as far behind the '040 (architecturally) 
as I thought, though it still has a big clock-speed gap.  I also take 
these numbers as a fairly clear sign that the hashcash algorithm fits 
into a very small L1 cache, because the IIcx's memory is *very* slow.

(NB: Apple marketed the 80MHz 68040 as a "40MHz" CPU, referring to the 
external clock rather than the clock-doubled core.  Modern terminology 
always refers to the core speed, so I corrected that here.  The '040 
can be considered equivalent to a 486DX2.)

Finally, the SPARC machine - which I'm still unsure of the specs for - 
gave about 250000 collisions/sec, and an estimated 4 seconds to make a 
20-bit hashcash.  If anyone who knows about Solaris can tell me how to 
extract basic information about the machine (from an unprivileged 
account, natch), I'd be grateful.  I'd hazard a guess that it's a 
recent but low-end multiprocessor workstation.

I'd also try to give you scores for an ARM, but I don't have access to 
my parents' Acorn Archimedes from over here.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 02:32:09 +0200

At 12:14 AM +0100 2003/09/14, Jonathan Morton wrote:

>                           If anyone who knows about Solaris can tell
>  me how to extract basic information about the machine (from an
>  unprivileged account, natch), I'd be grateful.  I'd hazard a guess
>  that it's a recent but low-end multiprocessor workstation.

	A Solaris 9 box that I have access to provides the following information:

% /usr/platform/`uname -i`/sbin/prtdiag -v
System Configuration:  Sun Microsystems  sun4u Sun Ultra 1 SBus 
(UltraSPARC 167MHz)
System clock frequency: 84 MHz
Memory size: 256 Megabytes

========================= CPUs =========================

                     Run   Ecache   CPU    CPU
Brd  CPU   Module   MHz     MB    Impl.   Mask
---  ---  -------  -----  ------  ------  ----
  0     0     0      167     0.5   US-I     4.0

========================= IO Cards =========================

      Bus   Freq
Brd  Type  MHz   Slot        Name                          Model
---  ----  ----  ----------  ----------------------------  --------------------
  0   SBus   25            0  SUNW,hme                      SUNW,501-2739
  0   SBus   25            0  SUNW,fas/sd (block)
  0   SBus   25           14  espdma/esp (scsi)
  0   SBus   25           14  ledma/le (network)
  0   SBus   25           14  SUNW,bpp
ERROR: Cannot determine PCI device type.

No failures found in System
===========================

========================= HW Revisions =========================

ASIC Revisions:
---------------
SBus: sbus Rev 1
FEPS: SUNW,hme Rev 22

System PROM revisions:
----------------------
   OBP 3.5.0 1997/01/06 18:05   POST 3.10.6 1996/10/18 10:19

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 02:09:25 +0100

> % /usr/platform/`uname -i`/sbin/prtdiag -v

Ah, thanks.

% /usr/platform/`uname -i`/sbin/prtdiag -v
System Configuration:  Sun Microsystems  sun4u Sun Enterprise 450 (4 X 
UltraSPARC-II 480MHz)
System clock frequency: 96 MHz
Memory size: 4096 Megabytes

                     Run   Ecache   CPU    CPU
Brd  CPU   Module   MHz     MB    Impl.   Mask
---  ---  -------  -----  ------  ------  ----
SYS     0     0      480     8.0   US-II    1.0
SYS     1     1      480     8.0   US-II    1.0
SYS     2     2      480     8.0   US-II    1.0
SYS     3     3      480     8.0   US-II    1.0

[snipped]

Looks like I was wrong about it being low-end.  :-)  This machine 
replaced a cluster of three four-way 100MHz boxes, which *were* 
repurposed workstations.

FWIW, it appears that the UltraSPARC II is slightly less efficient (by 
maybe 20%) per-clock than the G3, but that's not a bad deal overall - 
the G3 is known to be exceptionally good in that area.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 04:53:19 +0200

>  replaced a cluster of three four-way 100MHz boxes, which *were*

	Four-way 100MHz boxes?  I don't recall Sun making something like 
that.   What kinds of machines were they exactly?

>  FWIW, it appears that the UltraSPARC II is slightly less efficient
>  (by maybe 20%) per-clock than the G3, but that's not a bad deal
>  overall - the G3 is known to be exceptionally good in that area.

	Keep in mind that your E450 is an SMP box, but the code you're 
running almost certainly is not parallelized.  So, you're only going 
to be using one CPU.

	It would be interesting to compare these hashcash benchmarks 
against the SPEC CPU benchmarks at <http://www.spec.org/cpu2000/>, as 
well as the predecessors, so that we can try to get some sort of idea 
how various classes of machines will perform.

	If you can point me at the code, I can run the same test on a 
variety of hardware I have access to, which may provide some useful 
additional data points.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 05:13:07 +0100

> Four-way 100MHz boxes?  I don't recall Sun making something like that. 
>   What kinds of machines were they exactly?

I don't remember very precisely, but a friend who apparently saw them 
physically reported that they were of the "pizza box" form factor used 
for many Sun workstations.  A fourth, identical unit was used as a 
fileserver for the other three.

Needless to say, these machines weren't particularly fast, but they did 
handle lots of users quite well, except when a CPU conked out in the 
fileserver with fairly predictable results.  They can't have been 
enterprise servers, otherwise the admins would have been able to 
disable the bad CPU until the replacement arrived.

> Keep in mind that your E450 is an SMP box, but the code you're running 
> almost certainly is not parallelized.  So, you're only going to be 
> using one CPU.

Naturally.  I was comparing the 250K score on the 480MHz UltraSPARC 
with the 270K on the 400MHz G3, which works out about 20% difference.

But in a server environment, you're going to be able to search for 
several hashcashes in parallel, so the overall throughput of the E450 
will be about one hashcash per second, while the G3 will only be one 
every four.  The individual code doesn't need to be parallelised, you 
just need multiple jobs to run.

And it looks like my Pentium-MMX will take longer to make hashcash than 
it presently does to run SpamAssassin.  A data point worth noting.

> It would be interesting to compare these hashcash benchmarks against 
> the SPEC CPU benchmarks at <http://www.spec.org/cpu2000/>, as well as 
> the predecessors, so that we can try to get some sort of idea how 
> various classes of machines will perform.

Yes, that might be interesting.  Also worth checking are the 
distributed.net statistics, some of which are collected on a 
per-architecture basis.  The distributed.net stats are interesting 
mainly because they use a cryptographic algorithm (RC5), which is 
presumably not overly dissimilar in characteristics to hashcash (SHA1).

> If you can point me at the code, I can run the same test on a variety 
> of hardware I have access to, which may provide some useful additional 
> data points.

http://hashcash.org/

The actual code is on the "old site" linked from there.  As mentioned, 
I had to hack it up to make it work on Macs, but I think I have all the 
useful info we can get from Macs for now.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 06:13:01 +0200

At 12:14 AM +0100 2003/09/14, Jonathan Morton wrote:

>  option parsing.  The below is using CodeWarrior Pro 5, optimised
>  for a PPC601 or 68020.

	Compiling on my PowerBook G4 only required taking the following 
line and moving it outside of the #ifdef:

		#include "getopt.h"

	Anyway, my results.  First, my PowerBook G4 (800MHz DVI, 1GB RAM, 
MacOS X 10.2.6):

		% ./hashcash -s -b 20
		time estimate: 2 seconds
		% ./hashcash -s
		speed: 779500 collision tests per second

	On an old Compaq Armada 4131T laptop w/ Pentium-133 (not MMX), 
48MB of RAM, and FreeBSD 4.6.2-REL, I get:

		% ./hashcash -s -b 20
		time estimate: 28 seconds
		% ./hashcash -s
		speed: 37400 collision tests per second

	On the UltraSPARC server I previously mentioned (Sun 
UltraEnterprise 1, UltraSPARC-I @ 167MHz, 256MB RAM, Solaris 9), I 
get:

		% ./hashcash -s -b 20
		time estimate: 14 seconds
		% ./hashcash -s
		speed: 75200 collision tests per second

	As soon as I can get my Soekris 4521 WiFi base stations/firewalls 
up and running, I can give you some benchmarks on them also.  And 
when my Ultra 10 clones come in, and my 4-way Intel 
compute/fileserver arrives, I can run those as well.

	Note that the UltraSPARC machine listed above is the mail server 
for a reasonably high-profile project that I am otherwise involved 
in, and I imagine it would be hurt pretty bad if we had to run a 
hashcash scheme on it.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 05:25:40 +0100

> Compiling on my PowerBook G4 only required taking the following line 
> and moving it outside of the #ifdef:
>
> 		#include "getopt.h"

That's on OSX.  My goal was to run it under System 7.1 (the IIcx), 
MacOS 8.1 (the Quadra) and MacOS 8.6 (a PowerMac 8100/80 with a 400MHz 
G3 upgrade, the latter disabled for one of the tests).  :-)

Now, I *also* happen to have a 400MHz G3 PowerBook, running OSX.

-bash-2.05b$ ./hashcash -s
speed: 378100 collision tests per second

It would appear that GCC3 makes a lot better code than CodeWarrior Pro 
5, a pleasant turnabout from GCC2's (lack of) performance on PPC.  The 
latter, incidentally, is somewhat out of date, but it's what I use for 
68K code.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 06:27:38 +0100

> of hardware I have access to, which may provide some useful additional 

Actually, let's step back a bit.  The original question was whether 
this was going to be (even approximately) workable on low-end machines, 
like the old Macs I mentioned.  I think we've established that it's 
moderately painful, but yes it's workable, as long as we don't need 
more than 20-bit hashcash anytime soon.

We additionally have the option of offloading really slow machines' 
work to the MAA, but keeping server load low by having most MUAs do it 
themselves.  So, I don't think I'm overly concerned about particular 
machines' performance - except for the really slow MUAs for workability 
reasons, and really fast clusters / dedicated hardware that might be 
used by spammers for circumvention.

If the magnitude of performance difference approaches the magnitude of 
mail-volume difference, hashcash is in trouble - unless we can get 
coprocessing hardware to people who probably can't afford it.  That's a 
reasonably simple fact.

Now there's other questions.

Suppose we implement a "postage required" callback to promote awareness 
in the early stages.  What happens when one of these callbacks hits a 
listserv that doesn't know about it?  AFAIK, most listservs will 
probably interpret it as a bounce, which is probably counterproductive.

Also, what's the best way to combine hashcash and authentication?  Not 
forgetting, of course, that we still need to have lots of backwards 
compatibility that can (very gradually) be phased out.  It would be 
nice to be able to avoid hashcash for initial communications in certain 
situations, because that lets some of the low-end users off the hook, 
but that has to be watertight.

Finally, as an interim solution, can hashcash be effectively used as a 
filtering modifier?  Take SpamAssassin, for example, you could subtract 
a point from the spam score, for every bit of hashcash after the first 
N (say 16).  That'd be handy for people who keep getting caught by the 
filters for reasons beyond their control - it gives them a "get out of 
jail" card, cheap for low-volume mail, expensive for bulk.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 13:14:15 +0200

At 6:27 AM +0100 2003/09/14, Jonathan Morton wrote:

>  Actually, let's step back a bit.

	'k

>  Suppose we implement a "postage required" callback to promote
>  awareness in the early stages.  What happens when one of these
>  callbacks hits a listserv that doesn't know about it?  AFAIK,
>  most listservs will probably interpret it as a bounce, which
>  is probably counterproductive.

	Indeed.  We need to be careful about the SMTP Response Codes that 
we issue on a hashcash-enabled MTA.

>  Also, what's the best way to combine hashcash and authentication?

	On a hashcash-enabled MTA, we accept a hashcash-stamped message 
on the first try and 4xx tempfail others?  Maybe we also require a 
minimum waiting period before we accept a non hashcash-stamped 
message?

>  Not forgetting, of course, that we still need to have lots of
>  backwards compatibility that can (very gradually) be phased out.

	Indeed.

>  It would be nice to be able to avoid hashcash for initial
>  communications in certain situations, because that lets some of
>  the low-end users off the hook, but that has to be watertight.

	I think you could do this on a per-interface, or at least a 
per-source network basis -- your "local" clients don't need hashcash 
to get you to accept the message.  Or maybe a client that 
successfully uses SMTPAUTH and/or TLSSMTP doesn't need hashcash?

>  Finally, as an interim solution, can hashcash be effectively used
>  as a filtering modifier?

	Probably.  Is hashcash hard to calculate and easy to verify?

>                            Take SpamAssassin, for example, you
>  could subtract a point from the spam score, for every bit of
>  hashcash after the first N (say 16).  That'd be handy for people
>  who keep getting caught by the filters for reasons beyond their
>  control - it gives them a "get out of jail" card, cheap for
>  low-volume mail, expensive for bulk.

	That sounds like an interesting first-pass, yes.  Of course, this 
would have to be integrated into the default version of SpamAssassin 
that everyone installs (and other filtering agents), in order for 
something like this to be of value.  Otherwise, you're calculating 
this stuff and stamping your messages with it for nothing.

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sun, 14 Sep 2003 11:51:39 -0400

Jonathan Morton explained:

> Actually, let's step back a bit.  The original question was whether this 
> was going to be (even approximately) workable on low-end machines, like 
> the old Macs I mentioned.  I think we've established that it's 
> moderately painful, but yes it's workable, as long as we don't need more 
> than 20-bit hashcash anytime soon.

while it would be nice to stay at 20 bits, I suspect that the real initial value 
should be somewhere around 22 bits may be even 23.  This does put quite a strain 
on low-end machine users but I think it's a manageable one as we have discussed.

I do appreciate to your concern for the low-end user.  However, I believe they 
are a fringe user population.  I understand quite clearly what it means to be a 
fringe user and not get any support from the mainstream.  I am disabled courtesy 
the qwerty keyboard.  I an extremely dependent on speech recognition computer 
use.  There's precious little support for my kind of disability in computer user 
interface and even less for speech recognition on Linux.

So, I have found ways to work around the lack of accommodation.  so will people 
with low and computers.  And I am sure, we will try to help by designing the 
right kind of services etc.

> probably interpret it as a bounce, which is probably counterproductive.

this is part of what I was writing up in the hashcash best practices ID.

The way camram accommodates the real world is to provide multiple levels of 
filters.  The first stage is the postage check, second stage is the white list 
check, third is a Bayesian style discriminator.

The third stage is important because it lets me split e-mail into three 
categories (red, yellow, green).  Green is good and passed to the inbox.  Red is 
bad and passed to the dumpster.  Yellow is the e-mail which is indistinguishable 
from Spam[1].  The camram system will send out postage due notices to the 
originators of yellow mail.  From that action, we can further refine which 
messages are spam by paying attention to how the connection is rejected.

after receiving a postage due notice a user can then generate postage in their 
browser courtesy a Java applet and deliver the stamp allowing their message to 
be delivered.  In the document I am working on, I with the issues of forgery and 
spoofing and ways to deal with them.

> compatibility that can (very gradually) be phased out.  It would be nice 
> to be able to avoid hashcash for initial communications in certain 

does it really need to be watertight?  Is authentication a good idea?  one of my 
starting points for an antispam system is:

     Any measure for stopping spam must ensure that all non-spam messages
     have a means for bypassing that measure to reach their intended
     recipient.

another is that an antispam system must never become a tool for censorship.

If an authentication system has the properties of being able to silence a 
spammer by revoking their credentials, then you have created a tool by which 
anyone can be silenced.  This means you can be silenced.

Imagine how effective we would be against corporate interests if they could use 
the DMCA to revoke your ability to send e-mail.  That is what authentication 
systems buy you.  It is a system enabling censorship.

I'm probably going to get pilloried for this but like it or not, spam is speech 
in the same way that naked breasts on a dancer, Johnny Ashcroft Patriot act 
roadshow, burning a flag of any country, and even yelling fire in a crowded 
theater is speech.  But with all speech comes costs.  Free is not equal $free$ 
and if you're willing to bear the cost, you can make the speech.  At the same 
time, part of the freedom of speech is the ability to be heard but you cannot 
force others to listen.

The more we can follow that model of speech, the closer we will be to a good 
antispam solution.  For example, if we can push the cost of spam as much as 
possible onto the backs of the spammers, we will make unprofitable for the vast 
majority of them.  Then we can watch and learn how to make it more expensive for 
the rest of them.

when analyzing antispam systems, ask yourself "who pays".  With authentication 
systems that I've seen, typically it's increasing the receiver costs for 
decreasing freedom.  Only decentralize systems minimize user costs as a rule and 
have decent reliability in a whole bunch of dimensions.

Personally, I believe that Spam will never go away.  There will always be some 
form of organization which will pay the cost and mass mail.  That's why there'll 
always be a need for personal blacklisting so folks can say "I don't want to 
hear that" and make it stick.  The trick will be making the human interface so 
drop dead simple even your grandmother can't screw it up or at least you can 
unscrew it when she does.

> a point from the spam score, for every bit of hashcash after the first N 
> (say 16).  That'd be handy for people who keep getting caught by the 

you really should take a look at the camram code in CVS.  Much of what you 
suggest is already done.  It may not be exactly as you envision it but 
functionally its equivalent.  Now I just need some Java talent to help me finish 
with the browser postage due applet.

---eric

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sun, 14 Sep 2003 12:07:59 -0400

Brad Knowles explained:

>     Indeed.  We need to be careful about the SMTP Response Codes that we 
> issue on a hashcash-enabled MTA.

problem.  You are looking at the hashcash model in a classic but fundamentally 
flawed way.  I have a very different insight which camram takes heavy advantage 
of.  This insight is that e-mail really consists of two protocols, the transport 
layer (SMTP) and the content interpretation layer (headers and body).  By 
recognizing that you only need to change the interpretation layer to include 
stamps or certificates or whatever, the problem is simplified.

camram puts all of its efforts into the interpretation where because that's 
where you need to make the decisions about spam.  Now you may want to have some 
additional authentication features at SMTP layer but that is completely 
independent and orthogonal to what camram does.

camram implements electronic stamps.  Stamps go on the envelope and are 
associated with the message independent of how you get it there.

although I have discovered that server side filtering and stamp generation 
really needs to know who is okay and who is not for sending messages.  It's 
probably going to require either multiple interfaces (for enterprise) or 
SMTPAUTH for the general ISP case.

> something like this to be of value.  Otherwise, you're calculating this 
> stuff and stamping your messages with it for nothing.

well, that's is what will be happening with camram 0.2.  All messages classified 
as "yellow" (neither spam nor ham) will be triggering postage due notices.  So 
with no stamps, it's what you describe.

there is a problem with setting up a response only environment and that is 
determining when to start generating stamps.  If we implement automatic postage 
due response handling in the very beginning, then once you hit the 10 percent 
threshold for postage due notices vs. outbound mail, then it might be possible 
to do that.  It would also have the advantage of giving folks chance to 
establish a white list and minimize stamp generation from the get go.

anyway, this is definitely getting into the implementation realm and I encourage 
you to sign up for the camram mailing list (it's low-volume, believe me) and 
start making this shared vision real.

---eric

PS, I've been living with stamp generation for the past four months on a Pentium 
II/333 in foreground mode and it doesn't suck too bad although it would be 
better in the background.  Check the headers.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 14 Sep 2003 21:51:34 +0100

> Imagine how effective we would be against corporate interests if they 
> could use the DMCA to revoke your ability to send e-mail.  That is 
> what authentication systems buy you.  It is a system enabling 
> censorship.
>
> I'm probably going to get pilloried for this but like it or not, spam 
> is speech in the same way that naked breasts on a dancer, Johnny 
> Ashcroft Patriot act roadshow, burning a flag of any country, and even 
> yelling fire in a crowded theater is speech.

<offtopic>
Or the British National Party.  They have a right to exist, as long as 
they don't actually break any laws, and we have the right to pour scorn 
upon them for their neo-Nazi and totalitarian agenda.  Really, if the 
BNP didn't exist, their members would pop up in the mainstream parties 
and *then* we'd be in trouble.
</offtopic>

> But with all speech comes costs.  Free is not equal $free$ and if 
> you're willing to bear the cost, you can make the speech.  At the same 
> time, part of the freedom of speech is the ability to be heard but you 
> cannot force others to listen.
>
> The more we can follow that model of speech, the closer we will be to 
> a good antispam solution.

You're right, highly centralised authentication systems are censorship 
waiting to happen.  That's one reason why the system I suggested 
recently is moderately decentralised - there is no mandated group of 
"root servers" as in DNS, instead the recipient's MAA chooses a trust 
directory, and the recipient chooses the MAA.

Key is the fact that the recipient chooses who verifies the sender's 
chain of integrity.  That means he can choose what groups of senders to 
not listen to.  If one trust directory goes "bad", MAAs and/or 
recipients can switch to a new one.  There's also not much barrier to 
entry to setting up a new trust directory or MAA, if you think one's 
needed.

Most of my ramblings in this thread really have to do with how hashcash 
might be useful as a supplement to my own authentication system, and 
how it would impact users *that I know* who have somewhat lacking 
hardware.  There's a surprising number of older machines out there 
which are entirely adequate for their users.

Remember that in my system, the MAA handles authentication via a 
signature, and it would also be possible - even practical - to have it 
handle hashcash for (a subset of) it's users as well.  That's why I've 
moved on to the operational considerations, rather than the obvious 
technical ones, before I decide whether it would be worthwhile to add 
to my draft document.

In other words, I'm convinced the technical hurdles can be overcome - 
in the context of my own system.  I'm less sure of other systems, 
particularly those that seem to require coprocessing hardware for the 
low-end users when the postage costs escalate.

BTW, I do have some Java skills, but I find using them gives me COBOL 
fingers.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 22:56:30 +0200

At 11:51 AM -0400 2003/09/14, Eric S. Johansson wrote:

>  after receiving a postage due notice a user can then generate postage
>  in their browser courtesy a Java applet and deliver the stamp allowing
>  their message to be delivered.

	Hmm.  Kinda like TMDA.  I don't bother responding to anyone who 
uses TMDA-like systems.

	One thing that definitely needs to be kept in consideration is 
the amount of additional hassle that is caused by any system we 
recommend.

---

From: Brad Knowles <[email-masked]>
Date: Sun, 14 Sep 2003 23:02:04 +0200

At 12:07 PM -0400 2003/09/14, Eric S. Johansson wrote:

>  camram puts all of its efforts into the interpretation where because
>  that's where you need to make the decisions about spam.

	If you are looking at the content, there is no other way you can 
do that.  However, my view is that this decision needs to be made 
while the sender is still connected, so that you can decide what kind 
of SMTP Reply code to generate.

	If you look at the message and decide what to do with it 
after-the-fact, then you've already lost.  If nothing else, you open 
yourself to being used to DoS someone in a joe-job.

>  PS, I've been living with stamp generation for the past four months
>  on a Pentium II/333 in foreground mode and it doesn't suck too bad
>  although it would be better in the background.  Check the headers.

	Lots of things work acceptable well in small-scale use, but fail 
completely when you try to scale them up.

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sun, 14 Sep 2003 18:18:06 -0400

Brad Knowles explained:

>     Hmm.  Kinda like TMDA.  I don't bother responding to anyone who uses 
> TMDA-like systems.
> 
>     One thing that definitely needs to be kept in consideration is the 
> amount of additional hassle that is caused by any system we recommend.

understood and I agree.  It is your right to ignore such a message and if you're 
willing to accept the consequences of your message not being seen, then all is 
wonderful.  The only reason the postage due mechanism is there is for a 
failsafe/fallback action that allows the message sender to insure message 
delivery.  Is not intended to be the general case mechanism for supplying 
postage.  I have spent a fair amount of time showing the postage due mechanism 
to non-geeks and 80 percent get it right off the bat and the rest become 
comfortable after asking some questions about operation, what it does, how long 
it takes etc.

I have put a great deal of effort into working out mechanisms to minimize the 
number of postage due notices sent.  the discriminator I spoke of earlier 
eliminates the vast majority of messages from postage due processing.  I also 
have worked to develop heuristics for identifying mailing lists and eliminating 
postage due notices to people on mailing lists.  The heuristics aren't perfect 
and not all mailing lists the fingerprints identifying themselves as a mailing 
list but I do the best I can with what is available.

---eric

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sun, 14 Sep 2003 18:32:37 -0400

> entry to setting up a new trust directory or MAA, if you think one's 

than we should have a conversation of line if you don't mind because what you're 
describing could potentially be very good but dammed hard to fit into a simple 
human factors model.  Embedding public keys in messages and setting up 
opportunistic signatures/encryption within camram was an attempt to create a 
less forgeable white list and to provide envelope grade content protection.  But 
I'm starting to wonder if may be it might be more useful in the mechanism you've 
hinted at.  That maybe there's a way to publish your key, get it "blessed" from 
some authority people are willing to trust (i.e. the hotdog vault and trust 
company).  Then that would give us a way to change keys should a disk go poof 
sans backup.

> might be useful as a supplement to my own authentication system, and how 
> it would impact users *that I know* who have somewhat lacking hardware.  
> There's a surprising number of older machines out there which are 
> entirely adequate for their users.

unfortunately hashcash isn't a useful authentication tool.  It is a useful 
introducer however.  The protocol I was trying to support is the basic e-mail 
protocol of today which is "hello, you don't know me but I would like you to 
read my message."  I have had wonderful connections established because of this 
protocol.  Hashcash adds the step "and this is how much it is worth to me for 
you to see my message".  That's it.  It says nothing about who you are or 
whether or not your identity is valid or anything that nature.  It also 
preserves end to end connectivity on the net for servers like mine (at the end 
of a speakeasy DSL line).

Sometime later we should probably talk about my vision for the future which is 
that personal e-mail and Web+++ servers will be set up in the home just like 
answering machines are today.  And they should be somewhat easier to operate.

> In other words, I'm convinced the technical hurdles can be overcome - in 
> the context of my own system.  I'm less sure of other systems, 

I have more faith and spoken with more average users about this topic.  In the 
best of all possible worlds, camram would exist inside of every e-mail client 
shipped.  Many of the scaling issues go away because it's designed to be 
distributed.  There are some cases where cooperation with a more central service 
would be beneficial such as public key verification or propagation but for the 
most part, it can stand alone and do so quite nicely.

> BTW, I do have some Java skills, but I find using them gives me COBOL 

it's only a little applet, it's mostly written but just needs to be modified... 
you might only get COBOL fingernails from that.

---eric

---

From: "Eric S. Johansson" <[email-masked]>
Date: Sun, 14 Sep 2003 18:57:46 -0400

Brad Knowles explained:

>     If you are looking at the content, there is no other way you can do 
> that.  However, my view is that this decision needs to be made while the 
> sender is still connected, so that you can decide what kind of SMTP 
> Reply code to generate.
> 

my belief, based on all the efforts I have seen is that identifying a spammer at 
the server is extremely difficult.  By the time they are shipping you data, they 
have already one according to your definition.  I've heard from a few folks I 
trust that one of the tricks they do is show the message in during the data 
phase, send the . and close the connection.  If it won't close, they just drop 
it.  The only ability to deal with spam at the connection level IMO is to take 
feedback from your clients and then associate that feedback within IP address as 
a spam source.  Then you can pull all sorts of tricks such as connection 
stalling tuning SMTP responses etc. for future connections but that's a 
potentially dangerous feedback loop especially if the triggers are controlled by 
folks not necessarily trained in dealing with spam.

With the camram model, yes, you are looking at messages after the fact.  But, if 
it's a strictly postage and white list environment, that message isn't going 
anywhere near the users inbox.  It's going in spamtrap.  Even with the addition 
of a well tuned discriminator, the risk or possibility of dangerous unstamped 
e-mail coming into the users inbox is low.

During one of the latest e-mail viruses, one of my clients started labeling all 
of the reproductive messages as spam.  Within a few training sessions, the virus 
problem went away because it was all placed in the dumpster.  Personally, I 
never would have thought of doing that but I have a clever client.

so far, it looks to me like filtering at the end node especially on a postage 
base system is very easy, low-cost, and high payoff

> completely when you try to scale them up.

that's true but remember, camram is supposed to "fail" at the high end.  That's 
how it causes pain to spammers.  Only works in server mode because of the 
"friends fly free" principle.  If you generated a stamp for every single 
message, camram would "fail" by restricting the number of messages that could be 
sent in a given time period.  From a traffic standpoint, a legitimate 
high-volume mail server behaves exactly the same as a spammer mail server.  This 
is why I want to push stamp generation is close to the edge as possible.

In the small at each e-mail client generating stamps should be low pain and, for 
all practical purposes, invisible.  I must say, this is one of things that makes 
me the most excited about camram.

You don't need to be a network genius to make it work.

in fact, you don't really need to learn anything new except how-to manipulate 
the spamtrap (10 minutes if you are dim) and how/when to set configuration 
parameters.  Right now, any average administrator can operate and cleanup camram 
spamtrap in 10 to 15 minutes per day if you operate in global mode (i.e. 
everyone on the server).  If you operate in individual user mode, you're still 
looking at 2-3 minutes a day tops.  In fact I frequently ignore the spamtrap for 
two or three days at a time without any pain.  That is good human factors and is 
something we should all be striving for in our solutions.  if we create a 
solution that is the jobs program for IT, we have come up with the wrong 
solution.  It will put the burden of cost on the user and not the spammer where 
it belongs.

anyway, that's my Sunday night rant.  Make the it simple, drive the cost of 
installation and daily operation through the floor and that solution will be a 
good one.

---eric

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 15 Sep 2003 02:06:41 +0100

> During one of the latest e-mail viruses, one of my clients started 
> labeling all of the reproductive messages as spam.  Within a few 
> training sessions, the virus problem went away because it was all 
> placed in the dumpster.  Personally, I never would have thought of 
> doing that but I have a clever client.

I did the same with SpamAssassin when Sobig.F started hitting me with 
hundreds per day (bounces and infections alike).  I manually set the 
MICROSOFT_EXECUTABLE score to 10.0 (the default score is only 0.3) and 
set up Procmail to dump messages above 8.0.  I'm pretty sure that dealt 
with over 99% of the problem.

I personally think that nearly all ISPs, especially those with a large 
proportion of newbies, should delete directly-executable attachments 
without question.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 15 Sep 2003 04:42:51 +0200

At 2:06 AM +0100 2003/09/15, Jonathan Morton wrote:

>  I personally think that nearly all ISPs, especially those with a
>  large proportion of newbies, should delete directly-executable
>  attachments without question.

	There, I must disagree very strongly.  Plenty of people in this 
world have reason to be mailing attachments around, although I'm 
opposed to their using e-mail as a replacement for proper 
file-transfer technologies for large attachments.

	Yes, I agree that there should be some default controls to make 
this sort of stuff less dangerous, but I am most certainly not 
convinced that they should be deleting directly executable 
attachments unless expressly asked to do so.

	This would be a good topic for coverage in the BCP for service providers.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 14 Sep 2003 22:54:23 -0400

Brad Knowles wrote:

> world have reason to be mailing attachments around, although I'm opposed 
> to their using e-mail as a replacement for proper file-transfer 
> technologies for large attachments.
> 
>     Yes, I agree that there should be some default controls to make this 
> sort of stuff less dangerous, but I am most certainly not convinced that 
> they should be deleting directly executable attachments unless expressly 
> asked to do so.
> 
> 

And BCP for MUA authors.

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 15 Sep 2003 04:17:59 +0100

>> file-transfer technologies for large attachments.

Attachments, yes.  Executables, no.  Executables wrapped in an archive 
are quite a lot less dangerous than bare ones.

>> This would be a good topic for coverage in the BCP for service 

Agree on both counts.

---

From: david nicol <[email-masked]>
Date: 15 Sep 2003 00:21:01 -0500

On Sun, 2003-09-14 at 16:02, Brad Knowles wrote:
> after-the-fact, then you've already lost.

I'm remembering Message-IDs.  The first time I see a message
that I am going to 4xx after the dot for want of "magic phrase"
I remember the messageID.  If this message returns (again, the
body being accepted in provisional mode) before the problem
is dealt with (alteration of recipient's magic phrase timestamp,
appearance of a sender payment account) they get their connection
dropped on presentation of an already-seen message-ID.

Or is it better to tarpit at that juncture?  Maybe tarpitting
is better.

Does CAMRAM include tarpitting?

-- 
David Nicol /  kernel 2.6.0 is pretty whippy

---

From: "Eric S. Johansson" <[email-masked]>
Date: Mon, 15 Sep 2003 08:32:51 -0400

> proportion of newbies, should delete directly-executable attachments 

while there is an autocratic part of me that agrees most heavily with what you 
say, I also fear the hubris inherent in the situation.  This is what I think in 
isolation place or spamtrap equivalent is what is called for.  That way the user 
can determine whether or not they really want that piece of e-mail.  On the 
gripping hand however I have rarely received an executable by e-mail from anyone 
except someone I have had long conversations with (i.e. OEM technical support)

the nice thing about a spamtrap (at least the way I have designed/implemented) 
is that I can get an audit trail of messages and who approved them.  So in the 
case of a virus, you can know which employee is a FWM and started the infection 
process.

---eric

---

From: Brad Knowles <[email-masked]>
Date: Mon, 15 Sep 2003 17:49:27 +0200

At 12:21 AM -0500 2003/09/15, david nicol wrote:

>  I remember the messageID.

	IMO, doing this during the SMTP conversation (before you accept 
responsibility for the message) is about the best you can hope for.

>                            If this message returns (again, the

	Hmm.  I think I'd be inclined to wait a minimum amount of time 
between the "first seen" and "reject message" phases.  Give people a 
little while to get their updated information out there, before you 
outright reject the message.