Rspamd rejects `asciinema` e-mails about docker-mailserver HOT 45 CLOSED

Ok I thought that I'd give the mailserver.env file a quick test by passing it to the test container:
docker run --rm -it --platform linux/arm64 --env-file mailserver.env mailserver/docker-mailserver apt update

But everything works as expected so that's not the issue.

from docker-mailserver.

Can you try without Portainer? I don't know if that influences the behaviour?

It shouldn't at all. It's just a nicer way to use docker-compose as you have everything in an UI. I'll try to look into it by copying the compose file and starting it outside of Portainer.

I don't know how we could troubleshoot it further with you unless you can identify something we can actually act on?

I'll try to spin up a new container. I'll make a backup and try whether something in the volumes is messing this up by running it with the devault mailserver.env and then with mine.

from docker-mailserver.

@georglauterbach

can you post an anonymized version of such an e-mail here? I'd be curious to see one.

Of course. It's a simple email with a login link. You can also easily get one yourself by logging in/registering here: https://asciinema.org/login/new. There's no password or anything so it's not that annoying to make an account and test this out yourself.

The email (without the login token):

Welcome back!

Click the following link to log in to your asciinema.org account:

https://asciinema.org/session/new?t=<login-token-here>


If you did not initiate this request, just ignore this email. The request will expire shortly.

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mx.my.domain
	by mx.my.domain with LMTP
	id BriBOpdXS2YCegAAMGYE4w
	(envelope-from <[email protected]>)
	for <[email protected]>; Mon, 20 May 2024 16:00:55 +0200
Received: from fout3-smtp.messagingengine.com (fout3-smtp.messagingengine.com [103.168.172.146])
	by mx.my.domain (Postfix) with ESMTPS id 3C1FD2901CD5
	for <[email protected]>; Mon, 20 May 2024 16:00:55 +0200 (CEST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailfout.nyi.internal (Postfix) with ESMTP id E4C501381556
	for <[email protected]>; Mon, 20 May 2024 10:00:47 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
  by compute5.internal (MEProxy); Mon, 20 May 2024 10:00:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	hello.asciinema.org; h=cc:content-type:content-type:date:date
	:from:from:in-reply-to:mime-version:reply-to:reply-to:subject
	:subject:to:to; s=fm1; t=1716213647; x=1716300047; bh=Knun7XFdxq
	llWxxzAsFueCYLjNFjRM7+Vw2RB9DdGPs=; b=jwgYlURUOlU/n1ppl45sRHSUWb
	SOHKT8O78qcwGxQjp8hpToLA58U+QwDdG3oVDEF+SEO4di9wzBswlekcGEtLPu6F
	9BKrmiqo5HhR6F9jLH/V3M+CTCmgOZ0Q6mh1ec0Bl2JXCOm0nNCHcXxjE7Ieslo6
	QbDVZRkVfS5sT2BzUinJz/O6grk4baqYGkT2Z1zt+NFJMow05Zdq9h4oS2yvnb5I
	wxeTsT4USPYm1BC6MN0zI9UqCvjMw3fclT2HfQwWgEChGm3VYfNT63PVeDBa10od
	C1+dKc5U7Lm/Plt1XzPfKulTMngRmc8YrfQ/IHmAV3zJjsqiSMBNSU4U7pDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=cc:content-type:content-type:date:date
	:feedback-id:feedback-id:from:from:in-reply-to:mime-version
	:reply-to:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
	:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1716213647; x=
	1716300047; bh=Knun7XFdxqllWxxzAsFueCYLjNFjRM7+Vw2RB9DdGPs=; b=T
	8RrVARKFp0WKiAvwuPCc7GFYjZCHLCgiU/9AC5+4msfZuWR6W22yHzcYYFCEN2oJ
	pcU02lGGBSikwrLrLwzLOeowfe4V2BphZKzFbWoDTzAUwxHtOHMkuGfBDaj6U3Ms
	N9ciVnVVidUqnGKwPLRw5us7Halsc+H+cXu9eQlT3rIsDIEW/Nc8oNT2Jwj3WPai
	9KYZzZNS50VVT+v4kil+KfOaN6jSrKI2BgImt2i99qAZCNCAAJf5EUOSbGrWyXzZ
	BicOgu7lQbBxshgryAso41tjFNykoHTB8PrXDN8zCVhPENdb+45zcNDtKDTMcoFQ
	BcRFOrvpXs0FNeC6U5PWA==
X-ME-Sender: <xms:jldLZp6nkhxVsF8B19i4WQYqc-xD1RTVEt1i9lNnZr4Dz8Lso8CcdQ>
    <xme:jldLZm5up75w36ltx-5Jc25rHd6NgXhSVmycNZq1Lb-kOdZR35WK9gk71gomV7Wqh
    LNMUTY8p3kGerbbf5g>
X-ME-Received: <xmr:jldLZgcxScMTilypDGWgYQsyxoarTJSmZMNxMdJSAnYD8MnRfnkwaRVrX47I0I7zPTenBdCvM-GZtQDK2S-310hLpbKeyemgYvit>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeitddggeeiucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpefuhffvffhrgggtsehmtddtredttd
    ejnecuhfhrohhmpegrshgtihhinhgvmhgruceohhgvlhhloheshhgvlhhlohdrrghstghi
    ihhnvghmrgdrohhrgheqnecuggftrfgrthhtvghrnhepveffjeetuefgleeuieevveetve
    ehleeuvdfgtdevtefftdekueevgfejkeevhfdvnecuffhomhgrihhnpegrshgtihhinhgv
    mhgrrdhorhhgnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrh
    homhephhgvlhhloheshhgvlhhlohdrrghstghiihhnvghmrgdrohhrgh
X-ME-Proxy: <xmx:jldLZiKWjXEa_asRyBU5LGcY0n9DNvdCUzuNk1umGJuVS7-aw9yE5w>
    <xmx:jldLZtI8x63nIx5Z72ZgLdQ4XULamv3ZkFlFQcbfT9kEWKFWwVPqyw>
    <xmx:jldLZrwt-Kyl3JgQLhlJrmkkS2sQMx2LoNkQAnSYTeTIwyqNxYHw7A>
    <xmx:jldLZpLyr0JBguevSDg53b_X5IutnGEbfGc6TGfVsY2D_iMGukAt6g>
    <xmx:j1dLZriDwH_sYVk0jY214mqsQynY3xsji5fD1zXw3qhpWwm-kE5mDTYd>
Feedback-ID: i39a149d2:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <[email protected]>;
 Mon, 20 May 2024 10:00:46 -0400 (EDT)
Subject: =?UTF-8?B?TG9naW4gdG8gYXNjaWluZW1hLm9yZw==?=
From: =?UTF-8?B?YXNjaWluZW1h?= <[email protected]>
To: [email protected]
Date: Mon, 20 May 2024 14:00:45 +0000
Reply-To: [email protected]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_3837186536_2557352301.3238294641"
X-Rspamd-Queue-Id: 3C1FD2901CD5
X-Rspamd-Server: edb8408fe457
X-Spamd-Result: default: False [6.89 / 11.00];
	MISSING_MID(2.50)[];
	SUBJ_EXCESS_BASE64(1.50)[];
	FROM_EXCESS_BASE64(1.50)[];
	DMARC_NA(1.00)[asciinema.org];
	MIME_BASE64_TEXT_BOGUS(1.00)[];
	R_SPF_ALLOW(-1.00)[+ip4:103.168.172.128/27];
	CTYPE_MIXED_BOGUS(1.00)[];
	R_DKIM_ALLOW(-1.00)[hello.asciinema.org:s=fm1,messagingengine.com:s=fm1];
	HFILTER_URL_ONLY(0.39)[0.17763157894737];
	MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	RCVD_COUNT_THREE(0.00)[3];
	GREYLIST(0.00)[pass,meta];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~];
	RCVD_TLS_LAST(0.00)[];
	FROM_HAS_DN(0.00)[];
	REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[[email protected]];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MISSING_XM_UA(0.00)[];
	ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US];
	DKIM_TRACE(0.00)[hello.asciinema.org:+,messagingengine.com:+];
	HAS_REPLYTO(0.00)[[email protected]]
