Ned
what is the identity that is authenticated?
nfmc> As far as I can tell there isn't one. These schemes specify a particular
form
nfmc> of authorization, not authentication.
If there is no authentication, then the identities can be spoofed. In
fact all of these mechanisms are intended to prevent spoofing. That
means they have a basis for claiming that the identity being asserted is
authentic(ated).
These mechanisms at a minimum involve an identity and an authentication.
And then, yes, they assert an authorization.
And any rate, I had intended the focus of my note to be about identities
and their relationships to entities and processes.
what is its relationship to the message and/or the transmission of the
message?
nfmc> The formal semantics haven't been a major concern, nor is it clear they
should
nfmc> be. (I worry about the many and varied ratholes that litter the formal
nfmc> semantics landscape.) These proposals are all about operational semantics.
This was not intended to go down the formal logic/computer science path.
Besides being a rathole, I don't know anything about them and try to
stay away from them. So, operational semantics is fine.
My point is that these discussions and specifications need to have more
precise and consistent use of terms than is so far typical.
Perhaps the most problematic term is "sender". Often it is not clear
whether this means the client MTA for the current hop or the first hop,
or the author, or the entity that originally posted the message to the
first MTA, or what.
So let's develop some very careful definitions and use them
consistently. Let's identify particular types of identities, their
relationships to a message and to particular MTAs, and the "meaning" of
the authorization that is being assigned to the identities.
By way of offering some examples about difficulties in current
discussions -- and these are really intended only as examples, so folks
should not get worried about whether these are the latest drafts:
draft-irtf-asrg-lmap-discussion-01.txt
1.1. Summary of the Protocols
The data published by a domain includes statements as to which
IP's are permitted to originate mail from the domain in SMTP
EHLO/HELO and MAIL FROM.
The word "originate" historically refers to the initial act of passing
from an authoring MUA into the first MTA. It notably does not refer to
MTA-MTA exchanges. So it says nothing about peer MTA authorization. In
any event I'm not certain all that is meant in this specification. There
also is the implication that the domain in the EHLO and the Mail From
must be the same. Is this new constraint on SMTP really intended?
draft-mengwong-spf-02.9.54.txt
Abstract
SMTP receivers may use
these descriptions to authenticate mail and better apply local
policy.
Sorry, but I felt compelled to note that some proposals do, in fact,
purport to do authentication.
1.1 Designated Senders
SPF defines mechanisms for domain owners to designate legitimate
outbound mail servers. SMTP receivers may query sender domains using
these mechanisms, and decide the validity of a given SMTP transaction
while that transaction is ongoing, even before any message data is
Simultaneously referring to "outbound mail servers" and to peer
interactions (deciding the validity of a current transaction), sound
like conflicting capabilities. Perhaps they are not, but this is the
sort of reference that needs to be much clearer, if we are going to make
careful decisions about the real behavior and impact of a specification.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>