Obviously your hoster (or you) have a very restrictive MX policy, so I received:
Message rejected due to local policy. Please visit
https://dotplex.com/postmaster (in reply to end of DATA command)
No hard feelings, but it appears more and more big MX hosters do that and thereby effectively force anyone with their own (even hardened) MX to sign up to some big service. Which in my book is a privacy concern.
Would be cool, if you could address this. Thanks.
PS: visiting that website from the message makes me feel rather offended, though, because they’re writing of “including our internal spam ID”. Uhm, I wrote an email. It wasn’t spam.
This email policy doesn’t force you to use a big service. Instead it’s sufficient to properly configure your email server. Without knowing details about your particular case I can’t tell more. Often it’s a wrongly configured IPv6 setting. The policy is motivated to avoid spam.
To me, this sounds like a mighty bold statement, considering that e.g. even c’t (quite renowned German computer & technology magazine) recently had a quite hard time figuring out why Google blocked their emails (German link: Google stufte ct.de als Spamschleuder ein | heise online).
If you’re not able to set up your mx properly I can recommend you tutanota, it’s not one of the big services, privacy respecting, secure, very affordable and reliable.
Why thank you! I am hosting my own MX for over 20 years by now, so I have a little experience. This doesn’t rule out misconfigurations, certainly.
But I would rather expect this not to be a misconfiguration but one of the dreaded cases of “IP range” reputation. Which sucks in a day and age when IPs cost plenty money and therefore if you don’t actually decide to to “rent” an IP range, and you have an IP within an existing range, no one gives a rat’s a… about you having a properly configured MX, on account of the “neighbors”.
With 20 years of running your own mail service I’m pretty sure this isn’t the first time your mails haven’t been delivered.
I didn’t mean to offend you because I know how hard it is to run a self hosted mail service reliably. I tried it many many years ago myself and decided it’s not worth the hassle in the end.
Unfortunately a lot of crap and scams are being delivered via mail, so it’s hard to blame mail providers if they put heavy restrictions in place to prevent some of that garbage
I respectfully disagree - it is the right thing to blame mail providers if they cannot figure out why the email has been blocked. We end up in a nightmare if we set up piles of technology and nobody can tell why this works or does not work.
Reputation-based systems are especially difficult to handle, but I have seen successful cases where such a system could have been checked and the cause of the rejection identified.
In this particular case, Nitrokey should be able to figure out why the email is rejected if their paying customer is asking.
Indeed, you are right it’s not the first time and probably won’t be the last. Alas, sometimes the error messages (both in the log and/or the bounce notification) are considerably more useful than in this case and actually help to figure out what’s wrong.
And guess what: the message in the log is verbatim the same as in the bounce notification. Not much of a surprise here. But what is it you expect me to deduce from this rather generic error message, @cntrl? I seem to be missing something rather obvious here.
The mail finally got through after contacting dotplex.com. So the immediate issue is resolved. But of course it bugs me that claims of a wrong configuration – again, this may full well be the case, since mail hosting gets more complicated by the year – are circulating, but no helpful clue as to what triggered the policy is provided. Now IPv6 is a clue, but I don’t offer that SMTP on IPv6 (so far) and my MTA was contacting the remote MTA via IPv4 andno AAAA record for the respective host name exists for “mailname”. So not sure how that is wrongly configured. Is that something you deem a wrong configuration, @jan? My suspicion is that there is some policy that states roughly something along the lines of: make a PTR lookup of the connecting IP, then resolve the retrieved name back and then see if those IPs (yes, in that case you’d get IPv4 + IPv6!) provide SMTP (or are listed as MX). But is that it? Something else? No idea. And it’d be a bit far-fetched to assume that a service – not advertised for a given protocol – must be provided for that protocol. So I’m none the wiser.