X-Rspamd-Action: add header
X-Spam: Yes

------=_Part_3837186536_2557352301.3238294641
Content-Type: multipart/alternative; boundary="----=_Part_2649317485_3238082434.1923471972"

------=_Part_2649317485_3238082434.1923471972
Content-Type: text/plain;charset=UTF-8

Welcome back!

Click the following link to log in to your asciinema.org account:

https://asciinema.org/session/new?t=<login-token-here>


If you did not initiate this request, just ignore this email. The request will expire shortly.

------=_Part_2649317485_3238082434.1923471972
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEgY2hhcnNldD0idXRmLTgi
PgogIDwvaGVhZD4KICA8Ym9keT4KPHA+V2VsY29tZSBiYWNrITwvcD4KCjxwPkNsaWNrIHRoZSBm
b2xsb3dpbmcgbGluayB0byBsb2cgaW4gdG8geW91ciBhc2NpaW5lbWEub3JnIGFjY291bnQ6PC9w
PgoKPHA+PGEgaHJlZj0iaHR0cHM6Ly9hc2NpaW5lbWEub3JnL3Nlc3Npb24vbmV3P3Q9U0ZNeU5U
WS5nMmdEYUFKaUFBTnNRbUptU25iNGJnWUFQXzlObG84QllnQUJVWUEuSnAxUVdRS1RSUm5ELXNS
dXJWcllLWFpRdzN1Smg3RzhTNG9RT2tMb3pKZyI+aHR0cHM6Ly9hc2NpaW5lbWEub3JnL3Nlc3Np
b24vbmV3P3Q9U0ZNeU5UWS5nMmdEYUFKaUFBTnNRbUptU25iNGJnWUFQXzlObG84QllnQUJVWUEu
SnAxUVdRS1RSUm5ELXNSdXJWcllLWFpRdzN1Smg3RzhTNG9RT2tMb3pKZzwvYT48L3A+Cgo8cD4K
ICA8YnI+CiAgSWYgeW91IGRpZCBub3QgaW5pdGlhdGUgdGhpcyByZXF1ZXN0LCBqdXN0IGlnbm9y
ZSB0aGlzIGVtYWlsLiBUaGUgcmVxdWVzdCB3aWxsIGV4cGlyZSBzaG9ydGx5Lgo8L3A+CgogIDwv
Ym9keT4KPC9odG1sPg==
------=_Part_2649317485_3238082434.1923471972--
------=_Part_3837186536_2557352301.3238294641--

from docker-mailserver.

Could you please try reproduce the failure with the :edge image? There was some rspamd fixes there that may have already addressed this.

from docker-mailserver.

Please have a look at the Rspamd log (our Rspamd docs describe the location) and see how such a score came to be. Post the result here, please.

I suspect a (temporary) DNS issue. A hostname mismatch causes a +6 in the spam score.

Why? Because of

warning: hostname wfhigh3-smtp.messagingengine.com does not resolve to address 64.147.123.154

wfhigh3-smtp.messagingengine.com does resolve to 64.147.123.154. Reverse-DNS checks out, too.

DNS is, in my experience, the most frequent source of errors. We have a dedicated section in our docs on this issue as well (with a big warning and error admonitions).

from docker-mailserver.

Exactly what I predicted: HFILTER_HOSTNAME_UNKNOWN means DNS didn't work at the time of filtering the message. That's a common issue, but it means your setup is working fine per se. You probably need to double-check your DNS servers.

from docker-mailserver.

One gotcha you can run into is the default DNS used fails (using q within a container):

The command you supplied doesn't work as there's no arm64 image. Also the repositoried in DMS image are broken so I cannot install q in the container.

While setting the container DNS to use cloudflare 1.1.1.1 works:
$ docker run --rm -it --dns 1.1.1.1 ghcr.io/natesales/q -v -x 64.147.123.154

I"ve set the container to use Cloudflare:

    dns:
      - 1.1.1.1
      - 1.0.0.1

I also recall Docker in the past year had a bug with a release with DNS too. I don't recall specifics, but it might help to ensure you're using the latest Docker + Docker Compose if a DNS issue remains.

I think I encountered it, that's why I have manually set 1.1.1.1 on some containers.

docker exec -it dms-container-name dig -x 64.147.123.154 should confirm it

