I just don't think this is practical. 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. 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.
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. Even without these things, often we aren't sure that something's spam, so we rely on the folks always checking their email and clicking spam to inform us on messages we've already received but haven't been looked at yet. Those also mean, there's no saying its rejected even if we put the message in the spam folder. As for having a log, GSuite has an email log the admins can search, but we don't have anything for consumers. We considered it a couple times, but it would require a lot of extra transactions against user's mailboxes to store them, and we have cases like spammers sending us 10s of billions of spam messages just trying to get into the spam folder, though I'm not sure if that's an argument for or against (10B messages gets 1M messages in the spam folder which gets 10k users clicking through and viewing the website that's paying them to get traffic). This means there are days where SMTP time rejections peak at 80+% of mail, so logging those to user's mailboxes is not a light weight issue. As for user's controlling their own filters, our filters all use feedback from individual users to inform the per user policies, and the overall policies. I don't think the vast majority of users want to deal with any of it. As for ESPs, those on this thread may be the "good" ones, but there are plenty of bad ones too. Honestly, the majority of the anti-spam fighting goes to trying to stop the blatant spammers who are continuously testing us and looking for holes, and the secondary is on mopping up the effects of those new rules, ML signals and models on the ESPs and the smaller senders... though there are many more efforts on anti-phishing and anti-malware these days than even anti-spam, but that may be a more local decision. Also, there's just so much promotional mail that people want to see... and the answer is pretty small. Each sender seems to view their campaign as if it exists in a vacuum, but in reality folks are getting deluged in this stuff, and it just makes the whole email system less valuable. You want an incentive for the big mailbox providers? Making email stay relevant when the youngsters have all moved to various walled garden messaging services, and the problems with spam and marketing are one of the big issues. Brandon On Fri, Apr 19, 2019 at 5:16 AM Rich Kulawiec <r...@gsp.org> wrote: > On Thu, Apr 18, 2019 at 11:48:29PM +0100, Chris Woods wrote: > > I operate web services and mail servers for a small number of commercial > > clients, and the opaque (and seemingly erratic) classification criteria > for > > emails is causing me sleepless nights at the moment. > > [ My comments are generic. They're in a thread about outlook.com but > they are intended much more widely. ---rsk ] > > That's because it's a worst practice in mail systems engineering -- > an anti-pattern, if you will. It is, as you describe, opaque and > erratic, and this in turn creates a cascade of problems for everyone: > senders, recipients, mail system operators. > > Best practice is to accept/reject messages only. No classification, > no quarantining, no "spam folders", none of that. This provides > transparency to everyone: mail system operators on both sides can see > exactly what happened and (provided the rejection message is sensible) > why and (provided RFC 2142 role addresses exist and are properly > monitored/dealt with in a timely manner) seek resolution of the issue. > It also provides transparency to users and avoids all of the wasted > time and energy that goes into "I didn't get it" "But I sent it" "Well I > didn't get it, send it again" "I sent it again" "I still didn't get it" > and the myriad variations on that theme. > > Of course mistakes will be made in doing so: mistakes are *already* > being made. The problem now is that those mistakes are being made in the > dark where nobody can see them, thus nobody can ascertain what they are, > diagnose them, and fix them. Those mistakes need to be made in the open > so that everyone can see them -- and so that their visibility renders > them amendable to diagnosis and solution. > > A review of traffic on this mailing list (as well as others) with this > in mind will reveal that a lot of the issues raised are being raised > because of this worst practice. An enormous amount of time and energy > has been expended by mail system operators attempting to compensate > for this *even though they're not the ones doing it*. And that likely > pales into insignificance compared to the aggregate sender/recipient > time spent trying to detect, diagnose, and work around issues that they > likely don't understand. > > Some of us knew that doing anything other than accept/reject was a > very bad idea many years ago. Everyone should know it now. It has > become obvious on inspection by even the casual observer. > > ---rsk > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
