mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Comments on the authenticated-results header

2007-05-19 11:25:18
I've been dormant on this specification for quite some time, assigned to other projects and especially to DKIM. However, given the interest in it at the last IETF I'm dedicating time now to resuming work on it. I'm hoping to have something fairly solid by the IETF in July.

Now, to Wayne's almost-year-old remarks:

wayne wrote:
The biggest problem I see is that the semantics of the results from
the different authentication methods don't always line up so well with
the results defined in this I-D.  The results listed seemed to be
heavily based on SPF, but SPF result codes were never designed to be
general.  SPF is not the end-all and be-all of authentication
systems.
The current set of results was indeed based on the list given in SPF. They seemed at the time to be sufficiently general to clone so that's what I did, but I'm open to suggestions about a more general set.

While the meaning of an SPF "PASS" is very similar to a DKIM "PASS", I
don't think the results of an SPF "FAIL" really match up well with a
DKIM "FAIL".  DKIM has many more "failure" cases than SPF.  The DKIM
signature can fail validation due to changes in the email during
transmission, expired keys, attempts at forging the signatures, the
disallowance of third party signing and probably several others.  Of
course, there is also CSV, SMTP AUTH, PGP and quite a few other
authentication systems out there that probably need specialized
failure codes as well.
All true. My intent with "fail" and making it a structured header field is to allow the more specific cause of the failure to be relayed in comments. As the field is structured, locating the comments specific to a method (if any) is fairly easy.

Actually, I guess SPF evaluation can also "fail" in several ways, and
these other ways are encoded into this specs, with the TempError, and
PermError results.  I'm not sure if those two result codes really
apply to DKIM, CSV, SMTP AUTH, PGP, etc.
No such key would be a permerror for DKIM, while a transient DNS error could be a temperror. AUTH and PGP, for example, might not have cases that map to permerror and temperror. They're provided if the methods need them, but a method doesn't have to have a use case for each.

Now, one thing that could be done is to get rid of all the definitions
of the results and simply reference back to the appropriate specs.
Each authentication system would have its own set.

That's entirely possible as well. Would it be a big hassle for IANA though? That is, would we need a registry of possible result values across all known methods?

However, if we do this, then what is the point of having the
authentication-result header?
The value to me as a developer would be reduced header clutter. If I'm running eight methods, I'd rather not have eight (or more) different headers to eat, with different formats, for collating results.

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [mail-vet-discuss] Comments on the authenticated-results header, Murray S. Kucherawy <=