Permanent deferral I suspect is really supposed to mean "we can't deliver right now and we don't know when but keep retrying". Deferred messages are OK if they can be retried later and that's what the MTA will try to do. I'm fairly sure they were abusing the standard with this particular technique. Also, join all the sender programmes, set reverse dns, don't let your users do things like send bulk email and that will reduce many of the problems. I would generally look for a provider that has a relatively strict acceptable use policy, and in particular doesn't allow VPN endpoints to be run from their infra for your email, to reduce the chances your IP has a terrible reputation with the big providers. Of course, if you don't set up SPF/DKIM/DMARC, or you have an IP with poor reputation (you can check the DNSBL) or worse a residential address, you will have trouble. It seems that there is a large degree of per-account spam filtering as well at the big providers mapping to individual users' preferences. Usually this simply resulted in "OK but if you do bad things we will block you no guarantee of inbox delivery etc etc etc". I don't think deliverability is that much of an issue and I was able to resolve all the problems I've had in 10+ years of doing this by emailing support, explaining myself and asking to be unblocked. I've been running email since 2011, for my own main email and a few others. I receive dmarc reports now from many providers so I've an idea what percentage of our email is quarantined or rejected (none). I ended up discussing this with their support also and after some discussion that block too was removed. For reasons known only to them, they decided that IPs they've never seen before will be blocked by returning an smtp deferral that is permanent, which is bad for legitimate mail servers because the email remains stuck in the mail queue forever. I had quite strict rules that spf failure => user's junk folder that I had to relax, but I also had a discussion with the admins at the sending company to explain the issue. The second was a sender sending to us with a misconfigured SPF policy.
At the time, they didn't bother to validate DKIM or DMARC according to their headers. The first was delivering to, but this was temporary and resolved relatively quickly: I simply contacted their support.
I also have policies that suspend logins for accounts if they send too much in a certain timeframe, because this is a pretty good indicator of account compromise. I have a dedicated server with an IP address in a datacentre, with approx 6 users using my email server for their primary email.
0 kommentar(er)
