Mark Rousell <mark.rous...@signal100.com> wrote: >> But once you accept a >> message with a success status after the DATA stage, you are obliged to >> either really deliver it or else bounce it back. It is not acceptable to >> send messages down a "black hole".
> This *should* not be acceptable (and it's very annoying if you are a > legitimate sender who has his email swallowed like this) but this method > works well for the big mail service providers, who all seem to do it. Yes, it's the default because it's easy to do - so if you can get away with it then why put the effort into doing it right ? While all the software bits are there (or would be trivial for the big players to write if they didn't already exist), the main reason for "accept then bin" operation is scalability. Accepting mail is fairly cheap - a handshake and some preliminary (cheap) checks, then pour a data stream into a file, job done. So scaling mail acceptance is easy and cheap to do. Doing full malware & spam filtering is resource intensive. If you want to do it in real-time before deciding whether to accept a message or not, then you need to scale your resources for peak inbound mail rates. But if you do "accept then bin", you can scale your resources for more average rates and just let messages sit in a queue for a few minutes when things are really busy. Given the resources available to MS and Google (to name just two), that's not really a valid excuse - but I bet it's one of the ones they use. As an aside, many of the "how to setup Postfix with spam/AV scanning" all do the two postfix instance setup - where one instance accept the mail, then pipes the messages through Amavis with SMTP, and then the second instance manages it into mailboxes. > Many of their users don't even care that, as a result, they are missing mail > from legitimate contact and customers. > > You'd think that customer pressure would force the service providers to act > more sensibly but because the customers don't *see* the problem they don't > care about it, even small business customers who lose business as a result. That's the problem - it's mostly invisible. Take the likely scenario - customer emails to say "I'd like to spend money with you on ..." and gets no answer. Unless you really have a very compelling offering, the prospective customer just goes off elsewhere and you never know that you've lost business. I'm sure that a great many businesses would complain, and loudly, if they actually knew. One thing I can be sure of, if Royal Mail (or whoever your local postal service is) "just binned" anything that their algorithms decided you weren't likely to want, there would be more than just strong words about it. In many jurisdictions, it's a criminal offence to interfere with delivery of a mail item. At a previous job I had responsibility for running a mail server for our clients. Initially it was a thrown together quickly system (Debian/Postfix/PostfixAdmin/Courier) to replace an iMail system running on Windows NT that a) fell over regularly, and b) had a huge problem with spam. That iteration ran for years, until I replaced it with an upgraded one - and I put in effort to reject spam BEFORE accepting a message. As far as I concerned, if your mail server responds with "OK, I've accepted that" at the end of a message then you have only one choice - to deliver it. I made a point of pointing out that our mail service would not fail to deliver a message that had been accepted for delivery. I duplicated the same setup at home for my own server. As part of the rundown of services before I was made redundant, my employer was busy selling people onto O365 - and at no time would the customer be told about O365's dirty secret, that it will throw away some of your main and you'll never know unless the sender contacts you via a different means. Clients were also told that there was no GDPR problem for them to consider at all - even though anyone with 2 brain cells to rub together can explain the many ways in which O365 is fundamentally incompatible with GDPR, but that's a different thread altogether. Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
