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
