Subject: [Asrg] Spam Salt, an email sender authentication mechanism

From: Kai Engert <[email-masked]>
Date: Tue, 28 Sep 2010 03:15:14 +0200

Dear members of the ASRG mailing list,

I'd like to present you my anti-spam idea which I call Spam Salt.

Abstract:
The idea is to assign an additional secret key (salt) to each email user 
account. The email sender uses the salt and the message contents to 
calculate a hash value and adds that hash value as a new email header. 
For each email domain a verification server is registered in the DNS 
that can be contacted to verify the authenticity of messages that 
contain a hash value in the email headers. An email recipient can 
contact a verification server and filter incoming messages based on the 
verification response. As soon as multiple email recipients report that 
a sender is sending spam, the sender's salt gets changed, and future 
verification requests for messages that used the older salt will fail 
and such messages can be rated as Spam.

I'd like to invite you to read the detailed description of this idea, 
available at
http://kuix.de/spamsalt/

I'm looking forward to your feedback.
Thanks a lot in advance.

Regards,
Kai

---

From: Seth <[email-masked]>
Date: Mon, 27 Sep 2010 21:39:49 -0400 (EDT)

> calculate a hash value and adds that hash value as a new email header. 

Lots of extra work for sender.

Your basic system requires senders to verify that they aren't
spamming.  It gains nothing.

Seth

---

From: der Mouse <[email-masked]>
Date: Tue, 28 Sep 2010 00:12:32 -0400 (EDT)

> The idea is to assign an additional secret key (salt) to each email
> user account.  The email sender uses the salt and the message
> contents to calculate a hash value and adds that hash value as a new
> email header.  [...]

