[Rspamd-Users] x-spam-level header removed?

[Vsevolod Stakhov]

On 13/01/2021 20:16, Alain de Longue via Users wrote:
> Is the x-spam-level milter header no longer working or no longer supported?
> I still have sieve scripts that check this header and I now see it missing on all incoming emails to my server.
> Here are typical headers I see now...
> X-Spam-Status: No, score=-1.91
> X-Rspamd-Queue-Id: 68B712029B
> X-Spamd-Result: default: False [-1.91 / 25.00];
> 	 ARC_NA(0.00)[];
> 	 R_DKIM_ALLOW(-0.20)[rubyonrails.org:s=goodbits];
> 	 RBL_SENDERSCORE_FAIL(0.00)[147.253.213.135:server fail];
> 	 FROM_HAS_DN(0.00)[];
> 	 ZERO_FONT(0.10)[1];
> 	 TO_MATCH_ENVRCPT_ALL(0.00)[];
> 	 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
> 	 HTML_SHORT_LINK_IMG_3(0.15)[];
> 	 DMARC_NA(0.00)[rubyonrails.org];
> 	 HAS_LIST_UNSUB(-0.01)[];
> 	 RCPT_COUNT_ONE(0.00)[1];
> 	 URI_COUNT_ODD(1.00)[27];
> 	 MANY_INVISIBLE_PARTS(0.05)[1];
> 	 TO_DN_ALL(0.00)[];
> 	 DKIM_TRACE(0.00)[rubyonrails.org:+];
> 	 R_SPF_ALLOW(-0.20)[+exists:147.253.213.135._spf.sparkpostmail.com];
> 	 FORGED_SENDER(0.30)[newsletter at rubyonrails.org,msprvs1=18645ZtZavAbb=bounces-31123 at spmailtechnol.com];
> 	 RCVD_COUNT_ZERO(0.00)[0];
> 	 MIME_TRACE(0.00)[0:+,1:+,2:~];
> 	 ASN(0.00)[asn:23528, ipnet:147.253.208.0/20, country:US];
> 	 FROM_NEQ_ENVFROM(0.00)[newsletter at rubyonrails.org,msprvs1=18645ZtZavAbb=bounces-31123 at spmailtechnol.com];
> 	 BAYES_HAM(-3.00)[99.99%]
> X-Rspamd-Server: srvr2005b
> X-Virus-Scanned: clamav-milter 0.99.2 at srvr2005b
> X-Virus-Status: CleanI am running rspamd version 2.2
> Three months ago the x-spam-level header was present.
> This is from rspamd.log when rspamd was restarted today.
> 
> 2021-01-13 11:53:14 #28931(main) <n6bdtc>; lua; milter_headers.lua:648: active routines [x-spam-level,x-spam-status,remove-spam-flag]
> 2021-01-13 11:55:16 #29051(main) <btosr4>; lua; milter_headers.lua:648: active routines [x-spamd-result,x-rspamd-server,x-rspamd-queue-id,x-spam-level,x-spam-status,remove-spam-flag]

Your configuration is apparently broken. A common reason for that is
noted in *each* configuration file:

# Please don't modify this file as your changes might be overwritten with
# the next update.