root@mx:/# dig -x 64.147.123.154

; <<>> DiG 9.18.24-1-Debian <<>> -x 64.147.123.154
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;154.123.147.64.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
154.123.147.64.in-addr.arpa. 3600 IN    PTR     wfhigh3-smtp.messagingengine.com.

;; Query time: 2787 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Thu May 09 11:46:09 CEST 2024
;; MSG SIZE  rcvd: 102

You could try disabling the check temporarily via rspamd config perhaps?

I'd rather not. I don't know hot that config works and I don't like running "specialized" setups that I have to fix every major release.

from docker-mailserver.

apt update is needed before you can use apt install in the container.

I know but

root@mx:/# apt update
Err:1 http://rspamd.com/apt-stable bookworm InRelease
  409  Conflict [IP: 188.114.96.9 80]
Err:2 http://deb.debian.org/debian bookworm InRelease
  530   [IP: 188.114.96.9 80]
Err:3 http://deb.debian.org/debian bookworm-updates InRelease
  530   [IP: 188.114.96.9 80]
Err:4 http://deb.debian.org/debian-security bookworm-security InRelease
  530   [IP: 188.114.96.9 80]
Reading package lists... Done
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
E: The repository 'http://rspamd.com/apt-stable bookworm InRelease' is not signed.
E: Failed to fetch http://rspamd.com/apt-stable/dists/bookworm/InRelease  409  Conflict [IP: 188.114.96.9 80]
N: See apt-secure(8) manpage for repository creation and user configuration details.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.
E: Failed to fetch http://deb.debian.org/debian/dists/bookworm/InRelease  530   [IP: 188.114.96.9 80]
E: Failed to fetch http://deb.debian.org/debian/dists/bookworm-updates/InRelease  530   [IP: 188.114.96.9 80]
E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Failed to fetch http://deb.debian.org/debian-security/dists/bookworm-security/InRelease  530   [IP: 188.114.96.9 80]
E: The repository 'http://deb.debian.org/debian-security bookworm-security InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Could you chime in with what version of Docker and Docker Compose you're running?

I use the v2 plugin, not the old binary:

❯ docker compose version
Docker Compose version v2.27.0

If you really want to push it along without tackling that yourself, it may help if you can reproduce it between two DMS container instances which allows for isolating into an offline environment fully under our control. I understand if that's too much hassle, but I'm also a bit surprised no one else is reporting similar issues 🤔

If you'd help me set up such environment I'll gladly do so. I'm not that familiar with mailservers (that's why I use DMS) but I'm happy to help.

I'm also a bit surprised no one else is reporting similar issues

AFAIK not that many people use asciinema. I reckon that a pretty small number of people that

1. Use asciinema
2. Use it with their own mail server
3. Use DMS
4. Use it with rspamd

from docker-mailserver.

