Paper on Path and Cryptographic Authentication Technologies

[william(at)elan.net]

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.