From: <sup...@gm...> - 2023-07-29 11:35:21
|
You can just see how this happened and how the language of it ("advanced threat protection" "dynamic delivery" and complicated diagrams, multiple servers, cloud based previews, a liberal smattering of technical BS) is designed to leveraging $2/month per user out of IT middle managers for a faux product which simply involves turning virus scanning into theatre. The cost for large organisation runs to $millions per year for these theatrics. The upshot for me is that turning it off (on the grounds that it doesn't work and is simply fluff) doesn't look likely because someone will have to admit they were beguiled by this nonsense. Also the idea that the email gets through instantly is also illusory - a little benchmarking shows that handling all this (scanning, stripping, previews etc) is not much faster than scanning the payload anyway. Anyway - I will try to find a practical fix - if there is a simple way to do a timed "keep" can someone let me know? On Saturday, 29 July 2023 10:11:34 BST Matthias Andree wrote: > Am 29.07.23 um 10:30 schrieb sup...@gm...: > > It is very poorly documented - it also seems a daft amount of work to make something that should be hidden from the end user visible. I cannot see any tangible benefit other than, "useless gimic marketing bollocks". > > > > I will try the --keep option and observe what I get - it occurs to me that one option work simply be to "keep" for a limited time period and delete older messages. Based on observations of the propagation delay, keeping for 1 hour would probably save 99% of attachments. However, I understand that some part of the triage of these attachments can involve a human in the loop for a small number of attachments so maybe simply keeping for 24 hours would restore full functionality without requiring maintenance. > > > > I think that handling the dummy email (and possible duplicates) is easily done downstream (eg I can filter the dummy email out so I never see it). > I was thinking more along the lines "if we can match the headers > against a regular expression to just skip the message..." > > Changing the server delivery policy to "replace" instead of "dynamic" appears to be the ideal solution but someone somewhere has gotten very excited by this so I'm not holding my breath. > > You might think that the tenant paying Microsoft services were in > control of that switch. > Of course if they pay money to get rid of their own thinking, poking the > too-lazy-to-think payer is vain endeavour. Hope I am not stepping on > anyone's toes here, but then again such entities are usually robust > enough to not care about outsider's opinions... > I understand that in larger organizations the bodies passing such > outsourcing decisions are not necessary aware or interested in what > individuals think and are more in a "we have the broader view and know > better what is best" attitude. Then you are trapped between the > proverbial rock and the hard place. > > I am wondering why people would believe e-mail was real-time > communication to make this necessary. Spam killed the real-time aspect > decades ago, and if they take an hour to scan anything else but a zip > bomb, something's wrong with the scanner. > > > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users > |