Hi Wei, IMO, your proposal is on par with the engineering considerations needed to develop and mold the charter. Your proposal intent is to preserve the integrity and indirectly, the authorization for forwarding, resigning mail. The draft charter has its own even higher complex ideas for the same intent. My intent is to keep it simple with 3rd party authorization framework and I don't see any other better method than a DNS-based lookup method for resigning authorization or allowance. I believe in strong rejection author domain policies. You can't standardize random, subjective heuristic methods, but you can standardize deterministic protocol methods. This is the wider, network persistent and consistent solution that everyone can use.
If your offline moderation control messenger intent was to steer the work towards a specific more. complex, DKIM changing direction, and any negative discussion about it or censoring other better alternatives, and specifically authorization methods, are out of scope, then I don't wish to spend any more time, money and resources in what I strongly believe is going to be a big waste of time, doesn't resolve the problem, nor does it eliminate the need to do DNS lookups. The ADs need to consider more engineering solutions views that are outside the same typical folks who have long had control of this project. We are here today because the DKIM project leaders were incorrect in their presumptions about the market needs, directions and they seem to be repeating it again. I don't want to go thru this costly error again. The draft charter as written is too complex and IMO, it will not solve the main problem we always had which is how to authorize and scale resigners. Your idea is really not that different than what Murray and Dave want to pursue in the draft with a higher level DKIM processing complexity, long term prospects which I believe are not necessary and probably unrealistic to believe people are going to blindly accept with even more expense in long term experimentation. DKIM was just made into an STD document last year and already there is consideration in changing. Thanks -- Hector Santos http://www.santronics.com > On Jun 28, 2014, at 8:01 PM, Wei Chuang <[email protected]> wrote: > > Hi Hector > >> On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos <[email protected]> wrote: >>> On 6/28/2014 9:41 AM, Wei Chuang wrote: >>> Note this isn't a full proposal as we would like the concept to be >>> considered first. If this discussion is successful, we would like to also >>> discuss a related improvement to SPF and DMARC, as well as the binary >>> encoding change. At the conclusion we can have a longer discussion about >>> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a >>> draft that tightly specifies how this works. >> >> Wei, >> >> Any "chain of trust" idea will work with a honored client/server negotiated >> protocol steps and ideals. >> >> The problem has always been in dealing with the deviation from the ideal >> protocol steps and compliancy expectations. >> >> So if you have a protocol ABC, what are the benefits of this ABC processing? >> What is the payoff for the compliant mail receiver? What is the payoff for >> the originating/author domain? > > The benefit is that the recipient can authenticate the originating sender and > in particular a particular action such as sending to a mailing list, yet > allow intermediate domains to modify messages. It may be that a user has a > filter to see all messages from the original sender. This is jumping ahead a > bit, but the current DMARC paradigm is for the mailing list to own the > message and rewrite the RFC5322.FROM which make this difficult. In addition > SPAM filters likely can benefit from being able to process the original > message and know message was authenticated by the original sending domain. > >> What happens when there is deviation, something broke in the chain of MIME >> diffs? What do you want receivers to do? > > In this proposal, it would be the same as failing DKIM RFC 6376 verification. > It ought to be treated as information the recipient domain can use for > additional Spam processing etc but not necessarily indicate reject or other > action. This proposal is meant to build infrastructure that can be used to > enhance DMARC in a subsequent proposal. By itself this proposal primarily > provides extra information (well a strong guarantee on the authenticity and > modifications) for Spam processing. > >> >> You must think of the massive volume of wasteful mail processing. Not >> everyone is going to do this just for nothing. It has to have a meaningful >> payoff, and today that payoff comes in the form of mail filtering policies >> with rejection/quarantine/discard author domain policy concepts. >> >> So if your proposal says: >> >> "If you follow these steps, the author domain >> is OK with you (because you asked him) honoring >> rejection, if you see a problem, then there is >> something wrong with it and its better (trust the >> author policy) if you just reject it." >> >> then we you got something to consider. >> >> But I think in this case, your proposal is a higher processing complexity >> factor when all you need to do is ask the author if the final/last signature >> in the chain is an trusted and/or authorized signer domain. If you are not >> asking the author (directly or indirectly) if any of this forwarding stuff >> is ok, then I think you have a security conflict (loophole) to consider. > > I'm probably misunderstanding your intent. Here's a stab at a response: > Passing the DKIM Provenance verification is meant to provide a stronger > verification from a purported original sender. If intermediates want to > claim that a mail came from some original sender, then they have to provide > evidence. If they don't due maliciousness or otherwise, they don't have to > include such evidence but they won't get any benefit of claiming the > reputation of the original sender. > > -Wei > > PS It was mentioned offline that the discussion on dmarc@ietf is currently > restricted to building the WG charter. First apologies I missed that. > Second I can restrict subsequent discussion to apps-discuss if that's > preferred by the WG. > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
