[feedback-report] comments on draft-shafranovich-feedback-report-01

wayne wayne at schlitt.net
Mon Jun 19 21:20:54 PDT 2006

Hi everyone

Yesterday, I sent an email to Yakov about this draft, and as somewhat
of a result, I've stumbled across this mailing list.  I haven't heard
back from Yakov yet, but I figured I would resend my comments to this

As I mentioned in my first sentence to Yakov, I'm not involved with
abuse desk issues so I'll probably stay out of most of these
discussions.  I also think that my comments about the
authenticated-results header are probably best dealt with on
mail-vet-discuss list, so I will make a post there with a more
thought-out message.  (For example, I see that there *is* a new I-D
for this header and many comments have already been addressed.)

[note: I edited this slightly for spelling, it is not identical to
what Yakov received]

--- cut here ---

Hi Yakov!

Not being involved with abuse desk issues, I've not followed the
work on having a common feedback report format much.  I stumbled
across a fairly recent reference to it today, and decided to see how
things were going.  (See
http://www.politechbot.com/2006/04/15/debate-over-dearaolcom/ )

I wrote up the following two comments on your draft before I noticed
that the draft had actually expired.  Before I continue reviewing it,
I would like to know if this still an active project.  Are you
interested in comments on it?  Is there a newer version I should
review instead?

In section 5.3, you mention the Authentication-Results [header].  In my
opinion, using this header is not a good idea.  I really like [the] theory
of using one common header for all the email authentication systems,
but in practice, I don't think it will work well.

We did not decide to use it for the SPF RFC and I'm pretty sure that
the DKIM folks have decided not to use it either.  There are two major
reasons, which I present both to the SPF folks and to the DKIM folks.

First off, when the draft was last reviewed by various IETF lists,
there were *many* problems pointed out, [both] in format and in
substance.  Worse, the draft had expired and did not look like it
would be updated any time soon.  This was a killer for SPF since we
were very far along on the RFC process and didn't want to be stuck
waiting on this draft as a dependency.

Secondly, and in my opinion, probably more serious is that it tries to
unify the authentication results that really aren't semantically the
same.  What it means for an SPF "PASS" is different from a DKIM
"PASS", although they are fairly close.  There is a much larger
difference between what it means for an SPF "FAIL" and a DKIM "FAIL".
DKIM signatures can fail in many ways, either due to corruption during
transmission, expired keys, attempts at forged signatures, the
dissallowance of third party signing, and probably a few other

Trying to create a common authentication result header is really not
that different than trying to create a spam filter result header.  It
would be neat if you really could boil everything down to a common,
interchangable result, but in practice a spammassassin result is going
to have different semantics than a postini result.

Also in section 5.3, you reference RFC1035 section 2.31 as the format
of the domain name in the Reported-Domain: header.  This definition is
out of date and you should probably reference RFC3696 instead.  The
SPF RFC (RFC4408) has some ABNF for the TLD, but I think the USEFOR
drafts have a more complete set of ANBF that matches RFC3696.

--- cut here ---


More information about the abuse-feedback-report mailing list