Ok, I managed to setup spamassassin and opendkim. Opendkim even has my old key now (luckily it's not that hard to follow the files and the config) so I'm set up without any issues now.

I have both .env files so I can easily switch between them for testing. I'll be running spamassassin now, switching to rspamd only for testing and once it's fixed (I'd like to have the more lightweight thing).

from docker-mailserver.

Try recreating the container?

That was one of the first things I tried but I can try again. I tried to update the container (this recreates it in Portainer), then it was recreated when I switched to edge from latest.

when I used Docker in VMs that I suspended, the containers would lose network connectivity upon restoring the VM

This system does not suspend at all. It's a Raspberry Pi working 24/7 (I did update and restart it during these issues just in case there was something with the system).

from docker-mailserver.

In your containers, can you please run

$ rspamadm configdump options | grep -A 10 -F 'dns {'

to verify which DNS servers Rspamd is using. I also need

$ cat /etc/apt/sources.list.d/rspamd.list

and the contents of what is in the signedby= section, probably /etc/apt/trusted.gpg.d/rspamd.gpg. I'd also like to know what /etc/resolv.conf contains as well, just to double-check.

I don't think so because it's fine until I run it in my production container.

TBH that would indicate network problems in your production container.

Using SA + OpenDKIM works now because SA is simply not performing the reverse-DNS-mismatch check this way (it does, but it does not add as much weight IIRC). Still, this is not necessarily a Rspamd problem.

from docker-mailserver.

That's not the first message that belongs to this e-mail (denoted by the "too early"). Can you search for the first and show me?

The too early message was because I created a new login that sent a new email not because the mailserver resent it before the greylist period expired. The greylist since expired and I receive the emails now. It's in spam with a score of 6.11 though. I'll see why that is and whether there's something to do about that. Maybe it's just because there were so many of what is basically the same email.

What happens if you set both, hostname: and OVERRIDE_HOSTNAME? Technically, what you're experiencing shouldn't happen, als both options should be equivalent 🤔

They are not equivalent since the docker option modifies the network/DNS server of the container while OVERRIDE_HOSTNAME is an option inside the container that does not modify the networking.

I can try it once I have some free time.

from docker-mailserver.

Hi,
I got into the WebUI of rspamd and I got some reasons for why was asciinema greylisted.

Here's the report:

MISSING_MID (2.5)
FROM_EXCESS_BASE64 (1.5)
SUBJ_EXCESS_BASE64 (1.5)
MIME_BASE64_TEXT_BOGUS (1)
DMARC_NA (1) [asciinema.org]
CTYPE_MIXED_BOGUS (1)
HFILTER_URL_ONLY (0.390789) [0.17763157894737]
MIME_BASE64_TEXT (0.1)
DKIM_TRACE (0) [hello.asciinema.org:+,messagingengine.com:+]
REPLYTO_DOM_NEQ_FROM_DOM (0)
ARC_NA (0)
MISSING_XM_UA (0)
MIME_TRACE (0) [0:+,1:+,2:+,3:~]
RCVD_COUNT_THREE (0) [3]
TO_MATCH_ENVRCPT_ALL (0)
GREYLIST (0) [greylisted,Sun, 19 May 2024 22:00:55 GMT,new record]
FROM_HAS_DN (0)
TO_DN_NONE (0)
ASN (0) [asn:209242, ipnet:103.168.172.0/24, country:US]
PREVIOUSLY_DELIVERED (0) [[email protected]]
HAS_REPLYTO (0) [[email protected]]
FROM_EQ_ENVFROM (0)
RCVD_TLS_LAST (0)
RCPT_COUNT_ONE (0) [1]
RCVD_VIA_SMTP_AUTH (0)
MIME_GOOD (-0.1) [multipart/mixed,multipart/alternative,text/plain]
R_SPF_ALLOW (-1) [+ip4:103.168.172.128/27]
R_DKIM_ALLOW (-1) [hello.asciinema.org:s=fm1,messagingengine.com:s=fm1]

The email was resent and recieved in spam after the greylist expired.

from docker-mailserver.

Indeed, this is because my.domain has not DNS<->rDNS match :)

So it is local only? Now that I think of it though my DNS is one domain (the intended one) and the rDNS is a subdomain of my isp with the internal ip in it. How can I check whether that issue exists outside local emails?

That's a formidable idea! If you can, also mention the missing Message-ID header and the weird Base64 stuff. You can link to this issue and possibly to comments as well.

I already prepared the issue and I linked to your comment where you explained the issues which I think you did pretty well. The issue is on my laptop though so I'll post it later (on my phone RN).

from docker-mailserver.

Sounds cool for testing but that would not solve that my public domain has a rDNS something like ip-10-222-16-4.myisp.com instead of my domain.

Depending on who you ask, this is either not serious at all, or a deal-breaker. If you ask me, I think it's awful, and there is likely noting you can do when relying on an ISP. The ISP will not set a proper rDNS for you (kind of understandable).

I want to give a brief explanation of my point of view. In my main.cf, I have

smtpd_sender_restrictions_default =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unknown_reverse_client_hostname
    reject_unknown_sender_domain
    permit

Either you are in mynetworks or authenticated; otherwise you are checked. The first check, reject_unknown_reverse_client_hostname will reject the request "when the client IP address has no address -> name mapping". If you do not have a PTR entry, you are rejected; you'd not be rejected here.

Others may use reject_unknown_client_hostname, though. This is way stricter. According to the Postfix docs, this check rejects requests if

1. the client IP address->name mapping fails, or
2. the name->address mapping fails, or
3. the name->address mapping does not match the client IP address.

"This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above." At this point, you're done, and your mail would be rejected.

Now, reject_unknown_client_hostname is tricky. You are very strict, but you risk loosing legitimate e-mails. Hence, most people use reject_unknown_reverse_client_hostname and let anti-spam measures evaluate the fact that your rDNS may not exist (very bad), or that your rDNS may not match (bad). This increases your score, and hence the likelyhood of being greylisted, marked as spam, etc. - you name it.

That being said, there is more to it. For example, whether the assumption that illegitimate e-mails have not PTR record still holds up in 2024. Depending on the link you click on, you get different answers.

Because asciinema/asciinema-server#445 is resolved upstream, I will also close this issue. If you'd like to go on with the discussion, feel free to use our discussions :)

from docker-mailserver.

Thanks for all your suggestions, help and explanations.

Honestly I didn't realize this was still open.

from docker-mailserver.

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

It appears that the email from [email protected] was rejected by your mail server due to rspamd classifying it as spam. This is indicated by the log entry milter-reject: END-OF-MESSAGE from unknown[64.147.123.154]: 5.7.1 Spam message rejected.

To address this issue, you can adjust the rspamd settings to prevent legitimate emails from being rejected as spam. Here are a few steps you can take:

1. Whitelist the Sender or Domain:
   You can whitelist the sender's email address or the entire domain to ensure that emails from asciinema.org are not marked as spam. This can be done by modifying the rspamd configuration to add the sender to a whitelist.

2. Adjust Spam Threshold:
   Check the current spam threshold settings in rspamd and consider adjusting them if they are too strict. This might help in reducing false positives.

3. Review rspamd Logs:
   Review the detailed rspamd logs to understand why the email was classified as spam. This might provide insights into specific rules or characteristics that triggered the spam classification.

4. Update rspamd Rules:
   Ensure that your rspamd rules are up-to-date. Sometimes, updating or tweaking the rules can improve the accuracy of spam detection.

5. Test Changes:
   After making changes, send test emails from asciinema.org to verify that they are no longer rejected.

For specific instructions on how to configure rspamd settings, you can refer to the rspamd documentation or the configuration files used in your Docker Mail Server setup.

This comment was generated by Glime.

from docker-mailserver.

I switched to edge but still no luck:

2024-05-08T11:39:07.341977+02:00 mx postfix/cleanup[1392]: A6CAF29005EA: milter-reject: END-OF-MESSAGE from unknown[64.147.123.154]: 5.7.1 Spam message rejected; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<wfhigh3-smtp.messagingengine.com>

from docker-mailserver.

I've ran asciinema through https://www.mail-tester.com/ and it got 10/10 so it shouldn't be a configuration issue on their end. Also Gmail accepts the email and so does my other email provider. Only my server has issues with this.

Is this some kind of a configuration issue? I have not seen a single email in my spam folder I think. It looks like Spam emails are just rejected instead of moved. I know that Spam score 11 means email not received but IDK why only my instance would score their emails like that.

Also I see that some emails have a spam score - eg. a Github Education email had 5.74. But again - I haven't seen a single email moved to Spam so it looks like everything considered spam is rejected.

from docker-mailserver.

Could this be an issue with the greylisting module or hfilter?

from docker-mailserver.

env_file: stack.env

• You should probably share relevant config from this file. Don't bother with any defaults, keep it minimal.
• Likewise, if you have any relevant config you've created/modified in the config volume ./docker-data/dms/config/:/tmp/docker-mailserver/.

SSL_DOMAIN: mx.example.com

Remove this ENV unless you have a good reason for it? It's not something DMS uses. Our TLS setup docs with Traefik had not been updated for some time regarding that info, v14 (edge docs) has cleaned that up:

But I see that I missed it in the example compose.yaml, so I'll go fix that up 😅

EDIT: The scripts actually still use this it seems, and without having the time to verify we can drop that ENV (I'm pretty sure it was fine to in the past) I'll hold off from making that change for now.

aarch64

I've heard that the ARM rspamd has been iffy in the past, not sure if it's relevant here since it's about spam score rather than anything crashing.

Log: warning: hostname wfhigh3-smtp.messagingengine.com does not resolve to address 64.147.123.154

milter-reject: END-OF-MESSAGE from unknown[64.147.123.154]: 5.7.1 Spam message rejected; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<wfhigh3-smtp.messagingengine.com>`

That might be helpful? It's from the HELO greeting when asciinema delivered mail and was rejected as spam.

That type of mismatch with the hostname not resolving to the IP it's coming from is sometimes a security check to reject mail on or regard more likely as spam. I don't manage rspamd in DMS, so I'm not sure if it's been configured that way.

@georglauterbach will try assist if he can when he has the time to spare :)

I'm sure he'd appreciate more insight into your configuration ENV / files as it may be possible you have a misconfiguration or something about how you've configured DMS affects reproducibility.

Mostly we lack time to provide much support wise, especially when other users are not chiming in with the same issue to help pin down the cause. It's much easier for us to respond to bugs when users are able to troubleshoot the issue to narrow down where DMS is at fault.

In the meantime, you could try with our defaults instead of rspamd to see if the same issue occurs. It might help isolate if it's rspamd specific. Alternatively, mailu and mailcow projects use rspamd too IIRC, if you don't mind trying those out and letting us know if the issue occurs with another mail server rspamd deployment, that'd be insightful 👍 (if there is no issue with another mailserver using rspamd, we could probably compare configuration differences to pinpoint the problem)

from docker-mailserver.

I have no problem with switching to spamassasin and opendkim but from what I saw it was better to run rspamd as it looked easier to setup and the dkim setup was cool too.

Will there be a DKIM problem when I switch? Will I have to generate a new key and set it on my DNS?

from docker-mailserver.

Here's the related part of rspamd.log

2024-05-08 19:50:42 #1197(rspamd_proxy) <b05d9c>; proxy; rspamd_task_write_log: id: <undef>, qid: <C444D29008D8>, ip: 103.168.172.147, from: <[email protected]>, (default: T (reject): [12.39/11.00] [HFILTER_HOSTNAME_UNKNOWN(6.00){},MISSING_MID(2.50){},FROM_EXCESS_BASE64(1.50){},SUBJ_EXCESS_BASE64(1.50){},CTYPE_MIXED_BOGUS(1.00){},MIME_BASE64_TEXT_BOGUS(1.00){},R_DKIM_ALLOW(-1.00){hello.asciinema.org:s=fm3;messagingengine.com:s=fm3;},R_SPF_ALLOW(-1.00){+ip4:103.168.172.128/27;},DMARC_NA(0.50){asciinema.org;},HFILTER_URL_ONLY(0.39){0.17763157894737;},MIME_BASE64_TEXT(0.10){},MIME_GOOD(-0.10){multipart/mixed;multipart/alternative;text/plain;},ARC_NA(0.00){},ASN(0.00){asn:209242, ipnet:103.168.172.0/24, country:US;},DKIM_TRACE(0.00){hello.asciinema.org:+;messagingengine.com:+;},FROM_EQ_ENVFROM(0.00){},FROM_HAS_DN(0.00){},HAS_REPLYTO(0.00){[email protected];},MIME_TRACE(0.00){0:+;1:+;2:+;3:~;},MISSING_XM_UA(0.00){},PREVIOUSLY_DELIVERED(0.00){[email protected];},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_THREE(0.00){3;},RCVD_TLS_LAST(0.00){},RCVD_VIA_SMTP_AUTH(0.00){},REPLYTO_DOM_NEQ_FROM_DOM(0.00){},TO_DN_NONE(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 4954, time: 695.031ms, dns req: 36, digest: <3b5bd592017bdb683dc780bd08d407cf>, rcpts: <[email protected]>, mime_rcpts: <[email protected]>
2024-05-08 19:50:42 #1197(rspamd_proxy) <b05d9c>; proxy; rspamd_protocol_http_reply: regexp statistics: 0 pcre regexps scanned, 4 regexps matched, 176 regexps total, 63 regexps cached, 0B scanned using pcre, 3.33KiB scanned total

from docker-mailserver.

Ok, I've set the dns to 1.1.1.1 for the mailserver but the issue persists.

I've also checked the domain and it does resolve correctly:

warning: hostname wfout7-smtp.messagingengine.com does not resolve to address 64.147.123.150

from docker-mailserver.

Ok the MX record does not:

from docker-mailserver.

Ok, I've set the dns to 1.1.1.1 for the mailserver but the issue persists.

Just to confirm, you've got the reverse DNS resolving in the container correctly?

One gotcha you can run into is the default DNS used fails (using q within a container):

# Default DNS is via router 192.168.65.7 on this system, it always fails rDNS lookups:
$ docker run --rm -it ghcr.io/natesales/q --verbose --reverse 64.147.123.154

DEBU[0000] Name: 154.123.147.64.in-addr.arpa.
DEBU[0000] RR types: [CNAME PTR A AAAA NS MX TXT]
DEBU[0000] No server specified or Q_DEFAULT_SERVER set, using /etc/resolv.conf
DEBU[0000] found server [192.168.65.7] from /etc/resolv.conf
DEBU[0000] Server(s): [192.168.65.7]
DEBU[0000] Using server 192.168.65.7:53 with transport plain
DEBU[0000] Using UDP with TCP fallback: 192.168.65.7:53

# While setting the container DNS to use cloudflare 1.1.1.1 works:
$ docker run --rm -it --dns 1.1.1.1 ghcr.io/natesales/q -v -x 64.147.123.154

DEBU[0000] Name: 154.123.147.64.in-addr.arpa.
DEBU[0000] RR types: [AAAA NS MX TXT CNAME PTR A]
DEBU[0000] No server specified or Q_DEFAULT_SERVER set, using /etc/resolv.conf
DEBU[0000] found server [1.1.1.1] from /etc/resolv.conf
DEBU[0000] Server(s): [1.1.1.1]
DEBU[0000] Using server 1.1.1.1:53 with transport plain
DEBU[0000] Using UDP with TCP fallback: 1.1.1.1:53

154.123.147.64.in-addr.arpa. 56m6s PTR wfhigh3-smtp.messagingengine.com.

It's possible that rspamd may be configured to use something else internally (I think that's supported, but AFAIK DMS does not mess with it).

I also recall Docker in the past year had a bug with a release with DNS too. I don't recall specifics, but it might help to ensure you're using the latest Docker + Docker Compose if a DNS issue remains.

the MX record does not

I don't think MX record matters here? Here's what Postfix does (disabled in DMS by default, but I'd assume it's similar with the roughly equivalent rspamd feature being discussed?):

Docs for reference: reject_unknown_reverse_client_hostname.

reject_unknown_client_hostname:
Reject the request when any of the following is true:

1. The client IP address -> name mapping fails.
2. The name -> address mapping fails.
3. The name -> address mapping does not match the client IP address.

reject_unknown_reverse_client_hostname:
Only rule 1 applies.

• reject_unknown_client_hostname makes reject_unknown_reverse_client_hostname redundant to apply.

• If I understand correctly, it checks:

  1. A rDNS record exists (doesn't have to match HELO hostname?)
  2. HELO hostname has a DNS A record.
  3. That DNS A record resolves to the same IP making the request.

• Users could additionally configure known problematic clients to bypass the restriction via check_client_access.

I wouldn't expect this restriction to fail from reputable mail servers, but I don't run any large deployment to have such insights.

So IP =(rDNS)=> HELO =(A)=> IP should be the check.

For MX records, a common problem is when one doesn't exist causing SPF checks to fail and reject bounce the mail (common problem with mailgun apparently).

DNS queries for reference:

$ docker run --rm -it ghcr.io/natesales/q wfhigh3-smtp.messagingengine.com
wfhigh3-smtp.messagingengine.com. 26m14s A 64.147.123.154
wfhigh3-smtp.messagingengine.com. 23h38m51s TXT "v=spf1 include:spfall.messagingengine.com ~all"

$ docker run --rm -it ghcr.io/natesales/q spfall.messagingengine.com
spfall.messagingengine.com. 24h TXT "v=spf1 ip4:103.168.172.0/24 ip4:64.147.123.0/24 -all"

$ docker run --rm -it ghcr.io/natesales/q hello.asciinema.org
hello.asciinema.org. 1h MX 10 in1-smtp.messagingengine.com.
hello.asciinema.org. 1h MX 20 in2-smtp.messagingengine.com.
hello.asciinema.org. 1h TXT "v=spf1 include:spf.messagingengine.com ?all"

# `/27` subnet range for SPF is 64.147.123.128 => 64.147.123.159 (thus valid for IP above)
$ docker run --rm -it ghcr.io/natesales/q spf.messagingengine.com
spf.messagingengine.com. 24h TXT "v=spf1 ip4:103.168.172.128/27 ip4:64.147.123.128/27 -all"

# MX records resolve to these IP:
$ docker run --rm -it ghcr.io/natesales/q in1-smtp.messagingengine.com
in1-smtp.messagingengine.com. 1h A 103.168.172.216
in1-smtp.messagingengine.com. 1h A 103.168.172.217
in1-smtp.messagingengine.com. 1h A 103.168.172.218
in1-smtp.messagingengine.com. 1h A 103.168.172.219
in1-smtp.messagingengine.com. 1h A 103.168.172.220
in1-smtp.messagingengine.com. 1h A 103.168.172.221
$ docker run --rm -it ghcr.io/natesales/q in2-smtp.messagingengine.com
in2-smtp.messagingengine.com. 1h A 64.147.123.51
in2-smtp.messagingengine.com. 1h A 64.147.123.52

So all looks good there:

• hello.asciinema.org (doesn't need an A record 👍 ):
  • The MX record directs where mail should be delivered to when received.
  • The TXT SPF record authorizes the IPs to send on behalf of hello.asciinema.org, which is valid.
• wfhigh3-smtp.messagingengine.com is the mail server sending the mail to DMS:
  • As the HELO provided to DMS, it passes rDNS fine and the HELO also resolves to the same IP.
  • The IP is authorized to send mail on behalf of hello.asciinema.org.

MX for the HELO is not relevant AFAIK. If mail is to be bounced it should use the return-path header in the mail IIRC, or bounces it back to the mail server already connected to handle. No MX lookup needed on the HELO FQDN.

So please confirm that you can perform rDNS via a container on the Docker host running DMS, like I showed above with the q image. It's important that it resolves in the container correctly, rather than just on the docker host itself.

You should have dig or drill available on the DMS container, so docker exec -it dms-container-name dig -x 64.147.123.154 should confirm it 👍

If it's not due to this gotcha, then I am a bit puzzled why you'd still get that warning 🤷‍♂️ You could try disabling the check temporarily via rspamd config perhaps?

from docker-mailserver.

The command you supplied doesn't work as there's no arm64 image.

Oh that's a shame it's quite a nice dns tool!

Also the repositoried in DMS image are broken so I cannot install q in the container.

apt update is needed before you can use apt install in the container.

You can also get an ARM64 binary of q (or build it yourself) as it should be capable of static builds as a single binary file. Then adding that into the container is simple via a volume mount or docker cp ./q container-name-here:/usr/local/bin/q.

I've set the container to use Cloudflare

Awesome, just wanted to double check to be sure 😅

I'd rather not. I don't know hot that config works and I don't like running "specialized" setups that I have to fix every major release.

Fair enough 👍

So there's no reason rspamd should have trouble resolving DNS properly then? I don't know why you'd get that warning still 🤷‍♂️

Someone will have to spend time to troubleshoot the problem to better isolate the cause. I'm out of ideas 😭

If you really want to push it along without tackling that yourself, it may help if you can reproduce it between two DMS container instances which allows for isolating into an offline environment fully under our control. I understand if that's too much hassle, but I'm also a bit surprised no one else is reporting similar issues 🤔

I think I encountered it, that's why I have manually set 1.1.1.1 on some containers.

Could you chime in with what version of Docker and Docker Compose you're running?

from docker-mailserver.

Is there a way to migrate DKIM from rspamd to opendkim? I'd try to switch from rspamd to see if spamassasin will do the same. But I don't really want to mess my dkim up - I don't want to wait for my DNS records to propagate (it's on Cloudflare so it's quite better but still)

from docker-mailserver.

I've switched to spamassassin and it receives emails from asciinema without any issues. I've tried to migrate the DKIM key from rspamd to opendkim so I'll see whether that works.

from docker-mailserver.

apt update is needed before you can use apt install in the container.

I know but

Probably related to why you have this problem with rspamd failing to resolve? Something in your environment related to networking is broken?

$ docker run --rm -it --platform linux/arm64 mailserver/docker-mailserver apt update

Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:5 http://deb.debian.org/debian bullseye/main arm64 Packages [7957 kB]
Get:4 https://rspamd.com/apt-stable bullseye InRelease [3161 B]
Get:6 http://deb.debian.org/debian-security bullseye-security/main arm64 Packages [270 kB]
Get:7 http://deb.debian.org/debian bullseye-updates/main arm64 Packages [16.3 kB]
Get:8 https://rspamd.com/apt-stable bullseye/main arm64 Packages [1569 B]
Fetched 8456 kB in 10s (874 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
37 packages can be upgraded. Run 'apt list --upgradable' to see them.

Could you chime in with what version of Docker and Docker Compose you're running?

I use the v2 plugin, not the old binary:

❯ docker compose version
Docker Compose version v2.27.0

Ok that's great, what about the main Docker engine though? (docker version)

For reference I'm on v25.0.3, and compose is v2.24.6, via Docker Desktop + WSL on Windows 11 (which makes that --platform linux/arm64 arg require no additional setup, since I'm on linux/amd64/v4).

If you'd help me set up such environment I'll gladly do so. I'm not that familiar with mailservers (that's why I use DMS) but I'm happy to help.

I demonstrate here a basic relay setup all managed self-contained in a single compose.yaml. That'll work offline locally, but might not be enough in your case as your issue probably needs DNS records too.

I also have this example from 2022 with CoreDNS, and a revised version of that adapted to another response (also 2022), while in Feb 2024 I put together this more recent example with CoreDNS (however this is to demonstrate a different solution so it's config would need to be adjusted, the example also only caters to a single DMS instance to receive mail, but of potential value is the inline TLS config).

I have documented how to create local certs that you can test with (or you can just use the existing ones at that link that we use for our tests for mail.example.test / *.example.test).

Unfortunately I'm low on time, so I can't help atm to simplify the references into a config + instructions that's adapted to your needs, but they should at least provide insight on how to go about getting a local reproduction environment that you could then easily share if you can reproduce what asciinema.org is doing to trigger the problem.

However: As the apt update output implies, this seems more likely to be a problem with your own network environment. Thus even if you do pull this off, it's quite likely no one else will be able to reproduce the failure as it's not a fault of the image itself?

I'm also a bit surprised no one else is reporting similar issues

AFAIK not that many people use asciinema. I reckon that a pretty small number of people that

1. Use asciinema
2. Use it with their own mail server
3. Use DMS
4. Use it with rspamd

Right, but we still have quite a lot of DMS users (although not quite near the pull count that the original tvial image has before moving to an GH organization):

Only a small portion of the users are likely to opt-in to rspamd probably, but we still get reports from those giving it a try and often suggest users to try it instead of the defaults to confirm if it fixes some issues reported.

I wasn't thinking about asciinema specifically, but any other mail server that could also have the same problem as I'm sure it wouldn't only be them. Those that do use rspamd have been quick to report problems (we botched a release IIRC that affected rspamd users, so feedback was quick to address and push out a new point release).

from docker-mailserver.

Is there a way to migrate DKIM from rspamd to opendkim?

Bit tired, but I think this link may help with that.

At least it explains how to generate DKIM key files agnostic to either tool, you then just need to place them in the expected locations. The config files separate to each service may need to be created though. Eventually I'll have time to tackle that issue to implement what I've detailed there and it'll become much simpler in a future DMS release.

Ok, I managed to setup spamassassin and opendkim. Opendkim even has my old key now (luckily it's not that hard to follow the files and the config) so I'm set up without any issues now.

Oh.. awesome then! You already sorted it out. Glad to hear that the issue doesn't occur with SA. @georglauterbach did point out the specific rspamd config responsible for it. I don't know if that has an opt-out in DMS, so as mentioned you'd need to manually override it AFAIK.

I don't know about SA having an equivalent, but I did mention earlier what a rough equivalent was in Postfix, and the DMS ENV that enables that (as unlike rspamd it is opt-in). Toggling that is likely to cause the same problem.

I have both .env files so I can easily switch between them for testing. I'll be running spamassassin now, switching to rspamd only for testing and once it's fixed (I'd like to have the more lightweight thing).

Great! I'm just not sure what we can do to fix, other than to add support to opt-out of the feature in rspamd. I'm not sure if that's actually needed via an ENV, or if it's just a simple config file that we already support (I'm not familiar with the rspamd config much, @georglauterbach can chime in on that).

Other than that, I'm not sure if there's anything we can fix, as previously mentioned your network environment seems to be faulty in some manner if apt update isn't working in DMS either (as it clearly does for me).

from docker-mailserver.

Probably related to why you have this problem with rspamd failing to resolve? Something in your environment related to networking is broken?

I don't think so because it's fine until I run it in my production container. Here's a recording of the tests:

Ok that's great, what about the main Docker engine though?

Client: Docker Engine - Community
 Version:           26.1.1
 API version:       1.45
 Go version:        go1.21.9
 Git commit:        4cf5afa
 Built:             Tue Apr 30 11:48:06 2024
 OS/Arch:           linux/arm64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.1
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.9
  Git commit:       ac2de55
  Built:            Tue Apr 30 11:48:06 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Other than that, I'm not sure if there's anything we can fix, as previously mentioned your network environment seems to be faulty in some manner

Because of the issue persisting only in the container I think it's something with the config I have (see the recording). I'll look through the .env and see whether there is something to take out before posting it here as that could help. The compose file is already up there so I'll probably just edit the issue, add that file and make a comment to notify you.

Edit: I'm uploading the recording in case I ever were to delete it.
658609.cast.gz

from docker-mailserver.

Because of the issue persisting only in the container I think it's something with the config I have (see the recording).

Try recreating the container?

It's an important remedy for many issues that can't be reproduced well. So common that we really try draw attention to it on our troubleshooting docs page and direct users to before starting their report:

Perhaps you did follow that advice, but I noticed we didn't discuss it yet and with your last comment noting that apt update works in a fresh DMS container but not your real DMS instance, this is highly likely to be the cause?

FWIW, when I used Docker in VMs that I suspended, the containers would lose network connectivity upon restoring the VM requiring the daemon to be restarted IIRC. There can be lots of these weird networking gotchas with all the layers/abstractions involved.

from docker-mailserver.

This system does not suspend at all.

It was just intended as another example of where networking with a container broke.

I tried to update the container (this recreates it in Portainer)

Can you try without Portainer? I don't know if that influences the behaviour?

Either way, you were not able to reproduce the problem in a fresh container instance as per above, so whatever is gone awry it's likely unrelated to DMS itself? I don't know how we could troubleshoot it further with you unless you can identify something we can actually act on?

from docker-mailserver.

I found out what broke the apt command. It was this like in the compose.yml file that you provide for basic setup:

When I commented it out and used the OVERRIDE_HOSTNAME

in the env file instead it works again. I'm currently checking out whether amavis works, since it kept crashing and restarting, that's why I started looking into it now even though I don't have time. I'll look whether not using the hostname option in docker solved rspamd once I am sure that my mailserver works.

from docker-mailserver.

Looks like it's better but it's greylisted

2024-05-19 16:53:22 #1326(rspamd_proxy) <f0f8aa>; proxy; rspamd_task_write_log: id: <undef>, qid: <90321290148E>, ip: 64.147.123.150, from: <[email protected]>, (default: F (soft reject): [0.00/11.00] [ASN(0.00){asn:29838, ipnet:64.147.123.0/24, country:US;},GREYLIST(0.00){greylisted;Sun, 19 May 2024 14:56:54 GMT;too early;}]), len: 4955, time: 51.976ms, dns req: 1, digest: <9f483e94cb3c0537f4d579d7b057272a>, rcpts: <[email protected]>, mime_rcpts: <[email protected]>, forced: soft reject "Try again later"; score=nan (set by greylist)

from docker-mailserver.

The emails started coming as they should! Only they ended up in SPAM folder, maybe because I've tried logging in multiple times to test different configs/circumstances. So emails that are 90% similar with the same subject from the same email 3 times was maybe enough for it to get there.

It doesn't matter though! I got the emails and just moved them to INBOX so rspamd should learn, since it's turned on!

I'll leave this open until it's figured out what to do with the failing hostname option:

from docker-mailserver.

Looks like it's better but it's greylisted

2024-05-19 16:53:22 #1326(rspamd_proxy) <f0f8aa>; proxy; rspamd_task_write_log: id: <undef>, qid: <90321290148E>, ip: 64.147.123.150, from: <[email protected]>, (default: F (soft reject): [0.00/11.00] [ASN(0.00){asn:29838, ipnet:64.147.123.0/24, country:US;},GREYLIST(0.00){greylisted;Sun, 19 May 2024 14:56:54 GMT;too early;}]), len: 4955, time: 51.976ms, dns req: 1, digest: <9f483e94cb3c0537f4d579d7b057272a>, rcpts: <[email protected]>, mime_rcpts: <[email protected]>, forced: soft reject "Try again later"; score=nan (set by greylist)

That's not the first message that belongs to this e-mail (denoted by the "too early"). Can you search for the first and show me?

What happens if you set both, hostname: and OVERRIDE_HOSTNAME? Technically, what you're experiencing shouldn't happen, als both options should be equivalent 🤔

from docker-mailserver.

E-Mails from asciinema seem to be wild:

1. They lack a Message-ID header (!)
2. They seem to be using an excessive amount of Base64
3. They do not have DMARC set up (!)
4. They violate "RFC1341: 7.2 The Multipart Content-Type", indicated by CTYPE_MIXED_BOGUS

Hence, I would have been more worried if this did not end up in spam, TBH. If it's not too much trouble, can you post an anonymized version of such an e-mail here? I'd be curious to see one.

from docker-mailserver.

I just tried what would rspamd do with my own asciinema instance and it's basically the same (apart from me having a DMARC policy). So it looks like the client sending the emails may be misconfigured?

Also I get HFILTER_HOSTNAME_UNKNOWN (6) when I manually check the message source by rspamd. IDK what that issue really is but I suspect that it's because it's an internal message (from my.domain to my.domain).

from docker-mailserver.

If you think it's appropriate I'll create an issue in the server's repo and report the DMARC error to the default instance admin.

from docker-mailserver.

Thank you for the sources; it looks indeed weird. Nothing too much out of the ordinary, but enough to make Rspamd classify this as spam.

I just tried what would rspamd do with my own asciinema instance and it's basically the same (apart from me having a DMARC policy). So it looks like the client sending the emails may be misconfigured?

Yes.

Also I get HFILTER_HOSTNAME_UNKNOWN (6) when I manually check the message source by rspamd. IDK what that issue really is but I suspect that it's because it's an internal message (from my.domain to my.domain).

Indeed, this is because my.domain has not DNS<->rDNS match :)

If you think it's appropriate I'll create an issue in the server's repo and report the DMARC error to the default instance admin.

That's a formidable idea! If you can, also mention the missing Message-ID header and the weird Base64 stuff. You can link to this issue and possibly to comments as well.

from docker-mailserver.

Indeed, this is because my.domain has not DNS<->rDNS match :)

So it is local only? Now that I think of it though my DNS is one domain (the intended one) and the rDNS is a subdomain of my isp with the internal ip in it. How can I check whether that issue exists outside local emails?

When you are testing locally, having a dedicated DNS server is very handy. This way, you can have proper (r)DNS entries even for local domains, and you will not encounter the effects you just witnessed anymore. coreDNS is a good DNS server for containers (I use it my K8s cluster); and I also have a dedicated recursive resolver (for Rspamd and the like) (see georglauterbach/k8s-dns).

That's a formidable idea! If you can, also mention the missing Message-ID header and the weird Base64 stuff. You can link to this issue and possibly to comments as well.

I already prepared the issue and I linked to your comment where you explained the issues which I think you did pretty well. The issue is on my laptop though so I'll post it later (on my phone RN).

Awesome!

from docker-mailserver.

Sounds cool for testing but that would not solve that my public domain has a rDNS something like ip-10-222-16-4.myisp.com instead of my domain.

from docker-mailserver.