Hi.
From what I have read, this mailing list is only supposed to have one
subject at a time, and it *appears* to me that this topic is still the
authentication-results header. Please let me know if this is not the
case.
I sent a couple comments on the Abuse Feedback Report I-D, and one of
them was about the use of the authentication-results header.
One thing I mentioned about this header is that I thought that the
draft had expired and no work had been done on it for quite a while.
This is clearly not the case, I was just behind the time. Also, the
last time I saw this I-D being review, many problems were mentioned
with it, both in format and in substance. Reading the archives, it
appears that many of those same issues have been raised again and are
being addressed.
However, the major problem I have with this I-D is that, after
thinking about it, I don't think it is a really good idea.
Initially, I really liked the idea of a unified header to deal with
all the different authentication systems being floated about. The
advantages are well laid out in the I-D, so I won't repeat them, but I
generally agree with them.
I think this is a great idea in theory. In practice, I'm not so sure.
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.
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.
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.
There is also the problem that the definitions of things like
"SOFTFAIL" in authentication-result I-D don't exactly match the
definition in the SPF RFC. This creates ambiguities and
miscommunication. It is like translating a sentence from English to
French, there reason fro the phrase "lost in translation". The
definition of "SOFTFAIL" for the SPF result should be referenced back
to RFC4408, anything else will just cause problems.
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.
However, if we do this, then what is the point of having the
authentication-result header?
While there have been some comments already about the security issues
of communicating the results to an MUA, I think the whole process is
much messier. Each MUA is going to have to understand the subtleties
of each authentication system. Each end user is going to have to tell
the MUA which authentication systems are supported by each MDA that
they use. It isn't enough to simply say "you MUST strip the
authentication-results header", the end user will have to know if that
MDA is stripping it or not.
I dunno. I seem to recall there was an RFC published that tried to
unify all the spam filter results. I don't think it went anywhere in
large part for the same reasons I mentioned here. It just isn't
useful to try and make Spamassassin's and MXLogic's results mush into
a single set of results.
I guess with Sendmail and Yahoo both supporting this header, it is
unlikely to go away. As I said, I initially liked the idea, it sounds
good on the surface, but I think in the end, this header is going to
end up causing more problems than it solves. Time would probably
better be spent making sure that each authentication system has a well
defined header that deals with the special needs of each system.
-wayne
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html