J.D. Falk wrote:
hector wrote:
IMTO, before any automated concept can work well, the supportive DKIM
network must expect protocol consistency to be established among all
DKIM nodes.
Why are we arguing about it now, then? It'll be years until we reach that
point.
+1, however.
Don't you think a common ground (standard protocol methodology)
understood by all to even begin this long term process is necessary?
It wasn't my intent to create the illusion this is an argument. DKIM
is about mail integrity. Intermediary (re)signers are natural
contentious with this philosophy. I am simply stipulating that
intermediary (re)signers need to also support any ADD-ON protocol that
is designed to help mitigate DKIM integrity problems domains and for
the resigner itself.
I'm thinking with my Developer Hat on.
We have RFC 4871 (DKIM-BASE) and RFC 5617 (ADSP). How do we implement
this for signers and verifiers components in a logical "fit" that will
also be compatible with other systems also considering DKIM-BASE and
possible ADSP?
Note that in the deployment guide section 6.5, it already says:
Any forwarder that modifies messages in ways that will break
preexisting DKIM signatures SHOULD always sign its forwarded
messages.
However, there is no implication about resigner restrictions in
section 6.5.
And thats part of the problem with the deployment guide:
- ADSP semantics in section 6.1
- Forwarder signing semantics in Section 6.5
Simply put, there is no engineering consistency between the two.
In order to correct this, Section 6.5 needs a statement such as:
Proposed "draft" additional text for Section 6.5
Before any forwarder attempts to modifies messages and add
a new signatures to the message, it SHOULD look at the
ADSP record for the 5322.From domain. If the domain has
an ADSP record with "dkim=all" or "dkim=discardable", the
forwards SHOULD NOT forward the message.
Note: Forwarders who do not support ADSP should be aware
rejected or bounce mail may be result. For mailing
list systems, false subscriber removal notifications
can occur when the subscriber MDA is supporting ADSP.
See section 6.1 for ADSP support recommendations.
--
Hector Santos
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html