Alessandro Vesely wrote:
> On 01.05.2011 10:38, Hector Santos wrote:
>> Again, its about protocol consistency. So maybe I should ask the
>> chairs for:
>>
>> "Consensus needs to be reevaluated"
>
> IMHO, it needs not: It is premature to define an ODID now. ADSP is
> considered somewhat broken, and for this message, for example, it seems that
> the relevant id should be "mipassoc.org" rather than "tana.it". ODID would
> risk to be a candidate for removal like AUID.
IMV, ADSP is only broken in that it didn't allow you to declare you
were allowing mipassoc.org to sign for you or in general
"My Mail Is Always Signed - by me or someone else."
The only point here is that you did declare an ADSP record
(DKIM=UKNOWN) and to get that record, the verifier needs an ODID to be
an identity to satisfy the DKIM Service Architecture as described in
RFC5585. All the arguable semantics of its value is not the point in
the same way regarding the value of SDID.
Side Note: Relaxed ADSP policies is a high overhead redundant waste
on receivers because the results are indeterminate. This is the
same reason why SPF relaxed policies are wasteful too and more
domains are changing to a HARD FAIL (-ALL).
> From an engineering POV, policy developments are closely related to the
> verification software, as a matter of facts, so that cleaning up the
> definition of the interface between them doesn't seem to be urgent.
Well, sure, current implementations are already supporting AUID and
ODID and RFC4871bis doesn't reflect that.
Just look at the A-R header recorded by mipassoc.org for your
submission signature (that was stripped):
Authentication-Results: sbh17.songbird.com;
dkim=pass (1024-bit key) header.i=@tana.it
It reported AUID, not the SDID.
What makes it all harder is DKIM Mail Integration. We are using the
A-R to help with adding DKIM related attribute information to import
mail into our backend mail storage. We know what to do because of the
5-6 years of being involved with DKIM. But if a new engineer is
looking at RFC4871bis, they are not going to gain from all the current
implementations experiences. They will need to read RFC5585 (DKIM
Service Architecture) and maybe even RFC5863 (Deployment) and probably
at some point ask themselves or their boss ask them about security
issues and get that from RFC4686 and what will they see? Something
about POLICY called ADSP and then ask, ok, what output from RFC4871bis
is needed to support this thing called ADSP. They will find "hmmm,
there is nothing about it in RFC4871bis. Ok, its the domain in
RFC5322.From."
All I am saying, lets add that semantic into RFC4871bis and make life
easier for the next guy. I guess he will eventually find out at some
point and maybe that is what you mean that it isn't urgent. Ok, sure.
But we have been so anal with so many other little things, word
changes, worried about him not using l= tag or whatever, that we
missed out on bigger things he will probably need.
Anyway, my opinion.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
