On Sun, 2005-08-21 at 23:38 -0400, Scott Kitterman wrote: > Douglas Otis wrote:
> As I've said before, we are wanting to solve two different problems. > You want another input to improve spam filtering and reporting in order > to get from IP based solutions to name based solutions. Fine. I don't > think it will help that much, but have at it. What I have suggested involves more than transitioning to name acceptance criteria. The objective includes improved control over out bound email, independent of mailbox-addresses. > Filtering solutions are fundamentally dangerous to the mail system. > They are a necessary danger these days, but we should be striving to > find ways to minimize the risk that messages will disappear into a spam > folder somewhere. It's far better to reject up front. If a legitimate > sender is rejected, at least they'll know. I agree. A better system either accepts or refuses messages without heuristics. > What I want is for domain owners to have better control over the use of > their name and for me to have a mechanized way to know what messages > fall outside their definition of acceptable use. There are many different headers which may legitimately carry a third- party mailbox-domain for valid reasons. On this list, messages appear to be from many different mailbox-domains, but they are not. This is a valuable service. You wish to change existing practices to establish a new ideal, whether this provides a benefit or not. You want providers to either refuse sending or discover third-party mailbox-domain authorizations before sending or accepting messages. An authorization scheme that requires extensive DNS lookups, after prioritizing headers in some arbitrary fashion, to check whether this third-party mailbox-domain permits an otherwise valid and non-abusive message. Could first-party providers expect payments from third-party mailbox-domains to deal with resulting complaints and extra overhead resulting from this new paradigm? Would a provider that ignores this new ideal be considered bad? Is it even practical to express all the many ways email is currently used, for an authorization scheme to avoid causing extensive disruption? Could each of these authorizations require extensive negotiations? How much DNS bandwidth and logic will be needed to resolve all possible states such a scheme may need? > It seems pretty simple to me that if a domain publishes an SSP that says > that they always sign their mail with DKIM and I get a message allegedly > from their domain that's not signed, I can reject it. One view of course would be a message is from the domain that signs it. You must be assuming there is a binding to some header implied by this statement. Unfortunately, declaring ownership based upon just some mailbox-domain will likely create havoc for current practices. > Same if they say they do not want mail with third party signatures to > be considered valid. It fails their policy, so I reject it. Again, this implies first-party ownership based upon some header, whereas the stronger domain signature is ignored. Should this definition of ownership include Resent-Sender? Should this be only used for the From? What happens when the From has more than one mailbox- address? Binding headers is really better done with S/MIME or OpenPGP to avoid disruption. > The beauty of this type of system is that there is no centralized > clearing house who will control the mail system. By clearing house, are you suggesting this header authorization eliminates a need for reputation services? Are you suggesting abusers will not be able to meet requirements of self-authorization? > It's a distributed as DNS and the only parties involved in the > transaction are the receiver, then sender, and the sending domain > owner. There is the (1) signing domain, the (2) sending domain which may be different, your view of a (3) sender, defined in some fashion by a mailbox-address, and the (4) receiving domain. You want (4) to contact (3) via extensive DNS queries to decide if (1) is permitted to be sent by (2). If (4) trusts (1), is all this potentially disruptive logic needed? > Now, I don't expect to win you over on this point because you've > repeatedly declared this impossible. It seems simple enough to me. I have said it will not achieve the desired results once the details are considered. I have also indicated this will create disruptions that will likely inhibit deployment. > Frankly I find this "industry list of troubled domains" you mention > above scary. It appears to me to have the potential to put control over > e-mail delivery for the internet in a few hands. That kind of > centralization is antithetical to the foundation of the internet. Am I > understanding you correctly? There is much more involved in phishing than can be possibly met by DKIM alone. It seems reasonable for these institutions being hurt by phishing exploits to publish who among them is meeting a set of criteria designed to ensure adequate checks are possible. Phishing involves links, deceptive pretty names, similar names, among other things that can not be addressed by rules designed for normal email. Also, as there will be extensive processing involved, screening this list could also be helpful. I would not expect this to be done by a flag indicating the need for some new DKIM mode. The Internet is a collaboration of public and private organizations. What I have suggested is nothing different. I am not suggesting any new cabal take control of email, just that phishing may demand special attention by those affected. Even the use of S/MIME signatures, although currently problematic, may prove most effective over the long haul. If you examine what I have been suggesting, the self publication of revocation-identifiers and bad-lists will do more to reduce reliance upon centralized services than any thing else. Such a scheme greatly leverages feedback reporting, where sending domains are then able to better protect their recipients. This will permit dealing with zombie systems promptly and effectively. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
