My friend has lost the ability to send me messages. I’m using fastmail and it appears fastmail is using abusix. Consequently:
https://app.abusix.com/lookup/results?q=37.27.110.153
When I query dns, I get a different IP address that is considered clean. I have another friend using nine.testrun.org who can still message me.
It seems like the operators of nine.testrun.org need to either clear their name with abusix, or potentially investigate suspicious activity at that specific server.
Incidentally… I figured “this might be a good time to try out adding a chatmail relay to my account”.
But I was unable to do so because it’s incompatible with “show classic mail only for accepted contacts”.
Why is that? Surely chatmail has nothing to do with classic mail, why would I need to disable that?
Update: gmail is now blocking this IP too.
This requirement will be removed since version 2.41.0.
Said problems started after switching hosts, so maybe somebody forgot to update certain parts of the server configuration. Such error messages started to accumulate after the replacement, possibly contributing to being reported to more and more spam databases:
host mxs.ukr.net[212.42.75.251] said: 554 5.5.0 SPF pass is mandatory for 37.27.110.153 as ...@nine.testrun.org [un.20260211.GWmyErrPor] (in reply to MAIL FROM command)
host prefect.tmp.si[188.166.99.156] said: 550 5.7.25 Client host rejected: cannot find your hostname, [37.27.110.153] (in reply to RCPT TO command)
The only addresses that nine.testrun.org resolve to are 77.42.49.41 and 2a01:4f9:fff1:59::1. The IP address of the host which is sending mail to other hosts according to the above error is the Finnish 37.27.110.153. Both IP addresses seem to reverse resolve to the domain nine.testrun.org. This is a configuration error, because it fails the industry standard FCrDNS test, being eligible to be submitted to spam lists.
Most chatmail servers don’t have reverse DNS set up.
It’s therefore best to never use a regular email for DeltaChat unless you’re an expert, but rather only chatmail relays of which they are plenty. There are examples of Google and Microsoft randomly banning email servers too because they don’t understand traffic that is going on.
You assert that “most” of them do not. Could you perhaps list 2 as examples?
“SPF pass is mandatory” is an indication of misconfigured server. If the server requires SPF to pass and not just neutral, it cannot be used to accept messages from mailing lists with passing DKIM. SPF is a legacy authentication mechanism replaced by DKIM, it should not be required to pass.
Reverse DNS has nothing to do with authentication, it is a hack from the early 90s to work around proprietary UNIX software: draft-ietf-dnsop-reverse-mapping-considerations-06
The web page you linked to about “FCrDNS” is from sellers of DMARC analytics: https://www.suped.com/
It’s their job to make email authentication more complicated.
In any case, nine.testrun.org admins are notified and will do something.
But at the same time admins of the servers which cannot authenticate incoming mails with DKIM can also be notified to fix their setups.
There are some on the relay list you can check yourself. E.g. klan5.cc, nibblehole.com (has reverse DNS with similar domain but doesn’t match the MX mail server host name), chat.nuvon.app, chat.in-the.eu, …
It’s worse out in the wild for the smaller unlisted ones. The smaller it is, the less likely the relay has a reverse DNS.
The SPF record is the following:
nine.testrun.org. 1800 IN TXT “v=spf1 a:nine.testrun.org ~all”
The A record of the server is 77.42.49.41, so sending through 37.27.110.153 should produce a SOFTFAIL. I would guess that some more strict providers may promote this to a suspicious category to be combined with some other filter (e.g., rate limits and server age) to arrive at a verdict.
So, other than fixing the FCrDNS, I would also suggest fixing the SPF record as well (may not be needed depending on how you plan to fix the FCrDNS).
The only acceptable fix here is to remove spf entries, because they are useless for deltachat
The SPF record is not for enabling reception of messages by nine, it is for every other server who receives messages coming from nine, be it chatmail or not.
There is a fix for chatmail relays to use the same sending address in SMTP clients as the address in the A/AAAA record: feat(postfix): enforce sending from public IP addresses by j4n · Pull Request #845 · chatmail/relay · GitHub
We can set SPF to v=spf1 ~all, meaning SPF cannot be used to authenticate anything. But this will break compatibility with some servers that then throw “SPF pass is mandatory” error as seen above. Outlook requires SPF to pass according to this doc: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook’s-new-requirements-for-high‐volume-senders/4399730
Requiring SPF when DKIM passes is wrong, you cannot have “more authentication” when email is already authenticated, but we cannot just decide to defederate all such servers now since they have users and established chats.
I think we can mark this topic as solved.