I read the auth-* drafts.
Lisa Dusseault writes:
I'd like to do a more explicit consensus call now to nail this down.
I've tried to identify the major points of attraction rather than
every variant, to see where people are leaning. Please reply with
one of these options, a variant, and explanation if you like:
A) auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising
I don't like auth-header, but if any, then A.
Comments and stuff.
1. Auth-header tells MTAs to add two (or more?) trace fields. The
document doesn't specify order, so if it's not clear what was added by
y below:
Received: by x ...
Authentication-Results: (1) ... (dkim stuff)
Received: by y ...
Authentication-Results: (2) ... (dkim stuff)
Authentication-Results: (3) ... (iprev stuff)
Received: by z ...
Y might have added 1, 2 or 2+3, right? Difficult to handle. Particularly
if the analysis code wants to detect or handle reordered headers.
This could be fixed by adding a new level of hierarchy between header
and field. Call it trace-field-group. But we have that for Resent-* and
IMO that's one of the reasons Resent-* has faded from view.
Another solution would be to write this information inside the Received field.
2. I've noticed that some DKIM implementations like to sign every field
they see, which might include auth-headers. The auth-header draft says
to remove old auth-headers, breaking such signatures. That conflict
needs advice, or at least a security consideration.
3. The reason I don't like advertising is that many people use so very
complex delivery chains. Transmitting capability advertising from start
to end is hard. Better to design the stuff so that's not needed.
4. Why isn't there a sieve extension to let people filter mail on this?
Arnt