On 10/30/09 3:04 PM, hector wrote:
Doug Otis wrote:
Hector,
Doug, for the same reasons reputation schemes are hard to shallow for
DKIM as a general, useful, consistent scheme protocol, it was also
hard to shallow for CSV. It was a Batteries Required concept, and
once again, doesn't address failure which was what MARID was looking
for - the result SPF/SENDER-ID.
IP address path registration scales poorly and invites trouble.
Reputations of those offering SPF authorization is a poor tool for
improving the behavior of providers at fault. In addition, Dan Kaminsky
demonstrated that arbitrary queries enable poisoning of other important
records. By not including message bodies in DSNs and by checking valid
recipients prior to acceptance, this has largely solved the "failure" of
which I think you're referring. CBV represents another ill conceived
effort further burdening SMTP. :^(
SPF/Sender-ID expects MUAs and MTAs to make from 1 to 111 DNS
transactions for each name checked! Queries whose targets might be
unrelated to anything within email and yet modulated by various email
address local-parts generated from cached records. As such, SPF remains
a risky tool. Imagine the DDoS attack enabled by SPF over DNSSEC.
If you wish to consider policy and enforcement, I might even begin to
cheer for CSV. However, its really a day late and a dollar short -
the SPF standard is widely adopted and has an optional solution at
EHLO/HELO checking. CSV would be redundant.
The SPF protocol suggests these records _might_ confirm the IP address
of the SMTP client. There is no specific "policy" requirement being
imposed. In the end, the sending MTA is likely never affirmed by name.
Only that perhaps some feckless domain authorized an MTA by an IP address.
Dealing with IPv6 will likely require reputations be based upon a
domain name rather than upon individual IP addresses.
Why do we keep talking about a solution with a undefined reputation
component?
IMHO, soon only positive reputations are likely to prevail, but these
should reflect the actions of those in control. When done by name, the
numbers are manageable and less likely to require reputation assessment
services. A list a few million will likely be enough to seed a process,
where relational trust can fill in the gaps.
We talk about it so much, maybe it should be written into the charter
so we can concentrate on developing a open standard reputation
protocol, then maybe some of the reputation/DKIM ideas can begin to
make sense.
If there is a need, many companies are more than willing to provide the
service. The hope would be to document a process that avoids the need
for this type of service.
Looking for the low-cost web of trust...
Original Domain DKIM POLICY! Middle ware should keep their fingers
off.
Any transition will likely require exceptions. Publishing which
exceptions are needed should be made easy for the sending domain, and be
little effort for receivers to apply. If a TPA-Label authorization of
the Mail From avoids CBV, that would be a win for both. If the TPA-Label
authorization ensures the issue of an important DSN, again a win for
both, at the expense of a single transaction.
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html