Doug Otis wrote: >> Mailing list should HONOR it. If the abuse is so low, then it >> wouldn't hurt if forwarders honored policy. But it would at least >> close the loophole for the presumed "low volume" domain abuse. > > Any effort at imposing ridge rules will lower the reliability of email, > while also increasing support costs. As such, absolute policy > assertions are likely to prove useful in only a few cases. Nevertheless, > the TPA-Label scheme offers a significant level of flexibility that does > not require any coordination between the involved parties. After all, > such coordination will never scale.
I generally work on the basis that steady state operations do scale and operate efficiently and smoothly under a common protocol expectation with parts that fit under a standard tolerance levels. However, when we have relax provisions, pars that don't fit, it promote complexity, ambiguity, overhead, additional patch work, relief values, more wrapper layers and overall higher cost to manage, this continues to place more pressure on the system with all kinds of potential leaks in the network. Whether its DKIM itself, ADSP, undefined reputation schemes, TPA, DSAP, this subject topic SMTP level DKIM header signature proposal, there is something fundamentally wrong with the work if we have a set of documents that specifically targets mitigating exploits, yet we have other docs that basically offers relax provisions that essentially conflict with these protections. I find it very hard to come up with a working solution or compromise. Clear and consistent functional specifications are required first. For this topic, to me, the fundamental question is whether a SMTP transaction can be rejected with a new SMTP level DKIM-related algorithm before DATA is reached or partially read. Any current plug and play 2822/5322 technology trials at SMTP requires the entire payload to be read first. So there is no payoff on minimizing data reception. The only payoff is SMTP level rejection. However, under DKIM, with remailers being exempt to not pay too much attention to original domain intentions, this SMTP level rejection has its risk. So IMV these SMTP/DKIM handling engineering issues need to be settled before any wrapper technology can even get a chance at Proof of Concept. -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
