Spamassassin and spamc do not use same rules
I recently setup a new install of an email server on a CentOS 7 server. Everything is working correctly except for this problem: >spamassassin --test-mode Content analysis details: (9.6 points, 5.0 required) pts rule name description -- -- 1.9 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL blocklist [URIs: cricketlivehd.com] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to background 1.1 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_REMOTE_IMAGE Message contains an external image 5.2 TXREP TXREP: Score normalizing based on sender's reputation > spamc -R Content analysis details: (4.3 points, 5.0 required) pts rule name description -- -- 1.9 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL blocklist [URIs: cricketlivehd.com] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to background 1.1 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 T_REMOTE_IMAGE Why does the spamassassin test use TXREP but the spamc test does not? Do I have to start spamd up in a specific way to use TXREP? Anybody have any ideas? -- Paul (ga...@nurdog.com) Cell: (303)257-5208
Re: anyone recognize these headers? From SA or are they from another spam product?
On 24 Apr 2018, at 20:10 (-0400), L A Walsh wrote: These headers (not these values) are in most or all of my emails. In one email on the net they were adjacent to SA's headers (but they aren't in my emails). I was wondering if anyone knew what product might be inserting these headers: X-CSC: 0 X-CHA: v=1.1 cv=6jkfEoj2u7Yj9etNrzOg8LH7MfGxzbc6Xn0EJkmycus= c=1 sm=1 a=nDghuxUhq_wA:10 a=CxQU8S3nryls5r8B3V4N1Q==:17 a=3Y9Ew-73vc-33Fzs_NIA:9 a=wPNLvfGTeEIA:10 a=z11Dn8fxQD8A:10 a=Pmo6RyrIMpYA:10 a=zoqau9DHoPcA:10 a=zE7RolXeqPMA:10 a=CxQU8S3nryls5r8B3V4N1Q==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020207.521CE122.0254,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-WHL: SLR The X-CTCH-* headers are a sign of filtering software from Cyren (formerly Commtouch,) which has been resold or integrated by multiple vendors of commercial email filtering products, including Sophos and Ipswitch. I don't know if it is related, but some evidence of scanning by something called 'ironport', as well as by Semantec. I'm trying to track down what is scanning my email at an upstream mail host as they've rejected random emails on initial rcpt of the msg -- without accepting the message and bouncing it, but just not accepting it with the message: User and password not set, continuing without authentication. 64.29.145.41 failed after I sent the message. Remote host said: 550 5.7.1 vB73jgO3003858 This message has been blocked for containing SPAM-like characteristics. What email SW censors things by rejecting them before accepting them? That is not a unique feature, and is widely regarded as a best practice. A MTA which accepts mail and later decides that it is spam has an insoluble problem: pass along mail which is probably malicious, bounce it to an inherently untrustworthy sender address that may belong to an innocent victim, or drop it silently. Since this mail is being rejected immediately, you have an obvious place to go to get the problem fixed: whoever runs the server you're submitting mail to. Presumably that is an entity with whom you have a direct relationship. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
anyone recognize these headers? From SA or are they from another spam product?
These headers (not these values) are in most or all of my emails. In one email on the net they were adjacent to SA's headers (but they aren't in my emails). I was wondering if anyone knew what product might be inserting these headers: X-CSC: 0 X-CHA: v=1.1 cv=6jkfEoj2u7Yj9etNrzOg8LH7MfGxzbc6Xn0EJkmycus= c=1 sm=1 a=nDghuxUhq_wA:10 a=CxQU8S3nryls5r8B3V4N1Q==:17 a=3Y9Ew-73vc-33Fzs_NIA:9 a=wPNLvfGTeEIA:10 a=z11Dn8fxQD8A:10 a=Pmo6RyrIMpYA:10 a=zoqau9DHoPcA:10 a=zE7RolXeqPMA:10 a=CxQU8S3nryls5r8B3V4N1Q==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020207.521CE122.0254,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-WHL: SLR I don't know if it is related, but some evidence of scanning by something called 'ironport', as well as by Semantec. I'm trying to track down what is scanning my email at an upstream mail host as they've rejected random emails on initial rcpt of the msg -- without accepting the message and bouncing it, but just not accepting it with the message: User and password not set, continuing without authentication. 64.29.145.41 failed after I sent the message. Remote host said: 550 5.7.1 vB73jgO3003858 This message has been blocked for containing SPAM-like characteristics. What email SW censors things by rejecting them before accepting them? Any ideas would really be helpful.
Re: plugin: eval failed: __alarm__ignore__(xxx) how to troubleshoot
Pedro, ideas are great but patches are essential. If you are interested in said feature, please consider submitting a patch to achieve it. Especially because I can guarantee you that very few people will put any cycles on a 3.3.X release issue. -- Kevin A. McGrail Asst. Treasurer & VP Fundraising, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sun, Apr 22, 2018 at 2:27 PM, Pedro David Marco wrote: > > > >Given your findings, I kinda suspect *all* of the tflags=multiple rules > >are misbehaving from time to time under 3.3.1 - the compiled code may be > >getting into an infinite loop somehow if the number if *real* hits on the > >rule exceeds some value - I note there were 17 hits on "your business > > Maybe ths is a good moment to speak again about my old suggestion > of having a kind of: > > tflags=multiple-uniq > > to avoid repeated values > > -- > PedroD > > > . > > >
