Franck,
In my view, if we remove statistics from this consideration and just
consider protocol consistency for DKIM technologies, then it makes
engineering sense that resigners MUST respect and support RFC 5617.
While it might be easy for some people to believe this is a non-issue
because they never believed in policy in the first place, and framed a
RFC 5617 document that they believe to be of limited value and stated
so many times, in reality, this non-belief causes problems for people
who do implement it. When these non-supportive resigning systems
intentionally ignore the possibility of ADSP domains, we then no
longer have protocol consistency and there is clear interoperability
problems because of it.
I personally believe we need a simple 3rd party policy, but I don't
think we can resolve that until we have established in the WG the
significance of RFC 5617 and the current intentional non-supportive
behavior of resigners.
I think that this a legitimate DKIM adoption issue and it is one I am
facing as a SMTP, LIST SERVER product developer.
Should I ignore RFC 5617 like it never existed and expect it will
never be supported at the downlinks for list mail distributions?
--
Franck Martin wrote:
In most organisations, there is always someone subscribed to a mailing list.
So I see ADSP will fail there "all" the time.
It seems to me the first party signature ties to the From: header, while the
third party signature, ties to nothing.
The elegant solution, would be to tie the third party signature, may be to
the header: List-Unsubscribe:
In both case this would tie the message to an email address, where you can
send queries.
This would allow the mailing list software, to continue to behave as usual
and also respecting the ADSP.
if there is a valid 3p signature, then it can check ADSP to verify the
mailing list take care of its emails, it would then make the 1p signature
irrelevant (ADSP wise) if broken because the from: header does not match and
a few headers have been removed.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html