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
william(_at_)elan(_dot_)net