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

 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
> 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.)
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 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).
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.
> > 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'm glad you agree.

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

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg