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.
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.
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.
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.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
