Thanks for the reply, it seems spamassassin is not in use, but amavis seems to read out those settings. The spam score for FROM_ADDR_WS vanished now. My initial problem still exists, the sender gets a bounce message, my best guess is because of the newline in FROM.

Dear Zhang,

thanks for looking into this ...

554-Transaction
    failed 554-Reject due to policy restrictions. 554 For explanation visit
    https://web.de/email/senderguidelines/(in reply to
    end of DATA command)

I checked all of it, the only useful hint seems to be the header. The user has a not very common email-client. If he shortens his FROM < 50 letters his email will pass, > 50 letters there will be a newline.

cat -v -e ... shows:

X-Virus-Scanned: Debian amavisd-new at mail.my-server.tld$
X-Spam-Flag: NO$
X-Spam-Score: 4.259$
X-Spam-Level: ****$
X-Spam-Status: No, score=4.259 tagged_above=2 required=6.2$
    tests=[ALL_TRUSTED=-1, DKIM_ADSP_NXDOMAIN=0.8, FROM_ADDR_WS=2.999,$
    FROM_EXCESS_BASE64=0.105, HEADER_FROM_DIFFERENT_DOMAINS=0.249,$
    HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.105]$
    autolearn=no autolearn_force=no$
Received: from mail.my-server.tld ([127.0.0.1])$
    by mail.my-server.tld (mail.my-server.tld [127.0.0.1]) (amavisd-new, port 10026)$
    with ESMTP id QD-aK9Sq29VP for <receiver@my-server.tld>;$
    Fri, 19 Nov 2021 15:19:31 +0100 (CET)$
Received: from RS2014 (i6DFA2881.versanet.de [109.250.40.129])$
    by mail.my-server.tld (Postfix) with ESMTPSA id 4Hwf1b58hqz2RJl;$
    Fri, 19 Nov 2021 15:19:31 +0100 (CET)$

From: =?utf-8?B?UHJvZi4gRHIuIFJ1ZGkgU2NobWllZGU=?= <sender@my-serve$
    r.tld>$

Reply-To: sender@my-server.tld$
To: receiver@my-server.tld$
Subject: =?utf-8?B?VGVzdG2haWwgw8xiZXIgbWVpbmUgaWZzLUFkcmVzc3U=?=$
Date: Fri, 19 Nov 2021 15:19:34 +0100$
MIME-Version: 1.0$
Content-Type: text/html; charset="utf-8"$
Content-Transfer-Encoding: base64$
X-MimeOLE: Chaos Intellect v10.2$
x-Account: IfS-RS$
x-MsgStatus: U$
x-linkedname: $
x-ImapUidl: $
X-Mailer: Chaos Intellect v10.3.0.6$

I'm trying to understand why and where the newline actually occurs at first - is it the emailclient or is there a setting in postfix / amavis? Due to RFC 5322 the length of headerfields should work fine up to 78 characters, which would be okay for his original FROM (above is shortend).

The user has a not very common email-client, so which one is he useing?

He needs to change the email client then, it is causing those problems, if common spam filters detect the malformation and some providers even completely reject it, it is an unsolvable problem and not related to iredmail or any software used by it

did you manually disable spamasassin? because normalyl it gets invoked by amavis and only gets bypassed, if you enable spam bypassing for domain or single users

then there are 2 options, either your client gets help from software provider and they fix their program, or he uses other software for emails

aswell, i see no reason to utf8-encode (first example was utf-7encoded) the sender email, or better said useing  useing special chars in an sender email so it needs to get utf-8 encoded for transmission, i would avoid this anytime just to prevent incompatibilites