On 10/31/09 5:41 AM, hector wrote: > Doug Otis wrote: > >> 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.
When "steady state" includes dropping suspicious messages, or the performing of challenge response checks, then there is an area that a reduction in process and/or ambiguity would help. > 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. Since no change ever occurs at once, there will remain areas where handling is less certain. However, the sender is still able to offer information that has been made more trustworthy as a result of DKIM. This information might affirm relationships between the signing domains and a different domains contained within Mail From or EHLO, for example. Perhaps this information might lessen the likelihood of the sender then receiving a challenge response check, or of having their message dropped without issuance of a DSN. > 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. You are on the right track. IMHO, name based acceptance will soon be how SMTP EHLO acceptance is achieved, where relational information offered from trusted DKIM domains can assist in amending this information. There can never be any definite rules in how this is done, since all rules will be gamed. When decisions change from "unknown" or "bad-actor", to "unknown" or "good-actor", the process is less easily gamed, and tighter thresholds in determining behavior permit maintenance of "acceptance list" with minimal exposure. There would be two aspects of this list. Domain to domain relationships that might entail a few hundred million out of which good actor domains need to be identified. And then good actor SMTP hostnames with their related IP addresses which will entail a few million. Hints given by SPF are often overly broad and are easily gamed. IMHO, this information should be ignored. To prevent gaming, receivers should track "actual" use. The amount of information involved with "good actors" is actually fairly small, so this is not a difficult problem. Once a receiver has been "seeded" with reasonably complete information, amending the information on a trial basis with information of affirmed relationships should prove practical. > 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. There are other payoffs as well. Avoiding challenge response, or dropped messages without DSN would represent other payoffs. > However, under DKIM, with remailers being exempt to not pay too much > attention to original domain intentions, this SMTP level rejection has > its risk. When there are hundreds of thousands of domains indicating that "mailing-list-r-us" should be trusted, then how they go about handling their lists with respect to DKIM is less of a concern. Of course, it would help greatly for them to add their own DKIM signature. > 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. Dave insists that transfer by reference is off the table. IMHO, SMTP and DKIM unchanged can be made to work as described. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
