Franck Martin writes: > Anyhow... my point is that moving an human decision to the machine > is difficult, this is why we rely on protocols
Sure. That's why the U.S. military relies on landmines, too. "Smart bombs" aren't perfect, obviously, but they're better than landmines! DMARC "p=reject" isn't life-threatening when used by Yahoo!, of course, but it has collateral damage in the same way. And also in the same way, eventually you get to a point where the filtering decisions need to be made by a human. Unconditional reliance on protocols is irresponsible. > principle in the malformed emails RFC. John said (maybe?): if the > protocol is vague, be lenient, but if the protocol is clear then be > strict. He did not say "accept anything, the user will sort it out" Indeed he did not say "accept anything". But no, he did not refer to the clarity of the protocol. He said (paraphrased), if you're producing output according to a protocol, conform strictly (implying: even if it's stupid). If you're accepting input according to a protocol, use your judgment (implying: give the end user what they want). I think Google's treatment of DMARC "p=reject" is in exemplary conformance to Postel's principle. In some cases (often indicated by an obs- production in ABNF), we even explicitly specify a certain degree of leniency as SHOULD. But that's not always possible; often it must be left up to implementations. > From the discussion I have this question: How an MTA knows the > email is from a mailing list? Because List-Post and/or List-Id is signed with a known key. > Also looking at bayesian implementations in say spamassassin/amavis > (I looked quickly) it does not seem the bayesian rules are > organised around authentication identifiers. No, because the rules labeled "Bayesian" are only part of the system. However, stuff like SPF and DKIM have add-on modules to generate auth results and assign them to variables, and then you can create rules which assign spam points according to the values of those variables, and thus take advantage of those facilities. Strictly speaking not an application of Bayes rule, but a sort of hybrid classifier. > the From for that? May be, may be not.... It seems going forward, > there should be different baeysian learning, depending on the > authenticated domain attached to the email. I don't think we are > fully there yet. We never will be "there". But I have to wonder if our time might not be better used in building a better Bayes rather than trying to repair the DMARC protocol (which for some use cases just ain't broke). > For instance, the simplified rule should be if this is an email > looking like made only by X, but not authenticated by X, junk > it. I'm not sure there is any rule like this out there for lot of > MTAs. Of course there is. I've never used it, but SpamAssassin has had an SPF verifier for something like 10 years. You can add a rule that says if SPF fails, give it 100 spam points, and that will cause it to be junked. > So to close this long tirade, I think we are moving towards a > domain authenticated world of emails, using valid domains as > identifiers of source. If you mean using valid domains with valid signatures as the *only* identifier, "I don't think I want to be part of that 'we'." I think a lot of your feeling about this is that (1) you just don't trust classifiers (and yes, there are plenty of real examples where they've been fooled badly), and so (2) you're really not up on the classifier technology. > And yes, MUA have their role to play, in filtering according to > user preferences, but the tendency, is for the MUA to pass the user > preferences to the MTA, so it can work on received emails even when > the MUA is not connected. I don't want my mobile to do the > filtering, but tell the MTA what emails I like/don't like. I don't blame you. I don't know any decent mobile MUAs. But consider the GMail app. The MUA may actually be integrated with the MTA (any Google Mail devs want to comment), I don't know, but in principle GMail is an MTA. The "advanced" version of the MTA part of GMail is a *distributed system*: much of it is implemented in Javascript in your browser, but the filter rules and so on are implemented in the Google cloud. I don't see any reason not to implement filtering in the mobile MUA when mobile MUAs are actually such distributed systems. Regards, _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
