As long as the deployment of the pure DKIM protocol continues to openly allows for blind middle-ware resigners and destruction of author domain signatures to exist without any sort of protocol guidelines to offer controls, its hard to see any kind of policy concept having a chance to work - author domain as well as the inherent abstract 3rd party signer trust policy in DKIM. It really doesn't matter what we call it or who we wish to anchor a policy on, if the protocol allows for middle ware to ignore it and still be legit, then there is no worth in original signatures, including the previous resigner. At this point, the only real signer one can focus on is the last signer.
I've been working on an idea to have our POP3 server SIGN all mail that is picked up! Why? because mail is not always RFC5321 (SMTP) based. Mail can be created online in the backend format. There is no RFC5322 format expectation at this point. Its only during an export or gateway does RFC5322 come into play and if the message is export to SMTP to send out, then we sign it. But there are users who will POP in to get their mail and that mail is unsigned. So we are looking at signing local mail pickups. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Michael Deutschmann wrote: > On Wed, 27 Jul 2011, Douglas Otis wrote: >> Your fix will not control phishing or spoofing abuse and would expose >> these domains to open-ended sources. > > ADSP reforms along my lines would not create any additional exposure, > because they are only intended for senderside deployment by sites that > are currently entirely naked. > > The availability of weak ADSP declarations would actually increase the > protection afforded by "dkim=discardable", because then fewer domains > would go without ADSP, and more MX administrators would be incentivized to > implement and arm it. > > Remember, for an MX admin the goal is not to "control phishing". That's > just a side benefit of their true goal, to "control forgeries". When > forgery can be reliably detected, it becomes a low-false-positive noise > filter, something every MX admin loves. > > ---- Michael Deutschmann <[email protected]> > _______________________________________________ > 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
