Paper on Path and Cryptographic Authentication Technologies

Hi,

I've finished and now making available full version of the paper on
Email Security with Path and Cryptographic Authentication Methods -
  http://www.metasignatures.org/path_and_cryptographic_authentication.htm

Printable PDF version of the paper (21 pages) is also available -
  http://www.metasignatures.org/Path_And_Cryptographic_Authentication.pdf

About 3/4 of the paper is an overview of the various email anti-spoofing
technology proposals that were/are discussed at MARID and MASS. Even though 
many people already know about these topics I think it'll be worth it for you 
to read (or at least glance through) anyway, parts on the overview
and how its structured are unique as it has number of tables and focuses
on how the technologies protect various email identities and these interactions 
and differences. There are also chapters on Accreditation and Reputation 
(including section on spamhaus .mail) and "authorization vs
authenticity" question that has been raised by some when criticizing
path authentication technologies - I explain that is really problem for
both path and cryptographic proposals and its tied to question on if
mail servers are "enforcing submission rights" at mail origin.

The reminder 1/4 (chapter 6) of the paper is my proposal on how different path 
and cryptographic technologies can compliment each other. In particular I 
propose that cryptographic mail signature when added by
MTA include "hostname" of the system adding the signature and this be 
considered an identity and be verifiable as being correct host that added the 
signature. After that path authentication technology can use verified
hostname as the source for say SPF authorization (in place of where
SMTP Client IP would normally be used), this allows to effectively
bypass "forwarding problem" as SPF would now be able to directly
verify if original source mail server that mail came though (before
forwarding) is on list of mail systems authorized to be source of
messages with given email address in MAILFROM or some other identity. Having 
bypassed forwarding problem this makes it possible to actually reject safely 
using SPF, although it requires number of additional policy records, including 
info that all source systems are adding signatures.

------------------------------------------------------------------------
IPR Disclosure: Algorithm I described above for doing path authorization
after forwarding based on hostname from crypto signatures is patent
pending. License is expected to be compatible with GPL programs.
-----------------------------------------------------------------------

There is a public comment section open on website also where you can post your 
comments on the paper and its content and I'll gladly take
those on the mail list or privately.

-- 
William Leibzon
Elan Networks
[email protected]