An effort such as this one could actually improve the possibility of avoiding such false positives as you are describing. From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] I've seen a lot more harm done by spam filters, than by spam. of course that's subjective, as I don't directly see the "good" that the filters do - when they drop spam - but I do see the harm that the filters do - when they drop messages that I needed to see. but spam filters do a lot of harm to the reliability of message delivery. Keith On Apr 15, 2011, at 2:12 PM, Murray S. Kucherawy wrote: It’s not, but it is in a better position to reject content than an MUA is because it’s the thing that talks SMTP across the ADMD boundary. So where a particular recommendation might be “reject” or “discard” or “quarantine”, those are MTA actions and not MUA actions. It’s also where ingress filters (spam, virus, other content) tend to be attached, and this document addresses those as well. Every module involved needs to act in concert. From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] It's an attack vector no matter who is interpreting the mail. Why is the MTA in a better position to examine content than the MUA? Keith On Apr 15, 2011, at 2:04 PM, Murray S. Kucherawy wrote: Attempts to interpret malformed mail are what MUAs are doing, and what MTAs are not doing (or are doing differently). As Dave Cridland points out, this creates an attack vector. I didn’t suggest that the IETF needs to recommend “practically… what happens”, but I think we’re burying our collective head in the sand if we maintain the position that malformed mail shouldn’t be allowed in the first place. Decades of permissive software deployment got us to where we are, and that’s not going to be undone in short order. I totally agree, for example, that pressure should be applied to senders. But that’s simply not what happens. And in that stalemate between the way we say it should work and the way it does work, the end user loses. From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] IETF's job is not to recommend "practically .... what happens" but to recommend what works well from a technical perspective. Masking the problem does not work well. And in my experience, attempts to interpret malformed messages and guess what they really meant often fail. However, it is important to arrange things so that the "pressure" goes to the right place - i.e. someone who can fix the actual problem. In the case of a malformed message, that ends up being the sender. The sender might then put pressure on his ISP ("why didn't my mail get there? why did something complain about my mail reader generating a malformed message?") And the ISP might well respond by having their mail submission servers try to repair those messages. At least in that case, if the ISP's mail submission servers do more harm than good, the feedback will still go back to the sender and/or his ISP, and the ISP will be in a position to fix the problem with the fix. When the "repair" is done by a party unrelated to the sender, that opportunity is lost, and there is no convergence toward a working system. In general, OPES rules would seem to apply here. Keith On Apr 15, 2011, at 11:54 AM, Murray S. Kucherawy wrote: I think that’s true from the IETF side of things, but practically speaking that’s rarely what happens. What arrives at an ingress MTA contains all kinds of insane things, and in my experience the choice to reject them outright puts huge pressure on customer service facilities that nearly always results in demands for more relaxed software. And since that turns it into a business case, the pressure usually wins. So given that reality, this work seems to make sense to have out there, rather than allowing widely varied choices about how to handle this case or that one that result in weak ingress security all around. From: Keith Moore [mailto:moore@xxxxxxxxxxxxxxxxxxxx] I'm strongly opposed to MTAs "fixing" malformed messages (other than submission servers fixing a small number of known problems caused by broken mail clients). If an MTA does anything at all when it thinks that a message is malformed, it should be to bounce it _exactly as it received it originally_. MTAs trying to fix malformed messages, at best, mask problems further upstream that should be fixed. At worst, they exacerbate existing problems and make such problems harder to diagnose. Keith On Apr 14, 2011, at 3:07 PM, Murray S. Kucherawy wrote: This is some work starting up in the APPS area. Please comment on the apps-discuss list if you’re interested in participating. From: apps-discuss-bounces@xxxxxxxx [mailto:apps-discuss-bounces@xxxxxxxx] On Behalf Of Simon Tyler Hi, <ATT00001..txt> |