On Jul 18, 2005, at 7:09 PM, Murray S. Kucherawy wrote:
On Sat, 16 Jul 2005, Douglas Otis wrote:
result = "authen" / "authen-author" / "author" / "not-author" /
"non-compliant" / "unknown" /"temperror" / "permerror"
; results of an attempt to validate an identity
Without a new assertion added where the MTA assures exclusive use
of a
domain, path registration validation should return "author[ized]"
rather
than "authen[ticated]" as currently implied by "pass" according to
this
draft. This greater specificity would also allow greater utility
with
other mechanisms, such as DKIM or CSV.
While I'm not necessarily adverse to such a change, I would also
suggest that elsewhere in the header, the method whose result is
being relayed is identified. A "fail" for DKIM (authentication)
would be thus disambiguated from a "fail" for SPF (authorization),
for example. The cross-product of the method and the result can
reveal the specificity you'd like.
Even for something like SPF, 'pass' should be considered 'authorized'
unless an explicit assurance of domain exclusivity has been made.
Mapping to SPF scripting terms makes it difficult to use these
nebulous terms elsewhere. SPF terms define three shades of failure,
while not communicating what basic function has been attempted. As
example, with latest SPF draft, there is an expectation that a signed
bounce-address can be evaluated with an 'exists' macro as a solution
for forwarding. Is this a different function from finding that the
bounce-address references the address of the server? What if there
were some explicit assurance of domain exclusivity at the server?
A level of clarity can be achieved by defining what function is
performed.
Authorization,
Authentication,
Policy compliance,
In the draft:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt
Rather than attempting to distill (muddle) these separate functions
into a single result, I suggested these could be expressed
independently to provide greater clarity. Forgive the assumption CSV
could supplant DKIM policy, as then CSV is able to provide valuable
resource protections for DKIM as well.
-----
Any previous Border-Validation header introduced at the
Internet facing MTA should be stripped and may be viewed as an
attempt to forge this information and cause the message to be
rejected. This header has the following format:
header := "Border-Validation" ":" domain"["address-literal"]"
1*LWSP *(";" method "=" result)
domain := Domain as defined in [RFC2821]
address-literal := Address literal as defined in [RFC2821]
method := "CSV" | "DK" | "RDNS" | "A-RR" | "DKIM"
result := authen "/" author "/" policy "/" time "/" hash
authen := "VALID" | "INVALID" | "UNKNOWN" | "ERROR"
author := "VERIFIED" | "MISSING" | "UNKNOWN" | "ERROR"
policy := hexadecimal presentation of the CSV-CSA port field.
time := time value defined by recipient
hash := defined by recipient to cover domain, address-literal,
method, and result.
LWSP := 0x20 / 0x09
-----
Consider these aspects separately, rather than attempting to merge
them together. Much of the concern I have with respect to reputation
accrual is created when being fuzzy about what function is being
performed. In my view, reputation accrual requires authentication of
the entity being held accountable. By authentication, this means
results are not premised upon assumptions whether the entity was the
source. While an entity can 'authorize' a server, this in converse
does not mean that because the server was 'authorized,' the entity is
therefore 'authenticated' without some other assurances being made.
-Doug