[mail-vet-discuss] Auth-Results issues? #2 headerspec

Tony Hansen tony at att.com
Wed Mar 22 12:22:55 PST 2006


As a prelude to the following discussion, here is a sample of A-R
headers I've collected from various DKIM/DK/SPF test auto-responders.
(I've changed "hostname" in all cases to example.com. I've changed the
sending system's name to example.net. The references to tony at att.com are
what is in the rfc822.from header.)

Authentication-Results: example.com from=tony at att.com;
	sender-id=fail (DomainDoesNotExist);
	spf=fail (DomainDoesNotExist)
Authentication-Results: example.com smtp.mail=tony at att.com;
	spf=neutral
Authentication-Results: example.com header.from=tony at att.com;
	domainkeys=neutral (not signed);
	dkim=neutral (not signed)
Authentication-Results: example.com from=tony at att.com;
	sender-id=fail (DomainDoesNotExist);
	spf=fail (DomainDoesNotExist)
Authentication-Results: example.com header.From=tony at example.net;
	dkim=pass (768-bit key)
Authentication-Results: example.com from=tony at att.com;
	sender-id=neutral;
	spf=neutral
Authentication-Results: example.com; header.From=tony at att.com;
	dkim=neutral
Authentication-Results: example.com;
	header.DKIM-Signature=@example.net;
	dkim=fail (DKIM RR problem for example.net/shan.
		missing/bad public key; example.net/shan fail; );
	header.From=tony at att.com; dkim=neutral
Authentication-Results: example.com header.from=tony at att.com;
	domainkeys=neutral (not signed);
	dkim=pass (1:0:good;)

I have a variety of problems with the "headerspec" value.

It's unclear how multiple methods are to be combined together into a
single header; what happens with the "headerspec" value? If you wanted
to put in an A-R header saying that the message passed CSV, SIDF, SPF
and DKIM, how would those be combined? Each of those could and possibly
should have totally different values for headerspec. Messages often have
multiple identities that are confirmed differently by the various
authentication methods. CSV can identify the relay hostname. SIDF can
identify the rfc822.sender/from/etc. SPF can identify the smtp.from
hostname. DKIM can identify the sender's hostname. Which one goes into
the headerspec?

In the samples, some authors have punted and just put in a "header.from"
value, a choice totally divorced from the mechanism. One author
improperly put in multiple headerspecs. One author eliminated the
headerspec entirely. One author chose a headerspec based on the method.

My proposal is to either eliminate the headerspec from A-R, or to make
it subordinate to the method=result. In other words, the headerspec
should be supporting information to what was validated, not the other
way around.

If headerspec is kept, note the varying use of what's put there. Let's
think about what the values for ptype first. The spec says either "smtp"
or "header". Note that DKIM doesn't match either of these, because it
uses both the header and the body to do verification (and a DNS entry
too). Hmmm; should token be listed? No, I wouldn't want that. But I'm
not sure what to replace it with. Note that in the samples, some people
ignored the "ptype" entirely; perhaps it should be eliminated after all.

Also lots of people got this wrong: for example, DKIM does not usually
provide a username as the identity, so should not be listed with a
headerspec of header.from=tony at att.com. The closest I saw to what I'd
consider proper usage of a headerspec for DKIM was
header.DKIM-Signature=@example.net.

Argh.

Back to first principles: what's the headerspec supposed to provide?
>From the comments in the ABNF, I see three things: 1) which part(s) of
the message transmission was being evaluated (smtp, header or body); 2)
what identity was extracted from those parts; and 3) what in particular
within those parts was used to determine the identity. (Ok, body isn't
listed in #1, but should have been.)

>From this, we can see that a headerspec should be totally dependent on
the type of authentication that's being performed, and the types of
values that should go into it are also totally dependent on the type of
authentication.

This implies to me that the headerspec should be: 1) subordinate to the
authentication results; and the choice of what should be used for ptype
and property should be specified by protocols that use this specification.

	Tony Hansen
	tony at att.com


More information about the mail-vet-discuss mailing list