[MlMt] Adding rule based on spam headers

[Charlie Clark]

On 11 Nov 2020, at 22:06, Bill Cole wrote:

Hi Bill,

> <From><is in><Sent Messages><Recipient>"
>
> * to contains full name
>
> I haven't tried it, but I would expect this to work:
>
> <To><contains><Charlie Clark >
>
> * trust spam headers
>
> <X-Spam-Status><contains><Yes,>

I found this.

> Has anyone figured out conditions for rules like this?
>
> See above.
>
>
> I've got headers like this:
>
> X-Spam-Status: No, score=4.8 required=5.0 
> tests=HTML_FONT_LOW_CONTRAST,
> 	HTML_MESSAGE,NORDNS_LOW_CONTRAST,RDNS_NONE,SUBJ_ALL_CAPS,
> 	URIBL_ABUSE_SURBL,URIBL_BLOCKED autolearn=no autolearn_force=no
> 	version=3.4.2
>
> <Putting on "Apache SpamAssassin Project Committer" hat>
>
> Job 0: get your mail provider to fix that URIBL_BLOCKED problem. It 
> indicates that they are trying to use a free-for-most DNS-based URI 
> blocking list (uribl.com) in a way that makes them seem like a large 
> commercial email provider, for whom usage is NOT free. It may be as 
> simple as a DNS config change on the machine running SA, if they are 
> currently using a shared forwarder and don't actually have large 
> volume.

Thanks for this and thanks very much for your work on SpamAssassin! I've 
passed it onto the guy running the server: it is only a small one and 
was recently moved so I think it's still being tweaked.

> MM SHOULD parse that X-Spam-Status and put it in the "Spam Score" 
> pseudo-header for display and in X-Spam-Status->Score for conditions. 
> Unfortunately, it does not recognize the value as a number for 
> conditions, so you don't get 'greater than' and 'less than' operators.

Indeed MailMate is correctly parsing the score but, as you say, it 
doesn't have the operators for handling numbers properly.

@Benny: feature request?

> Where I'd like to be able to set the threshold a bit lower but I can't 
> think of an easy way of doing this at the moment with the score not 
> being available as a separate header.
>
> What are you all doing?
>
> Filtering on the server side and seeing so little spam that it's not 
> worth dealing with in MM. (Yes, I know that's not a broadly useful 
> strategy.)

In general, this is the way to go as anything that makes its way to the 
user could cause problems.

Charlie

--
Charlie Clark
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-938-5360
Mobile: +49-178-782-6226