On 23 Apr 2019, at 1:17, Brandon Long via mailop wrote:
On Sat, Apr 20, 2019 at 12:47 PM Bill Cole <
mailop-20160...@billmail.scconsult.com> wrote:
[...]
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.
Sure, but there's a lot of room below "minutes to receive every message"
to interrogate complex and suspect messages carefully without troubling
most senders. The overwhelming majority of non-bulk legitimate email
can be cleared very fast, no matter how intensively you examine it,
because it simply isn't that complex.
If you are not taking minutes to filter every message asynchronously
(after which you can only reasonably deliver what you think is spam into
a spam folder) then doing as good a job synchronously and rejecting mail
deemed to be spam wouldn't mean taking minutes for every message.
However, if you have useful filtering tactics that literally take a
minute for some messages, that shouldn't be considered lethal no matter
how much it makes a few senders whine.
And I should note that I'm not trying to be prescriptive for behemoth
freemail/freemail+ providers. I have a hard time avoiding the use of the
generic 2nd person so this is not about YOU, Brandon Long, Google
Incarnate... Spam foldering and other flavors of mail limbo may well be
the only feasible choice at Google/MS scale but most mail operators are
nowhere near that scale and should not fall into the trap of mimicking
service patterns that are ultimately rooted in scaling problems.
[...]
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.
You might be surprised...
But that's a digression. I did not say attachments should be absolutely
prohibited on any mail system, and I don't believe they can or should
be. I said that most mail providers can and should avoid some of the
most demanding filtering tasks by being willing to break some edge
cases, offer workarounds, and use the teachable moments that breakage
offers.
Note that Google & MS already have such workarounds in operation. Your
smartest paying customers who care about governance are already using
them in preference to tossing around files in email. I am just glad
(because I still need to earn a living...) that Google & MS have not
recognized that services which people eagerly pay for that have great
economies of scale can be used as leverage to raise the quality of a
service that everyone has mostly conceded to always kinda suck (but at
least it's cheap...)
[...]
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.
I am acutely aware of that, it is central to my argument. For many years
I have worked for businesses that could loosely be called competitors to
GSuite and O365. I know from doing it that limbo-free email can be done
well enough (minimal bad mail being delivered or good mail being
rejected) that paying users will come to prefer it over freemail-like
service. That service model lacks significant economies of scale (and
arguably has net diseconomies of scale,) but by the most objective
metrics of value it is a better service model than that of the
behemoths.
--
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