This is just a particular flavour of signing.  Like most signing
schemes, it really does nothing to address spam; to the extent it
addresses anything, it addresses forgery.  (This is not totally
unrelated to addressing spam, but it's very far from the same thing.)

To be at least somewhat fair, the webpage you name below does seem to
indicate you realize this at some level, though your wording ("the
problem that spammers might register a domain for the sole purpose to
send spam messages from email addresses at that domain") indicates you
are unaware of the current extent of the problem - there is no "might"
whatever about that scenario.

See also http://www.rhyolite.com/anti-spam/you-might-be.html#irresistible-bandwagon

> As soon as multiple email recipients report that a sender is sending
> spam, the sender's salt gets changed,

See http://www.rhyolite.com/anti-spam/you-might-be.html#programmer-13
(the wording in the list doesn't quite apply, but I trust it's easy to
see how the same basic idea applies here).

> http://kuix.de/spamsalt/

Further quotes are from there.

> If we had established an environment where spammers are required to
> provide the MX/MSALT infrastructure, required in order to get their
> spam through to user's eyes, because messages without spam salt hash
> values won't be looked at by most users, then, I believe, we would
> have made a huge step forward.

Indeed we would.

I note you give no hint of how we are to get from here to there.

http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5

> It can be easily shown that a domain owner ignores spam reports.  If
> spam email messages still verify correctly, despite many users having
> reported spam messages, then the domain owner doesn't follow the
> rules of the Spam Salt infrastructure.

So what?  Not following the rules mostly doesn't matter, or nobody
would still be listening to the likes of Google and Yahoo.

> Maybe this behaviour might even be sufficient proof to justify to sue
> a domain owner for sending lots of spam?

Good luck.  Let us know when you get anyone shut down based on such a
suit.  You might want to start with a ROKSO spammer; they are already
known, identifiable entities with a clear enough history of spamming to
stand out even among spammers.  Until you find a way to use a legal
system to shut them down, I think anything that depends on a legal
system being a justice system is a non-starter.

You also might want to consider the issues involved in trying to sue,
for example, a Nigerian cybercafe, a Russian spam gang, and the botnet
herder behind whatever botnet dumped the latest spew from a compromised
end-user system in your mailbox.  Under some legal systems you might be
able to get an absentee judgement.  Let us know how well that works to
get the sender shut down.

> Evidence can be easily collected by having some spam fighting
> organization run multiple honeypot email boxes, have a human identify
> a spam message, and send multiple spam reports for every message
> having identical contents, received at each of the honeypot
> mailboxes.

Easily?  Paid for by whom?  Or are you volunteering to do all this?

> This invention has been submitted to the USPTO by my employer Red
> Hat, Inc., a member of the Open Invention Network.

If anyone has to do _anything_ in order to use this idea legally, that
will be a substantial barrier to adoption.

I can understand defensive patenting in the USA.  But, based on their
webpages, that's not what the OIN does.  While I'm outside the USA and
thus don't care about the USPTO, if I were inside it, this would
totally kill any tendency I might have towards using this idea.  If you
really want to advance the state of the art, start by granting
irrevocable, royalty-free, *sublicensable* licenses in perpetuity to a
few entities trusted by the culture - the IETF, Eric Raymond, and
Richard Stallman, to name the first three who come to mind.  If you're
not willing to go that far, I for one consider your idea just another
proprietary (and thus unusable in general) scheme.

I also think your patent is dead if anyone bothers to fight it.
Digital signatures for mail (which this is just a particular flavour
of) have been widely used for decades; if your patent claims are narrow
enough that historical signature schemes don't form prior art, it is
probably trivial to do something functionally equivalent that doesn't
infringe.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Sep 2010 22:23:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Seth
> Sent: Monday, September 27, 2010 6:40 PM
> To: [email-masked]
> Subject: Re: [Asrg] Spam Salt, an email sender authentication mechanism
> 
> user

Is there any chance new people with some ideas could be given some quarter and perhaps some mentoring by those of us who've been around for a while rather than bullied into putting their innovative energies elsewhere?

Really, if the best you can do is crap all over someone's enthusiasm, please just don't reply.  This area needs more R&D calories, not fewer of them.

---

From: der Mouse <[email-masked]>
Date: Tue, 28 Sep 2010 02:41:21 -0400 (EDT)

>>> The idea is [...]
>> [...problems...]
> Is there any chance new people with some ideas could be given some
> quarter and perhaps some mentoring by those of us who've been around
> for a while rather than bullied into putting their innovative
> energies elsewhere?

As someone else who wrote up a few criticisms of SpamSalt, I've got two
points to make here.

One, if you - or anyone else - want to implement spamsalt - or anything
else - and try it out, go for it.  Hard data beats speculation, even
well-informed speculation, every time.  (Well, in this case, if you're
in the USA, you may need a patent license.  I'm no lawyer.)

Two, that said, there is such a thing as avoiding reinventing the
square wheel for the 83rd time only to discover, for the 83rd time,
that it doesn't roll at all well.

Which is a better match for this situation?  I think #2 is.  But I
could be wrong.  It's happened often enough before and will again.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Sep 2010 00:08:41 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of der Mouse
> Sent: Monday, September 27, 2010 11:41 PM
> To: Anti-Spam Research Group - IRTF

One can deliver such sentiments without being plainly rude about it, don't you think?

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Tue, 28 Sep 2010 10:55:58 +0200

It's some sort of message signing schema.

As there are other quite good signing schemas around us, a discussion could be 
around comparing schemas. E.g., how do you place SpamSalt WRT DKIM ? What's the 
differences ? Why SpamSalt could be better or worse than DKIM ?

JM

Kai Engert wrote:
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:[email-masked]

---

From: Kai Engert <[email-masked]>
Date: Tue, 28 Sep 2010 18:36:42 +0200

Dear der Mouse,

thank you very much for your detailed and valuable feedback.

You said:
> ... This is just a particular flavour of signing.  Like most signing

 From my point of view "just a flavour of signing" is an understatement. 
In addition to being a flavour of signing, it's also a proposal how a 
verification infrastructure, revocation infrastructure, spam reporting 
infrastructure could work, which could give fine grained control at the 
level of individual mailboxes, without requiring end users to carry the 
same burden usually associated with using public key cryptography on one 
more multiple computers.

You confirm that address forgery is not unrelated to spam.

Wouldn't it help to introduce an universal mechanism that makes forgery 
difficult, in order to make sender addresses in emails more reliable? As 
of today, I can't see anti-forgery mechanisms being used in most emails 
I receive.

I presume that each of the previously proposed flavours of signing might 
have had properties that made them difficult to be deployed universally.

The key part of my proposal is to introcuce an authentication mechanism, 
an anti-forgery mechanism, and I hope I came up with a scheme that 
doesn't require immediate intrusive migration efforts, but can grow over 
time.

If everyone agreed that anti-forgery can be a reasonable step towards an 
infrastructure with less spam, could we work to find a reasonable 
technical architecture (a variation of SpamSalt or something else), and 
propose that it becomes generally adopted?

> see how the same basic idea applies here).

Yes, signatures, keys and revocation are not new ideas. If a FUSSP 
exists, it probably can't be created without reusing existing concepts.

I don't claim that my idea is a self-contained FUSSP, but I understand 
it's the hope of this research group to create one, and it's my hope 
that my ideas can contribute to building it.

>> have made a huge step forward.

I'm glad you agree.

> http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5

My idealistic hope is:
(a) some email anti-forgery mechanism and it's accompanying 
infrastructure additions are agreed on to be reasonable
(b) it gets standardized
(c) it gets implemented
(d) applications start to add anti-forgery signatures to emails
(e) after a while (between 1 and x years) most big players have deployed 
it in parallel to existing infrastructure
(f) nearly all desired email messages are created using the anti-forgery 
mechanism
(g) email receiving applications sort messages that lack the 
anti-forgery properties into a "dubious" folder

At this point spammers would have to participate in the anti-forgery 
game, in order to avoid that all their spam gets filed into the 
"dubious" folder.

> Easily?  Paid for by whom?  Or are you volunteering to do all this?

Thanks for clarifying that domains designated for sending spam are a 
major part of the spam problem. I honestly say that I currently can't 
present a solution, and SpamSalt probably can't help with that side of 
the problem, besides allowing that blacklists and whitelist could be 
build on top of reliablly knowing sender addresses and sender domains.

You successfully countered my quickly written thoughts related to that 
part of the problem, which I had written yesterday, after receiving the 
first feedback to the SpamSalt proposal.

I may come back to your arguments at a later time, but for now I'd like 
to focus on the anti-forgery aspects.

> webpages, that's not what the OIN does.

I wonder why you draw this conclusion. In my understanding the OIN is a 
defensive system.

Quoting from http://xml.coverpages.org/OIN-Announce.html :

"Patents owned by Open Invention Network will be available on a 
royalty-free basis to any company, institution or individual that agrees 
not to assert its patents against the Linux operating system or certain 
Linux-related applications."

See also
http://en.wikipedia.org/wiki/Open_Invention_Network#Views_on_Open_Invention_Network

> While I'm outside the USA and

I am not a lawyer, but based on my understanding (which could be wrong) 
of the above quote, your request might already be fulfilled, for anyone 
playing peacefully with the Linux community.

> probably trivial to do something functionally equivalent that doesn't

I'd prefer to not touch this topic too much. If if weren't for a 
defensive pool, I wouldn't have gone the path of applying for a software 
patent.

Thanks for listening.
Regards,
Kai

---

From: Steve Atkins <[email-masked]>
Date: Tue, 28 Sep 2010 09:49:51 -0700

On Sep 27, 2010, at 6:15 PM, Kai Engert wrote:

> The idea is to assign an additional secret key (salt) to each email user account. The email sender uses the salt and the message contents to calculate a hash value and adds that hash value as a new email header. For each email domain a verification server is registered in the DNS that can be contacted to verify the authenticity of messages that contain a hash value in the email headers. An email recipient can contact a verification server and filter incoming messages based on the verification response. As soon as multiple email recipients report that a sender is sending spam, the sender's salt gets changed, and future verification requests for messages that used the older salt will fail and such messages can be rated as Spam.
> 
> I'd like to invite you to read the detailed description of this idea, available at
> http://kuix.de/spamsalt/
> 

There are some obvious flaws with this from your brief description. It's possible that you've addressed them in your full document.

But if you want people to look at it in more detail you might want to expand on the patent and intellectual property rights you're claiming, and the terms under which the patent will be licensed to implementors (it's possible that I should be able to infer that from the mention of openinventionnetwork - but from a quick read of their website, it appears that they don't offer patent licenses to anyone other than Linux developers, so I'm presuming I'm reading that wrong).

Cheers,
  Steve

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 28 Sep 2010 17:50:52 +0100

> propose that it becomes generally adopted?

It's a step towards an infrastructure in which domain and email based based 
reputation databases can be managed. It reduces the opportunity to poison 
such reputation databases, for example.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 28 Sep 2010 10:13:40 -0700

On 9/27/2010 10:23 PM, Murray S. Kucherawy wrote:
> Is there any chance new people with some ideas could be given some quarter
> and perhaps some mentoring by those of us who've been around for a while
> rather than bullied into putting their innovative energies elsewhere?

Stray question:  if someone showed up in a senior research environment for an 
activity that has a long history and then said that they had created a mechanism 
that greatly reduced computational overhead for large-scale data activity and it 
turned out merely to be a basic hashing algorithm, would you be equally 
concerned that they be treated delicately?

Stated differently: Are there reasonable expectations that should apply to 
participants, in terms of their doing prior due diligence?  If they fail to do 
it, is the group prohibited from expressing unhappiness at having its time wasted?

Calling someone an asshole crosses a line, pretty much no matter the content or 
the people.

Telling someone that they need to do their homework before presenting a 
'solution' strikes me as merely appropriate.  Telling them this in a way that 
indicates pique at their having been immature in their effort might, itself, be 
immature, but really, it is little more than scolding a wayward child.

IMO.

d/

ps.  Over the course of my career and especially in the early years, I've been 
that wayward -- ie, arrogant and ignorant -- child many times and while being 
scolded stung, it was deserved.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Kai Engert <[email-masked]>
Date: Tue, 28 Sep 2010 19:18:33 +0200

> But if you want people to look at it in more detail you might want to expand on the patent and intellectual property rights you're claiming, and the terms under which the patent will be licensed to…

I can't speak for my employer nor for the OIN, other than quoting what's 
publicly available.

Quoting from http://www.openinventionnetwork.com/about_faq.php :

"Open Invention Network’s mission is to further software innovation by 
acquiring patents to be used for cross-licensing purposes to defend the 
Linux System - making them available on a royalty-free basis."

"We are making the patents available royalty-free, and all we ask in 
return is that the licensee agrees not to assert its patents against Linux."

See also

Regards,
Kai

---

From: John Levine <[email-masked]>
Date: 28 Sep 2010 17:37:45 -0000

>I'd like to present you my anti-spam idea which I call Spam Salt.

As others have noted, this proposal appears to use a variety of well
known techniques, some of which work better than others.

The ASRG wiki includes a taxonomy of anti-spam techniques, both ones
that work and ones that don't.  Since people reinvent anti-spam
techniques all the time, the idea is to have a place where they can
look quickly to see if their particular wheel has been invented
before, and if so, how well it rolls.

http://wiki.asrg.sp.am/wiki/Taxonomy_of_anti-spam_techniques

POINTED COMMENT: The wiki is chonically lanquishing in a half
completed state.  If everyone who wrote to point out all the known
issues with spam salt would get a wiki password (just ask) and spend
half an hour writing or updating some of the stub entries, the wiki
would be a lot more complete and useful.

R's,
John, ASRG cat herder and jello nailer

---

From: Kai Engert <[email-masked]>
Date: Tue, 28 Sep 2010 19:39:01 +0200

On 28.09.2010 10:55, Jose-Marcio Martins da Cruz wrote:
> As there are other quite good signing schemas around us, a discussion 
> could be around comparing schemas. E.g., how do you place SpamSalt WRT 
> DKIM ? What's the differences ? Why SpamSalt could be better or worse 
> than DKIM ?

At the time I came up with the SpamSalt proposal, I wasn't aware of DKIM.

Some differences between DKIM and SpamSalt:

(a) SpamSalt is not limited to the period of time that a message is in 
transit.

(b) DKIM adds a domain-level signature, SpamSalt proposes signatures 
that are associated to individual mailboxes.

(c) DKIM doesn't seem to provide a revocation mechanism for emails that 
have been produced while an individual user's credentials were 
compromised (e.g. because of a computer virus). With SpamSalt the 
verification can be delayed or repeated until a recipient first looks at 
an email. By that time, after the transit but before reading, it may 
have become known that the message originates from a spam account or a 
compromised account and can be automatically treated as such.

(d) SpamSalt doesn't require that existing transport agent software gets 
changed or upgraded, thus allowing for less intrusive migration. It's 
sufficient to install complementary server applications and upgrade 
client applications.

(e) SpamSalt doesn't help against sender domains that exist for the sole 
purpose of sending spam.

(f) SpamSalt and DKIM don't seem to be in conflict, but rather be able 
to complement one another.

Kai

---

From: mathew <[email-masked]>
Date: Tue, 28 Sep 2010 13:14:07 -0500

On Tue, Sep 28, 2010 at 11:36, Kai Engert <[email-masked]> wrote:
> difficult, in order to make sender addresses in emails more reliable?

We already have S/MIME, which almost every common e-mail client supports (1).

Nobody (2) uses it. Hence I suspect that validating sender identity is
less valuable to people than you think. And I don't think that the
popularity of webmail clients which fail to support it is the reason;
rather, I think the reason that webmail clients don't support it is
that nobody cares.

I mean, even my bank doesn't care.

> have had properties that made them difficult to be deployed universally.

For Apple Mail at least, once you have your certificate file you
double-click it and everything gets configured automatically; then you
can just check a box when composing e-mail in order to sign it. The
recipient doesn't have to do anything; the message will show up in
Thunderbird, Mail, Notes etc. as correctly signed.

So the biggest difficulty of S/MIME is that you need to go to a web
site and verify your ID somehow in order to get a certificate file
that you can feed to your e-mail client. That's pretty much a
fundamental issue independent of the specific technical
implementation. If you've thought of a way to avoid that issue, I will
be astounded.

There are some smaller difficulties, like buggy IETF mailing list
software that breaks the signatures, but those would probably get
worked out pretty quickly if people cared enough to use S/MIME...

mathew
[ (1) Including Microsoft Outlook, Microsoft Exchange, Mozilla
Thunderbird, Apple
  Mail, BlackBerry phones, etc etc.
  (2) Well, obviously a few people do. I've used it. But 99% of people don't. ]
-- 
<URL:http://www.pobox.com/~meta/>

---

From: der Mouse <[email-masked]>
Date: Tue, 28 Sep 2010 15:31:07 -0400 (EDT)

> Wouldn't it help to introduce an universal mechanism that makes
> forgery difficult, in order to make sender addresses in emails more
> reliable?

Yes.

I don't think SpamSalt is it.  It assumes all receivers have direct
Internet connectivity.  It fails to address the elephant-in-the-room of
botnets.  As far as I can see it does not provide anything not already
provided by schemes like DKIM.  It is, or at least is likely to become,
encumbered.

> As of today, I can't see anti-forgery mechanisms being used in most
> emails I receive.

Well, I can't speak to your mail flow.  But I already have a perfectly
good anti-forgery mechanism available in the form of PGP (the line of
hex in my signature is my PGP key fingerprint) but I don't see enough
value in it to bother using it, even as low as the cost is.

> I presume that each of the previously proposed flavours of signing
> might have had properties that made them difficult to be deployed
> universally.

So does yours.  It requires changes to all recipient mailservers and/or
user agents (to check the signatures), and all sender mailservers
and/or user agents (to generate the signatures), just for starters.

> The key part of my proposal is to introcuce an authentication
> mechanism, an anti-forgery mechanism, and I hope I came up with a
> scheme that doesn't require immediate intrusive migration efforts,
> but can grow over time.

Yes, in that you succeeded.  There's the quadratic adoption effect, but
that's inevitable, and you did indeed come up with something that has
no costs beyond those inherent in implementation for early adopters.

As for the whole patent issue, this is mostly an anti-spam list, so
I'll confine myself to noting that the OIN is defensive for nobody but
Linux, as far as I can tell, and lots of people have no interest in
having anything to do with Linux.  If I have to run Linux to be safe
from your patent (which as far as I can tell I would, and maybe even
that wouldn't be enough), I'll just not use it at all.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Tue, 28 Sep 2010 15:43:31 -0400 (EDT)

> would be a lot more complete and useful.

POINTED COMMENT: If you didn't require people to use some God-damned
Web interface[%] to update it, you might get more content.

[%] `Pardon my French', but, really, that is already the toned-down
    version of how I feel about the current "oh, a Web interface is all
    anyone ever needs" zeitgeist.

(What alternatives?  A cvs/svn/git/etc repo.  A mailserver that will
mail out files on request and accept patches back.  An FTP server
jiggered to turn uploads into new revs.  An ssh server that drops
clients into a severely restricted shell permitting little but editing.
Doubtless a bunch more I don't think of because I'm an aggressively
old-school old fart who wants content unfettered by imposed
presentation, and probably more I could think of if I put more than
thirty seconds' thought into it.)

					Mouse

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 28 Sep 2010 15:54:55 -0400

> thirty seconds' thought into it.)

LOL!

-- 
Jeff Macdonald
A programmer, who realized a long time ago that he was a minority.
A programmer, who realized that his favourite tool set might not be
what others had in mind.

Ayer, MA

---

From: Kai Engert <[email-masked]>
Date: Tue, 28 Sep 2010 22:42:15 +0200

> that wouldn't be enough), I'll just not use it at all.

My understanding is, as long as you are peaceful and don't sue anyone 
else, you're all set.
You don't need to know that Linux exists, even.

(That's my understanding of the OIN, but I'd like to add the usual 
disclaimer that I speak for myself and I'm not a lawyer, so my 
understanding might be wrong.)

Kai

---

From: mathew <[email-masked]>
Date: Tue, 28 Sep 2010 19:02:48 -0500

On Tue, Sep 28, 2010 at 14:43, der Mouse <[email-masked]> wrote:
>POINTED COMMENT: If you didn't require people to use some >God-damned Web interface[%] to update it, you might get
>more content.

It wasn't the web interface that put me off, it was the fact that it
would have meant registering for yet another username/password
combination, which I would then have to record in my database, look up
again when going back to edit, and so on.

OpenID is an idea whose time came quite a long while ago.

mathew

---

From: Brendan Hide <[email-masked]>
Date: Wed, 29 Sep 2010 04:15:23 +0200

This has stirred the nest a bit. lol.

I had a similar idea a while back, which I called Mail Remote 
Authentication Protocol. If anyone is interested, email me and I'll dig 
up the specs for your perusal/lulz. The ultimate goal in my idea was to 
automate everything - put a nice "this is spam" button in every email 
client so spam-recipients don't have to do much to ensure spammers would 
be stopped. ISPs would have automated spam-reporting to shut down rogue 
or "bad-password" email accounts/domains rather than relying on their 
staff having to monitor an abuse@ email account/queue.

Though it is nothing new, the idea is theoretically sound. You did well 
to come to ASRG, in spite of the majority of the responses being 
discouraging ones. Let us at least, gently, push you into the right 
frame of mind. The spam problem is easily solvable on a technical level. 
The spam problem is NOT easily solvable on a "political" level.

The rub is simple in 2 main ways:
EVERY email client needs to support the feature natively
EVERY MX server needs to support the feature natively
EVERY domain's DNS needs to support the feature natively
EVERY relay server needs to support the feature natively
EVERYONE must stop using the "old-style" SMTP

I believe the above are the main reasons why all other FUSSPs have 
failed, though the lists given in the other responses list many more 
reasons.

When (if?) I get around to actually doing something about my own idea, 
I'm more-or-less going to have to implement it in all the above respects 
and publish the idea as public domain. I'd probably have to do it 
anonymously so that nobody can call me an idiot for trying. xD

-- 
__________
Brendan Hide
Web Africa - Internet Business Solutions
http://www.webafrica.co.za/?AFF1E97

---

From: John Levine <[email-masked]>
Date: 29 Sep 2010 03:50:13 -0000

>Web interface[%] to update it, you might get more content.

Uh, Mouse, that's just you.  It's the same gd web interface as Wikipedia
and about a million other wiki sites.

R's,
John

---

From: John Levine <[email-masked]>
Date: 29 Sep 2010 03:51:31 -0000

In article <AANLkTinEZAv52MT-pp73x3=[email-masked]> you write:
>>POINTED COMMENT: If you didn't require people to use some >God-damned

Feel free to ask me to reuse your favorite low-security ID.  You can
change the password to your fave low-security password, too.

>OpenID is an idea whose time came quite a long while ago.

I'm not opposed to it.  Is there a plugin for mediawiki?

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 29 Sep 2010 00:04:23 -0400

>sufficient to install complementary server applications and upgrade 

Both S/MIME and PGP do all that, and have for over a decade.

You should try them out. -- S/MIME support is built in to your MUA,
and there's a plug-in for PGP.  To get you started, this message has an 
S/MIME signature although the buggy code in T'bird may not recognize it.

If you want people to take your proposals seriously, you need to do
your homework, see what people have done before, and in cases like
these, why nobody uses them.  (look for "key management")

R's,
John

---

From: mathew <[email-masked]>
Date: Wed, 29 Sep 2010 07:12:48 -0500

> I'm not opposed to it.  Is there a plugin for mediawiki?

Looks like there is:

http://www.mediawiki.org/wiki/Extension:OpenID

mathew

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 29 Sep 2010 08:59:16 -0400

I'm gonna go with Dave on this one, particularly including:

On Tue, Sep 28, 2010 at 10:13:40AM -0700, Dave CROCKER wrote:
> ps.  Over the course of my career and especially in the early years,
> I've been that wayward -- ie, arrogant and ignorant -- child many
> times and while being scolded stung, it was deserved.

which has happened to me as well.  I would rather have my
mistakes pointed out -- even if they're embarrassing, and even
if the means of doing so pisses me off -- than remain wrong.
I'll get over it, move on, and hopefully progress to making
better mistakes.

Now as to der Mouse's tone: I found it quite restrained.  Let's
keep in mind here that our mutual enemy are spammers, who rank among
the most vile filth on the planet.  A little sporadic flack on a
mailing list is *nothing* compared to what they dish out on a
routine basis.  So I would suggest that anyone who can't handle
that with ease may wish to reconsider their decision to get
involved in this fight.  (der Mouse and I, on our worst possible
days, and working in tandem, couldn't even come close to the
level of vicious abuse that spammers manage before breakfast.)

Now on to the substance (more or less, of the latest two proposals to show
up here, one of which is discussed in this thread).  I think any anti-spam
scheme which relies on end users is dead on arrival.  Users are stupid,
users are lazy, users are careless, users have spent the last several
decades conclusively proving that they cannot tell spam from non-spam,
phish from non-phish, scam from non-scam.  Moreover, the single most
deleterious impact of spam is consumption of end-user time, so even
if everything in the previous sentence weren't true, and the teeming
masses of users were intelligent, diligent human classification engines,
enlisting them to perform that task will chew up the very same precious
resource that spam does: their time.

In general, any proposed anti-spam scheme must account for a number
of unfortunate realities; offhand, I'd list (and I'm well aware that
this is woefully incomplete):

	- users are wholly unreliable
	- horrible mail clients exist
	- users will use those horrible mail clients no matter what
	- nobody will change their SMTP, DNS or HTTP server software
	- thus fundamental changes to those protocols won't fly
	- spammers have an (essentially) inexhaustible supply of domains
	- spammers have an (essentially) inexhaustible supply of IP addresses
	- spammers have an (essentially) inexhaustible supply of zombies
	- spammers have an (essentially) inexhaustible supply of email addresses
	- no trustable central authority exists or will exist
	- no meaningful legal action by anyone, anywhere, is possible
	- spammers will not just sit still and watch
	- spammers will very likely try to co-opt any mechanism
	- spammers are not all as stupid as we'd like to think

(And yes, I should probably buck up and edit this into the wiki.)

---rsk

---

From: der Mouse <[email-masked]>
Date: Wed, 29 Sep 2010 09:40:18 -0400 (EDT)

> Uh, Mouse, that's just you.  It's the same gd web interface as
> Wikipedia and about a million other wiki sites.

Right.  And anyone who nags me about putting stuff into any of those
million other wikis gets pretty much the same response.  I've long
since lost track of the number of things I've found in wikipedia that
need fixing but which I haven't fixed because they don't support a sane
interface for making edits.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Andreas Saurwein Franci Gonçalves <[email-masked]>
Date: Wed, 29 Sep 2010 10:55:29 -0300

> interface for making edits.

Well, one day even YOU will have to accept that you must install the latest
XZ OS Version 17.09, download a 270mb video driver, get the 500 mb package
of webcam software, which will allow you finally to speak into your cam, so
it can read from your lips, saves this to a cloud service from where you can
automatically send it to the spell checker which can, for your convenience
attach an translation of your misspellings in Hindu (because it knows from
your GPS enabled netbook where you sent it from, that you've been flying
over India) and finally save it as a text file on your disk so you can
submit it to the wiki of your choice.

---

From: mathew <[email-masked]>
Date: Wed, 29 Sep 2010 08:56:37 -0500

On Wed, Sep 29, 2010 at 08:40, der Mouse <[email-masked]> wrote:
> And anyone who nags me about putting stuff into any of those

http://vimperator.org/vimperator
https://chrome.google.com/extensions/detail/godjoomfiimiddapohpmfklhgmbfffjj

Or hell, use Lynx and set your preferred editor.

mathew
[ i.e. get a grip ]

---

From: mathew <[email-masked]>
Date: Wed, 29 Sep 2010 09:00:50 -0500

On Wed, Sep 29, 2010 at 07:59, Rich Kulawiec <[email-masked]> wrote:
> I think any anti-spam
> phish from non-phish, scam from non-scam.

I would modify this slightly.

Any anti-spam scheme which relies on reasonable behavior by *all* end
users in order to be effective for *any* end users is dead on arrival.

However, an anti-spam scheme which relies on the end user in order to
provide spam protection *for that end user* can still be quite viable.

To put it another way: If someone could come up with an anti-spam
system that worked, but only for people who have (say) skills
equivalent to a CS degree, that might not be of any use to 90% of
people, but it'd work just fine for me.

mathew

---

From: Kai Engert <[email-masked]>
Date: Wed, 29 Sep 2010 17:05:13 +0200

> Web interface[%] to update it, you might get more content.

You could compose the content for the wiki page using your email 
software, and then mail it to someone who is willing to use the web 
interface, who then copy and pastes it.

Kai

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 29 Sep 2010 11:13:59 -0400 (EDT)

> people, but it'd work just fine for me.

In economics this is called "incentive compatibility". That is, an action 
can be depended upon only if it benefits the person asked to perform the 
action. Most naive anti-spam measures lack incentive compatibility, and 
depend on an external power (known to economists as a "dictator") to 
enforce good behavior. Since there is no such dictator on the internet, 
anti-spam techniques that succeed sufficiently to become widespread are 
incentive compatible. These include DNSBLs, gray listing, and content 
analysis.

The analysis of who benefits can be subtle. ISPs may block port 25, which 
at first glance only benefits customers of other ISPs. However, it reduces 
abuse desk costs so it is incentive compatible. It doesn't matter that the 
benefit to others is greater than the benefit to the ISP. It only matters 
that the benefit to the ISP is greater than the cost to the ISP.

Daniel Feenberg

---

From: Seth <[email-masked]>
Date: Wed, 29 Sep 2010 11:16:20 -0400 (EDT)

mathew <[email-masked]> wrote:

> Any anti-spam scheme which relies on reasonable behavior by *all*
> end users

Fails, because most end users are clueless, and many of the rest are
spammer sockpuppets gaming the system.

> However, an anti-spam scheme which relies on the end user in order
> to provide spam protection *for that end user* can still be quite
> viable.

E.g. Bayes.

> people, but it'd work just fine for me.

And you'd have to code it yourself, because the market is too small.

What are the requirements to use data from one user to help others
avoid spam?

Seth

---

From: der Mouse <[email-masked]>
Date: Wed, 29 Sep 2010 11:31:34 -0400 (EDT)

>> I'll confine myself to noting that the OIN is defensive for nobody
>> but Linux, as far as I can tell, [...]
> else, you're all set.  You don't need to know that Linux exists,
> even.

That's not the impression the OIN webpages gave me.  Their FAQ, for
example, says

   We are making the patents available royalty-free, and all we ask in
   return is that the licensee agrees not to assert its patents against
   Linux.

The license agreement at
http://www.openinventionnetwork.com/pat_license_agreement.php has
Linux-specific language and as far as I can see does not give any
protection to those not using, working with, or at least somehow
involved in Linux.

Perhaps I just missed something.

Not that I think it really matters as far as spamsalt is concerned;
having to do _anything_ in order to legally use the technique is, I
expect, going to be a substantial barrier to adoption.

If I cared about USA patents, it would certainly kill it for me.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: mathew <[email-masked]>
Date: Wed, 29 Sep 2010 11:04:22 -0500

> spammer sockpuppets gaming the system.

...which is what everyone already said, including me.

> And you'd have to code it yourself, because the market is too small.

Did you miss the free software revolution of the last 20 years? There
are thousands of free software projects that require CS knowledge to
be useful.

mathew

---

From: John Levine <[email-masked]>
Date: 29 Sep 2010 17:37:21 -0000

>http://www.mediawiki.org/wiki/Extension:OpenID

Well, I installed the prerequisite library, and it appears
not to work.  Sigh.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Sep 2010 20:31:38 +0200

On 28/Sep/10 19:39, Kai Engert wrote:
>> As there are other quite good signing schemas around us, a
>> discussion could be around comparing schemas. E.g., how do you place
>> SpamSalt WRT DKIM ? What's the differences ? Why SpamSalt could be
>> better or worse than DKIM ?
>

They're strikingly similar, including patent encumbrance.

> (a) SpamSalt is not limited to the period of time that a message is in

Irrelevant, nobody cares much about yesterday's spam.  The outcome of 
checking on arrival (Authentication-Results) is supposed to be 
recorded in its own header field.

> that are associated to individual mailboxes.

DKIM's approach is better, after establishing that users are too lazy 
to use PGP or S/MIME.

> (c) DKIM doesn't seem to provide a revocation mechanism for emails
> that have been produced while an individual user's credentials were
> verification can be delayed or repeated until a recipient first looks
> at an email. By that time, after the transit but before reading, it
> may have become known that the message originates from a spam account
> or a compromised account and can be automatically treated as such.

Good point.  However, what do you mean by "looking at an email"?  Most 
users are quick enough with the "del" button even without assistance...

DKIM allows senders to quickly change keys, for limiting replays.

Since SpamSalt only signs a few fields, it seems it would be more 
vulnerable to replay attacks.

> (d) SpamSalt doesn't require that existing transport agent software
> gets changed or upgraded, thus allowing for less intrusive migration.
> It's sufficient to install complementary server applications and
> upgrade client applications.

Neither does DKIM.

> (e) SpamSalt doesn't help against sender domains that exist for the
> sole purpose of sending spam.

Neither does DKIM.

> to complement one another.

If DKIM worked reliably, SpamSalt would not be needed, though.

My comments above are skewed in favor of DKIM, because I've already 
installed the required complementary software :-)  Given that you 
nearly reinvented it, you should be very much interested in DKIM; 
consider that it has already gathered some years of field testing.

---

From: Bill Cole <[email-masked]>
Date: Thu, 30 Sep 2010 12:45:22 -0400

mathew wrote, On 9/29/10 12:04 PM:
 > On Wed, Sep 29, 2010 at 10:16, Seth<[email-masked]>  wrote:
 >> mathew<[email-masked]>  wrote:
[...]
 > are thousands of free software projects that require CS knowledge to

Indeed. There are even some of those that don't demand the ability to debug 
CS101-quality code to successfully build and run as intended, and in some 
cases there are actually competent coders who have done maintenance in this 
century.

Less cynically: I think Seth's point is more quantitative and subtle. A 
mechanism that only provides any benefit at all for the most CS-savvy 10% or 
requires BSCS equivalent skills (which is actually on the other side of 
0.1%) to get full benefit from has a sparse potential audience with such 
diversity in specific needs and skills that no specific implementation can 
satisfy any meaningful subset of them. For example, I recently went looking 
for an audio metadata tool that could manipulate mp3 files whose unusual 
tags demonstrate a fuzzy area of the ID3 specs. The open source, beer-free, 
and demo-able tools can't do the tricks I was looking for, and the open 
source tools seemed to be the products of fledgling coders who outgrew their 
obsession with music files some years ago. I ended up handling my own task 
with some rather clumsy shell work using standard Unix tools. I *could* 
recover all of that from my shell history and pretty it up for a real script 
or even translate it into Perl or C and release it, but I am unlikely ever 
to bother.

In other words: the spam control needs/whims of people who *can* write 
enough code to satisfy them are diverse enough that where they go beyond the 
needs of the general population they don't overlap enough for there to be a 
generalized solution for a significant fraction of the highly-skilled 
minority. See SpamAssassin for a demo of that. Also relevant to this is the 
fact that many of us who have been in the spam war for many years have 
essentially already won it for ourselves with highly individualized 
defenses, so many of the people who could be early adopters and improvers of 
novel approaches lack motivation for those roles.