Lacre fails to send email

muppeth commented

2025-02-06 14:01:26 +01:00

Owner

I noticed an issue a while back with Lacre. I have not report it before as it was affecting emails that would be anyway rejected, however there might be bigger issue at hand so probably good to check what exactly causes the issue.
Currently on our server, before email is handed to Lacre, it's checked by Amavis (spam/virus check). I have few spamassasin filters looking for some obvious spam phrases and giving it high score (eg 5000). When checking headers, postfix is ordered to reject any email with spam score higher then 499.*. Seems like this triggers Lacre to fail:

 lacre.transport[2745487]: Permanent delivery failure: (550, b'5.7.1 ErrorCode 007')
2025-02-06T12:52:45.066956+01:00 mail01 lacre.daemon[2745487]: Permanent failure#012Traceback (most recent call last):#012  File "/opt/lacre/lacre/transport.py", line 92, in __call__#012    smtp.sendmail(self._from_addr, recipients, message)#012  File "/usr/lib/python3.11/smtplib.py", line 908, in sendmail#012    raise SMTPDataError(code, resp)#012smtplib.SMTPDataError: (550, b'5.7.1 ErrorCode 007')#012#012During handling of the above exception, another exception occurred:#012#012Traceback (most recent call last):#012  File "/opt/lacre/lacre/daemon.py", line 52, in handle_DATA#012    send(new_message, operation.recipients())#012  File "/opt/lacre/lacre/transport.py", line 101, in __call__#012    raise PermanentFailure()#012lacre.transport.PermanentFailure

I've tested this against other header filters and seems to be working ok. Just the X-SPAM seems to have issue.
I think what I could do to help narrowing down the issue or at least make it more possible to test is setting up similar scenario on lacre.io. This means spamassasin rule giving 5000 triggered on some keywords (for reproducibility), and add header check to postfix. Unless of course @pfm you see the issue right away based on the traceback posted above.

I noticed an issue a while back with Lacre. I have not report it before as it was affecting emails that would be anyway rejected, however there might be bigger issue at hand so probably good to check what exactly causes the issue. Currently on our server, before email is handed to Lacre, it's checked by Amavis (spam/virus check). I have few spamassasin filters looking for some obvious spam phrases and giving it high score (eg `5000`). When checking headers, postfix is ordered to reject any email with spam score higher then `499.*`. Seems like this triggers Lacre to fail: ``` lacre.transport[2745487]: Permanent delivery failure: (550, b'5.7.1 ErrorCode 007') 2025-02-06T12:52:45.066956+01:00 mail01 lacre.daemon[2745487]: Permanent failure#012Traceback (most recent call last):#012 File "/opt/lacre/lacre/transport.py", line 92, in __call__#012 smtp.sendmail(self._from_addr, recipients, message)#012 File "/usr/lib/python3.11/smtplib.py", line 908, in sendmail#012 raise SMTPDataError(code, resp)#012smtplib.SMTPDataError: (550, b'5.7.1 ErrorCode 007')#012#012During handling of the above exception, another exception occurred:#012#012Traceback (most recent call last):#012 File "/opt/lacre/lacre/daemon.py", line 52, in handle_DATA#012 send(new_message, operation.recipients())#012 File "/opt/lacre/lacre/transport.py", line 101, in __call__#012 raise PermanentFailure()#012lacre.transport.PermanentFailure ``` I've tested this against other header filters and seems to be working ok. Just the X-SPAM seems to have issue. I think what I could do to help narrowing down the issue or at least make it more possible to test is setting up similar scenario on lacre.io. This means spamassasin rule giving 5000 triggered on some keywords (for reproducibility), and add header check to postfix. Unless of course @pfm you see the issue right away based on the traceback posted above.

muppeth added the

BUG

label 2025-02-06 14:01:26 +01:00

muppeth commented

2025-02-06 14:12:58 +01:00

Author

Owner

Quick update. I suspected high score number to trigger issue. But when removing the header check on postfix side, emails arrive to the other side marked as spam, so the issue seems to be with header_checks here which causes postfix to trip out. I will re-create scenario on lacre.io