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 with fair
amount on SPF and proposals on new identity/scopes for it. 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.
Lastly I'd like to thank Lou Katz (participant from SPF Community) for
his private review and help in fixing some errors and his many suggestions
that helped to greatly improve the paper.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/