On Sat, Apr 20, 2019 at 12:47 PM Bill Cole < mailop-20160...@billmail.scconsult.com> wrote:
> On 19 Apr 2019, at 17:31, Brandon Long via mailop wrote: > > > I just don't think this is practical. > > It could be, were it not for the tragic conceptual cancer of "email is > free like beer." > > > For one, when you're only solution is to reject, the only way to get a > > signal that you're rejecting the mail wrong is manual review, which is > > impractical at best, and difficult to correlate with the opinion of > > the > > actual receiver. > > "Impractical" in this case is a result of mandating economies of scale. > > > The spam/not spam signal from users is the best > > information you have on what your users want, even if the bad actors > > try to > > game the signal and a lot of user's use it as a hammer instead of the > > softer touch. > > Yes, vetting and training users is judgment-intensive and > wisdom-intensive work. Charging users for the service they get helps > with the vetting of some sorts of bad behavior but convincing > well-meaning people to not be childish is harder. > > It is a serious challenge to find and/or develop enough of the right > people to handle that, and it has almost no economy of scale, unlike > basic technical ops. > > > The second is that it is impractical to ascertain whether a message is > > spam > > or not during delivery time in all cases. A decade ago, the reason > > was > > because we had to OCR images contained in power point presentation > > spam, > > now there are services where anti-malware services are opening Word > > files > > on clean VMs, or anti-phishing/malware where the service has to follow > > each > > link through a headless web browser with full javascript running. > > There are multiple approaches to that, none of them cheap. > > One fact that is very helpful to understand and yet broadly ignored when > people look at the feasibility of processing-intensive filtering is the > mandate of https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6. > Holding a connection open for a long time before admitting you received the message has its own issues, of course. We've also found that we often have way more resources to receive messages than the senders do to send them, I doubt very many mail senders would react well if we started taking minutes to receive every message. Also, you don't NEED to do that in 2019. Email is a ridiculous medium > for file sharing, both technically and for security, so you can > explicitly choose to deprecate it, hamper it, and offer alternatives. > OCR is hard, but determining that an image is essentially the whole > message is not. Determining whether JavaScript is malicious is hard, > rejecting mail with embedded JavaScript is easy. > Sorry if I wasn't clear, this was evaluating the web sites that were linked to from the message. The better you get at figuring out if a message is malware, the more indirection used. Banning links in messages seems like a non-starter. And unfortunately, enterprises often rely on some of these self same tools. Telling them they can't do something like send/receive attachments is a very quick way for them to choose another provider. And these are the paying users. Sure, these policies will alienate some senders and some recipients, and > maybe even some customers willing to pay for less restrictive, more > dangerous, and less useful email service. If a provider wants to satisfy > all possible users at a cost low enough to service a large fraction of > them for free, this isn't feasible. > What you end up with isn't email, then. Turning email into store & forward "talk" isn't that useful when you're competing with dozens of different walled garden messaging services. The problem is the business model to which a freemail operation must > conform. The freemail adaptations to cost constraints and scale have > metastasized via user expectations and cargo-cult system design, but > they aren't necessarily the best choices elsewhere. > You speak of freemail as if GSuite and O365 aren't also the largest paid mail services in the world, with products that are extremely similar to their consumer free services. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
