pdfinfo plugin
Hello, I still use the pdfinfo plugin from Dallas Engelken (and it still hits on some messages). But does anyone know the status of the plugin? Is it maintained? Does it make sense to use it with spamassassin 3.4.0 or is a similar functionality already included there? Best regards Stefan
Re: pdfinfo plugin
On 12/02/2014 11:58 AM, Stefan Jakobs wrote: Hello, I still use the pdfinfo plugin from Dallas Engelken (and it still hits on some messages). But does anyone know the status of the plugin? Is it maintained? I'm partially to blame this plugin exists - rule support, etc. Does it make sense to use it with spamassassin 3.4.0 yes, definitely or is a similar functionality already included there? nope... As PDF spams haven't been a huge issue lately I've been lazy with adding rules Not sure if rule creation was well documented - I'll try to put something together - it's been ages...
SA dns_server option
Hi all. I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? Thanks in advance. Best regards, Matteo
Re: Honeypot email addresses
On 02/12/2014 15:28, Ted Mittelstaedt wrote: On 12/1/2014 8:47 PM, Noel Butler wrote: On 02/12/2014 09:07, Reindl Harald wrote: Am 01.12.2014 um 23:46 schrieb Franck Martin: On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: My experience says it is very useful my point in context of that thread is that using previous valid addresses as honeypot is dangerous to stupid - you have no clue in most cases about the context how the RCPT got chosen and i know a lot of people sening once or twice a year some mail to their limited address book congratulations if you in that case (you can't know) block the whole sending server because one of your team memebers left not to mention the number of people who run ancient backups, because they CBF checking to see that their current backups still worked, and find they are mailing a dead address. Harry and I rarely agree, but here we do, it is a dangerous act - the only safe trap address are the ones never ever used before, its only way you have 100% guaranteed zero FP's. This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Most honeypots are not used in such a draconian fashion. But go ahead and be Draconian - I guess the only way you both can justify a win on this argument is by assuming people use honeypots in ways that simply are not done in reality. For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bays feeding sources. Don't bother engaging the two Zealots, you will be wasting your time. eyeroll Ted most dont use it this way ? backup your statement with evidence. I await your masses of proof do you even read what you dribble before click send?
Re: SA dns_server option
On 12/02/2014 12:32 PM, Matteo Dessalvi wrote: Hi all. I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? Thanks in advance. Best regards, Matteo No matter how hard I look, I can't find a dns_server option in SA's conf did you mean dns_available ?? ( http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt ) or is this an Amavis option (I don't know Amavis)
Re: SA dns_server option
On 12/02/2014 01:16 PM, Axb wrote: On 12/02/2014 12:32 PM, Matteo Dessalvi wrote: Hi all. I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? Thanks in advance. Best regards, Matteo No matter how hard I look, I can't find a dns_server option in SA's conf did you mean dns_available ?? ( http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt ) or is this an Amavis option (I don't know Amavis) doh.. there it is dns_server dns_server ip-addr-port (default: entries provided by Net::DNS) Specifies an IP address of a DNS server, and optionally its port number. The *dns_server* directive may be specified multiple times, each entry adding to a list of available resolving name servers. The *ip-addr-port* argument can either be an IPv4 or IPv6 address, optionally enclosed in brackets, and optionally followed by a colon and a port number. In absence of a port number a standard port number 53 is assumed. When an IPv6 address is specified along with a port number, the address must be enclosed in brackets to avoid parsing ambiguity regarding a colon separator, Examples : dns_server 127.0.0.1 dns_server 127.0.0.1:53 dns_server [127.0.0.1]:53 dns_server [::1]:53 In absence of *dns_server* directives, the list of name servers is provided by Net::DNS module, which typically obtains the list from /etc/resolv.conf, but this may be platform dependent. Please consult the Net::DNS::Resolver documentation for details. You don't need to specify one unless you need the specials in the config
Re: SA dns_server option
Yes, I have read the docs but I was not sure if SA, when used through Amavis, would use such option. Nevermind, I pushed up the log verbosity of my DNS caching service and it looks like SA is using it. So, problem solved :-). Thanks. Best regards, Matteo On 02.12.2014 13:18, Axb wrote: doh.. there it is dns_server dns_server ip-addr-port (default: entries provided by Net::DNS) Specifies an IP address of a DNS server, and optionally its port number. The *dns_server* directive may be specified multiple times, each entry adding to a list of available resolving name servers. The *ip-addr-port* argument can either be an IPv4 or IPv6 address, optionally enclosed in brackets, and optionally followed by a colon and a port number. In absence of a port number a standard port number 53 is assumed. When an IPv6 address is specified along with a port number, the address must be enclosed in brackets to avoid parsing ambiguity regarding a colon separator, Examples : dns_server 127.0.0.1 dns_server 127.0.0.1:53 dns_server [127.0.0.1]:53 dns_server [::1]:53 In absence of *dns_server* directives, the list of name servers is provided by Net::DNS module, which typically obtains the list from /etc/resolv.conf, but this may be platform dependent. Please consult the Net::DNS::Resolver documentation for details. You don't need to specify one unless you need the specials in the config
Re: Argument perl_version isn't numeric
On 12/1/2014 11:57 PM, Noel Butler wrote: On 02/12/2014 10:24, Kevin A. McGrail wrote: On 12/1/2014 6:06 PM, John Hardin wrote: It looks like as long as we support perl 5.10.0 then the only clean solution is can(Mail::SpamAssassin::Conf::perl_min_version_501) With perl versions so low in so many distros, I think we have to implement the perl_min_version function. Do you want me to take a stab at it? Regards, KAM 5.10 is only what, six years old? Surely anyone running anything older have far greater issues :) (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe but theyll join the 14 series this Christmas when I can take them offline to upgrade em, even -current is useing a 12 month old 5.18.1) There is a fairly consistent streak in some distros to backport patches to older versions rather than move the version forward. 5.8.8 is in pretty far spread use from my knowledge. Regards, KAM
Re: Honeypot email addresses
On 12/2/2014 12:28 AM, Ted Mittelstaedt wrote: For anyone else, this discussion about honeypots STARTED as a discussion on where to find good Bayes feeding sources. No, it started as a discussion about honeypots to help the SOUGHT 2.0 project which could use more volunteers, BTW! Regards, KAM
Re: SA dns_server option
Matteo Dessalvi wrote: I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? Yes it is. To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? The dns_server only affects SpamAssassin. If you want other applications on that host to also use the same recursive name server, its address needs to be in /etc/resolv.conf. For example DKIM validation is done by amavisd calling Net::DNS directly, which has no idea about SpamAssassin settings. Similarly a milter or MTA. Yes, I have read the docs but I was not sure if SA, when used through Amavis, would use such option. Nevermind, I pushed up the log verbosity of my DNS caching service and it looks like SA is using it. So, problem solved :-). Mark
Re: SA dns_server option
Am 02.12.2014 um 14:16 schrieb Mark Martinec: Matteo Dessalvi wrote: I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? Yes it is. To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? The dns_server only affects SpamAssassin. If you want other applications on that host to also use the same recursive name server, its address needs to be in /etc/resolv.conf. For example DKIM validation is done by amavisd calling Net::DNS directly, which has no idea about SpamAssassin settings. Similarly a milter or MTA i would recommend setup unbound on 127.0.0.1, let do it recursion directly and configure internal zones as forwarders which can also including a forwarding to a rbldnsd running on 127.0.0.1 using a different port so /etc/resolv.conf just contains 127.0.0.1 see below how that could look like * one source for all services * local caching * no problems with DNS blacklists by doing recursion instead share a forwarder exceeding limits __ minimal-responses: yes interface: 127.0.0.1 access-control: 127.0.0.0/8 allow local-zone: 192.in-addr.arpa. nodefault forward-zone: name: dnsbl.thelounge.net forward-addr: 127.0.0.1@1053 forward-zone: name: thelounge.net forward-addr: 192.168.196.6 forward-addr: 192.168.196.106 stub-zone: name: 192.in-addr.arpa. stub-addr: 192.168.196.6 stub-addr: 192.168.196.106 __ signature.asc Description: OpenPGP digital signature
Re: SA dns_server option
For example DKIM validation is done by amavisd calling Net::DNS directly A nitpick: Actually, amavisd is calling Mail::DKIM when DKIM validation is enabled, which in turn calls Net::DNS. The validation result is then passed to SpamAssassin's DKIM plugin, so that it doesn't need to do the validation again. Mark
Re: Honeypot email addresses
On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. -- You're just impressed by any pretty girl who can walk and talk. She doesn't have to talk.
Re: SA dns_server option
Hi. @Mark: thanks for the explanations about Amavis/SA. @Reindl: thanks, I am indeed using unbound as a DNS caching server. Interesting the option 'minimal-responses', I would check that. Regards, Matteo On 02.12.2014 14:16, Mark Martinec wrote: Matteo Dessalvi wrote: I have a short question about the dns_server option of SA. Is this option used when SA is called from Amavis and there isn't any spamd process running? Yes it is. To be more clear: should I also be forced to add the IP address of the caching DNS server to /etc/resolv.conf or the option would be sufficient? The dns_server only affects SpamAssassin. If you want other applications on that host to also use the same recursive name server, its address needs to be in /etc/resolv.conf. For example DKIM validation is done by amavisd calling Net::DNS directly, which has no idea about SpamAssassin settings. Similarly a milter or MTA. Mark
Re: SA dns_server option
Am 02.12.2014 um 15:20 schrieb Matteo Dessalvi:
@Mark: thanks for the explanations about Amavis/SA.
@Reindl: thanks, I am indeed using unbound as a DNS
caching server. Interesting the option 'minimal-responses',
I would check that
it's damned useful, Google using it also on their public NS
a drop of 25%-30% DNS traffic on our auth-nameservers
for BIND minimal-responses yes; inside options {}
the only drawback is that dig no longer resolves MX hostnames and so
on to the IP until you ask explicit, well for that i wrote a
web-interface answering any possible question of a domain
signature.asc
Description: OpenPGP digital signature
Re: Argument perl_version isn't numeric
Hello Noel, Tuesday, December 2, 2014, 4:57:08 AM, you wrote: NB 5.10 is only what, six years old? Surely anyone running anything older have far greater issues CentOS 5.11 doesn't go EOL until 2017 and it has 5.8.8 -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpBNkgh1ChjG.pgp Description: PGP signature
Re: SA dns_server option
Axb skrev den 2014-12-02 13:16: No matter how hard I look, I can't find a dns_server option in SA's conf oh are you living in belgium ? :) did you mean dns_available ?? next line after that is dns_server ( http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt ) or is this an Amavis option (I don't know Amavis) possible you see incorrect config file # dns_server ip-addr-port (default: entries provided by Net::DNS) dns_server 127.0.0.1 ip-addr-port should just be ip-addr:port imho, if only defined ip-addr it defaults to port 53 may santa be with this maillist here
Re: Argument perl_version isn't numeric
jdow skrev den 2014-12-01 23:56: I just added the following to my user-prefs file: if version 3.004001 perl_version = 5.01 metaPDS_FROM_2_EMAILS __PDS_FROM_2_EMAILS !__VIA_ML !__VIA_RESIGNER endif No error here SL6.6, perl 5.10.1 and SA 3.3.1. good, but 3.4.2 does not exists yet :)
Re: Honeypot email addresses
On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org, we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. A single spamtrap hit for an IP that has been seen for a few days only says quite a lot. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. Now you've seen one that doesn't :) -- Matthias
Re: Argument perl_version isn't numeric
Noel Butler skrev den 2014-12-02 05:38: On 01/12/2014 22:27, Benny Pedersen wrote: Please turn of html never going to happen this will be added so to my sieve autoreader, eg i can save reading your hints of my own problems again
Re: Honeypot email addresses
On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? Ted
Re: Honeypot email addresses
On 12/2/2014 12:24 PM, Ted Mittelstaedt wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? For me, spam is always about minimizing collateral damage but it is far from an exact science and subject to friendly debate to improve things for everyone. Let's remember who the bastards are (the spammers) and not attack people's honeypots/DNSWLs, etc. because if you don't like their policies, you don't have to use them. Regards, KAM
Re: Honeypot email addresses
On 12/2/2014 9:31 AM, Kevin A. McGrail wrote: On 12/2/2014 12:24 PM, Ted Mittelstaedt wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? For me, spam is always about minimizing collateral damage but it is far from an exact science and subject to friendly debate to improve things for everyone. Let's remember who the bastards are (the spammers) and not attack people's honeypots/DNSWLs, etc. because if you don't like their policies, you don't have to use them. Agreed, I will also point out I didn't start the attacks. I do not agree with the logic that using email addresses on a domain that have been deactivated for a long period of time - years that is - as honeypots is going to result in blocking a valid sender. My assertion got attacked - I refuted those attacks with logic - my assertion got attacked more with illogical statements like the one I just refuted a few minutes ago. Data from a single honeypot has some value. Data from hundreds of them has far, far more value. If some of those hundreds of honeypots are old email addresses that were bouncing mail for the last 5 years with unknown user then it isn't logical to assert that those will result in blocking a legitimate sender. At least, not in what I consider a reasonable filter. Ted Regards, KAM
Re: pdfinfo plugin
On Tue, 2 Dec 2014, Axb wrote: On 12/02/2014 11:58 AM, Stefan Jakobs wrote: Hello, I still use the pdfinfo plugin from Dallas Engelken (and it still hits on some messages). But does anyone know the status of the plugin? Is it maintained? I'm partially to blame this plugin exists - rule support, etc. Does it make sense to use it with spamassassin 3.4.0 yes, definitely or is a similar functionality already included there? nope... As PDF spams haven't been a huge issue lately I've been lazy with adding rules Not sure if rule creation was well documented - I'll try to put something together - it's been ages... Where does it live these days? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Men by their constitutions are naturally divided in to two parties: 1. Those who fear and distrust the people and wish to draw all powers from them into the hands of the higher classes. 2. Those who identify themselves with the people, have confidence in them, cherish and consider them as the most honest and safe, although not the most wise, depository of the public interests. -- Thomas Jefferson --- 13 days until Bill of Rights day
Re: Argument perl_version isn't numeric
On Tue, 2 Dec 2014, Burnie wrote:
On 12/02/2014 03:12 AM, John Hardin wrote:
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
On 12/1/2014 8:03 PM, John Hardin wrote:
For now, the only issue that has ever arisen in years is the 501
test so I would stick with just that for now.
Ok.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl 5.10
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
if version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit}
])/
endif
endif
Dec 2 03:53:48.550 [30251] warn: Argument perl_version isn't numeric in
numeric ge (=) at (eval 2521) line 2.
ARGH!
Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA releases.
- IMHO, that single '+' character may be the single most annoying character
in SA for years? :-\
indeed.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
---
13 days until Bill of Rights day
Re: Honeypot email addresses
Am 02.12.2014 um 18:24 schrieb Ted Mittelstaedt: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? surely, on *one* RBL Or are you saying that the spammers NEVER use throwaway accounts on those large providers? Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? no, i am saying nobody right in his mind is rejecting mails because *one* RBL but based on scores and with delisting after a few days - each honeypot one RBL if you put a lot of RBL's as well as a lot of DNSWL in the score mix you unlikely have false positives because *one* honeypot it only becomes a problem when the maintainers of honeypot's are dumb as bread and re-use previous legit addresses as trap or what i heard crazy people suggest register on porn sites with trap addresses the large ISP's like gmail are typically also on whitelists (including one of our internal) and so they need to hit a lot of honeypots within a short timeframe to get blocked, but if they do - so be it signature.asc Description: OpenPGP digital signature
Re: pdfinfo plugin
On 12/02/2014 07:02 PM, John Hardin wrote: On Tue, 2 Dec 2014, Axb wrote: On 12/02/2014 11:58 AM, Stefan Jakobs wrote: Hello, I still use the pdfinfo plugin from Dallas Engelken (and it still hits on some messages). But does anyone know the status of the plugin? Is it maintained? I'm partially to blame this plugin exists - rule support, etc. Does it make sense to use it with spamassassin 3.4.0 yes, definitely or is a similar functionality already included there? nope... As PDF spams haven't been a huge issue lately I've been lazy with adding rules Not sure if rule creation was well documented - I'll try to put something together - it's been ages... Where does it live these days? It doesn't... Has been in exile since many years... Have the last version in my SA repo and Dallas has given me permission to commit to SA. Will do the necessary license foo, cleanup the obsolete rules and commit...
Re: Honeypot email addresses
Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp3RZaW1KKvL.pgp Description: PGP signature
Re: Honeypot email addresses
Am 02.12.2014 um 19:22 schrieb Niamh Holding: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. you should re-consider that, your users problems as said: the linux.com newsletter get blocked by b.barracudacentral.org which is normally a trustful blacklist (their URIBL's on the devices are crap playing lottery with email) a since we replaced the device i receive it again (b.barracudacentral.org is still used, but as *one* RBL in the postscreen mix) another recent example: Spamhaus blocked GMX/11/Web.de completly *by a mistake*, no problem in case of scoring, a ruined weekend if we had used it as only source signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 12/02/2014 07:22 PM, Niamh Holding wrote: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. Could we stop beating this dead horse? There's way better places to discuss philosophy for example List Guidelines: http://www.new-spam-l.com/admin/faq.html List Information: https://spammers.dontlike.us/mailman/listinfo/list and the good old NANAE news.admin.net-abuse.email
Re: Argument perl_version isn't numeric
On 2014-12-02 10:10, John Hardin wrote:
On Tue, 2 Dec 2014, Burnie wrote:
On 12/02/2014 03:12 AM, John Hardin wrote:
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
On 12/1/2014 8:03 PM, John Hardin wrote:
For now, the only issue that has ever arisen in years is the 501
test so I would stick with just that for now.
Ok.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl 5.10
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
if version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit} ])/
endif
endif
Dec 2 03:53:48.550 [30251] warn: Argument perl_version isn't numeric in
numeric ge (=) at (eval 2521) line 2.
ARGH!
Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA releases.
- IMHO, that single '+' character may be the single most annoying character in
SA for years? :-\
indeed.
Does this show the error?
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit} ])/
endif
Perhaps the same trick can (almost) work again.
{^_^}
RE: Argument perl_version isn't numeric
-Original Message- From: Niamh Holding [mailto:ni...@fullbore.co.uk] Sent: Tuesday, December 02, 2014 7:27 AM To: users@spamassassin.apache.org Subject: Re: Argument perl_version isn't numeric Hello Noel, Tuesday, December 2, 2014, 4:57:08 AM, you wrote: NB 5.10 is only what, six years old? Surely anyone running anything older have far greater issues CentOS 5.11 doesn't go EOL until 2017 and it has 5.8.8 -- Best regards, Niamhmailto:ni...@fullbore.co.uk Which brings up the question, what is spamassassin being developed on? I like long term releases for obvious reasons - upgrading servers every year or two gets old. But it's nice to match the tool to the job, so it might be instructive to know what the development environment looks like so when upgrading or installing a new server one can match it, more or less... ...Kevin -- Kevin Miller Network/email Administrator, CBJ MIS Dept. 155 South Seward Street Juneau, Alaska 99801 Phone: (907) 586-0242, Fax: (907) 586-4500 Registered Linux User No: 307357
Re: Argument perl_version isn't numeric
On 12/2/2014 3:10 PM, jdow wrote:
On 2014-12-02 10:10, John Hardin wrote:
On Tue, 2 Dec 2014, Burnie wrote:
On 12/02/2014 03:12 AM, John Hardin wrote:
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
On 12/1/2014 8:03 PM, John Hardin wrote:
For now, the only issue that has ever arisen in years is the
501
test so I would stick with just that for now.
Ok.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl 5.10
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
if version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai}
\p{Digit} ])/
endif
endif
Dec 2 03:53:48.550 [30251] warn: Argument perl_version isn't
numeric in
numeric ge (=) at (eval 2521) line 2.
ARGH!
Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA releases.
- IMHO, that single '+' character may be the single most annoying
character in
SA for years? :-\
indeed.
Does this show the error?
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai}
\p{Digit} ])/
endif
Perhaps the same trick can (almost) work again.
{^_^}
There is no need for the other checks.
if can(Mail::SpamAssassin::Conf::perl_min_version_501) is enough
since it doesn't exist until 3.4.1.
If you are locally using SA trunk and writing your own rules that
require certain perl_versions, you can use the if perl_version = XYZ
logic without concern.
regards,
KAM
--
*Kevin A. McGrail*
President
Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422
http://www.pccc.com/
703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
kmcgr...@pccc.com mailto:kmcgr...@pccc.com
Re: pdfinfo plugin
On 12/02/2014 07:02 PM, John Hardin wrote: On Tue, 2 Dec 2014, Axb wrote: On 12/02/2014 11:58 AM, Stefan Jakobs wrote: Hello, I still use the pdfinfo plugin from Dallas Engelken (and it still hits on some messages). But does anyone know the status of the plugin? Is it maintained? I'm partially to blame this plugin exists - rule support, etc. Does it make sense to use it with spamassassin 3.4.0 yes, definitely or is a similar functionality already included there? nope... As PDF spams haven't been a huge issue lately I've been lazy with adding rules Not sure if rule creation was well documented - I'll try to put something together - it's been ages... Where does it live these days? John, I've commited the plugin and 20_pdfinfo.cf with historical rules disabled - mainly for documentation purposes. I'll probably add a few fuzzy rules to sandbox when I discover some new undetected PDF spams. Amazing how old this stuff is and can still be used. Axb
Re: Argument perl_version isn't numeric
On 2014-12-02 12:15, Kevin A. McGrail wrote:
On 12/2/2014 3:10 PM, jdow wrote:
On 2014-12-02 10:10, John Hardin wrote:
On Tue, 2 Dec 2014, Burnie wrote:
On 12/02/2014 03:12 AM, John Hardin wrote:
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
On 12/1/2014 8:03 PM, John Hardin wrote:
For now, the only issue that has ever arisen in years is the 501
test so I would stick with just that for now.
Ok.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl 5.10
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
if version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit} ])/
endif
endif
Dec 2 03:53:48.550 [30251] warn: Argument perl_version isn't numeric in
numeric ge (=) at (eval 2521) line 2.
ARGH!
Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA releases.
- IMHO, that single '+' character may be the single most annoying character in
SA for years? :-\
indeed.
Does this show the error?
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit} ])/
endif
Perhaps the same trick can (almost) work again.
{^_^}
There is no need for the other checks.
if can(Mail::SpamAssassin::Conf::perl_min_version_501) is enough since it
doesn't exist until 3.4.1.
If you are locally using SA trunk and writing your own rules that require
certain perl_versions, you can use the if perl_version = XYZ logic without
concern.
regards,
KAM
--
*Kevin A. McGrail*
President
Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422
http://www.pccc.com/
703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
kmcgr...@pccc.com mailto:kmcgr...@pccc.com
Perhaps test it just the same to see if the basic technique works? I suspect it
should. That way it may be a messy way to handle the problem without falling
into even nastier messes.
{o.o}
Re: Argument perl_version isn't numeric
On 12/02/2014 09:10 PM, jdow wrote:
Does this show the error?
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} \p{Digit}
])/
endif
It doesn't show the warning.
But the line starting with '' will generate a more severe warning
when the first line is 'true'. (SA lint exits with code 1)
Testing perl 5.16 / SA 3.4.0:
if version = 3.003001
version = 3.004000 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_10 /\w++/
endif
Dec 2 22:14:35.776 [31075] warn: config: failed to parse line,
skipping, in /etc/mail/spamassassin/local.cf: version 3.004000
perl_version = 5.018000
Dec 2 22:14:35.801 [31075] warn: lint: 1 issues detected, please rerun
with debug enabled for more information
- And if you put it all in one line with perl 5.10, SA lint will
complain about perl_version
--
Bernt 'Burnie' Pettersen /// DoD#2345
E-mail:bur...@dod.no /// URL:http://burnie.sh/
- Creative brains need creative workhours! -
Re: Argument perl_version isn't numeric
jdow wrote: John Hardin wrote: Bob Proulx wrote: I am hoping this won't make you gun-shy from continuing your fine work on the project. Please don't let this minor bump in the road discourage you from future work. That would be a tragedy for the project and for the users. Oh, it won't do that. It's just embarrassing as all hell to publicly step on my sword in this manner. Stepped in a richard, you did. (Read Terry Pratchett's Dodger if you must to get the term's meaning and origin.) I don't want to pour salt on the wound but if you can laugh at it then all is good. Laughter is the best medicine! I keep thinking of this classic Dilbert. I have been there myself too many times. :-) http://dilbert.com/strips/comic/1995-08-18/ Bob
Re: Argument perl_version isn't numeric
On 02/12/2014 23:10, Kevin A. McGrail wrote: 5.10 is only what, six years old? Surely anyone running anything older have far greater issues :) (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe but theyll join the 14 series this Christmas when I can take them offline to upgrade em, even -current is useing a 12 month old 5.18.1) There is a fairly consistent streak in some distros to backport patches to older versions rather than move the version forward. 5.8.8 is in pretty far spread use from my knowledge. Likely in antique versions of debian and Redhat (which again will have bigger issues), there surely must come a time when the line is drawn and say - you're unsupported from this_date, give them plenty of notice, I think 12 months notice is plenty of time for planned upgrades or devise workarounds, SA is not updated all that often, so a next major release would be about 12 months away, short of a serious exploit found anyway, so there's plenty of time for lazy admins to do what they actually get paid to do :)
Re: Honeypot email addresses
On 03/12/2014 03:07, Matthias Leisi wrote: On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org [1], we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. I see no difference, if I never have, never will, use say deletet...@ausics.net and its used as a trap address (actually used as examples in some of my pages/blog etc), *anyone* who sends to that address, has got it via means of scraping, it clearly means it was taken from a webpage, or a mailing list archive, if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address, and reputation, trust - my arse, again, no valid or legitimate reason to send to that trap address, its sole purpose in life is to catch those who spam, if one person sees it, they *will* be doing it to many many many others. Noel PS (for the spammers, since we know you scum read this list - that example is only 1 of 7 trap addresses over a couple of domains I use, exempt it, I'll still catch you out) Links: -- [1] http://dnswl.org
Re: Argument perl_version isn't numeric
On 03/12/2014 03:08, Benny Pedersen wrote: Noel Butler skrev den 2014-12-02 05:38: On 01/12/2014 22:27, Benny Pedersen wrote: Please turn of html never going to happen this will be added so to my sieve autoreader, eg i can save reading your hints of my own problems again Benny you dont need anyone to show you hints of your own problems hahaha
Re: Honeypot email addresses
.if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address ït is not really true. If a spammer sends to a list of addresses and among them is a spamtrap address a user might respond to that list and so you'd be blocking a legit ip or domain ! cheers 2014-12-02 20:04 GMT-03:00 Noel Butler noel.but...@ausics.net: On 03/12/2014 03:07, Matthias Leisi wrote: On Tue, Dec 2, 2014 at 3:19 PM, LuKreme krem...@kreme.com wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedt t...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Not necessarily. At dnswl.org, we use spamtraps as one input source to determine the trustworthiness of an IP - to list (and at what score) or if not to list. A single spamtrap hit over an extended period of time for a system with a high magnitude does not say much. And it's different if it's an ISP mailserver or an email marketing provider. I see no difference, if I never have, never will, use say deletet...@ausics.net and its used as a trap address (actually used as examples in some of my pages/blog etc), *anyone* who sends to that address, has got it via means of scraping, it clearly means it was taken from a webpage, or a mailing list archive, if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address, and reputation, trust - my arse, again, no valid or legitimate reason to send to that trap address, its sole purpose in life is to catch those who spam, if one person sees it, they *will* be doing it to many many many others. Noel PS (for the spammers, since we know you scum read this list - that example is only 1 of 7 trap addresses over a couple of domains I use, exempt it, I'll still catch you out)
Re: Argument perl_version isn't numeric
On Tue, 2 Dec 2014, jdow wrote:
On 2014-12-02 12:15, Kevin A. McGrail wrote:
On 12/2/2014 3:10 PM, jdow wrote:
On 2014-12-02 10:10, John Hardin wrote:
On Tue, 2 Dec 2014, Burnie wrote:
On 12/02/2014 03:12 AM, John Hardin wrote:
On Mon, 1 Dec 2014, Kevin A. McGrail wrote:
On 12/1/2014 8:03 PM, John Hardin wrote:
For now, the only issue that has ever arisen in years is the
501
test so I would stick with just that for now.
Ok.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7107
Just FYI: The nested if example in the patch/doc will still
give a lint warning for perl 5.10
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
if version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai}
\p{Digit} ])/
endif
endif
Dec 2 03:53:48.550 [30251] warn: Argument perl_version isn't
numeric in
numeric ge (=) at (eval 2521) line 2.
ARGH!
Well, I suppose we're back to hoping the distro maintainers accept the
perl_version patch for their LTR release versions of older SA
releases.
- IMHO, that single '+' character may be the single most annoying
character in
SA for years? :-\
indeed.
Does this show the error?
if can(Mail::SpamAssassin::Conf::perl_min_version_501)
version 3.004001 perl_version = 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai}
\p{Digit} ])/
endif
Perhaps the same trick can (almost) work again.
{^_^}
There is no need for the other checks.
if can(Mail::SpamAssassin::Conf::perl_min_version_501) is enough since
it
doesn't exist until 3.4.1.
If you are locally using SA trunk and writing your own rules that require
certain perl_versions, you can use the if perl_version = XYZ logic
without concern.
regards,
KAM
Perhaps test it just the same to see if the basic technique works? I suspect
it should. That way it may be a messy way to handle the problem without
falling into even nastier messes.
I suspect it will fail just the same. I think it's something related to
shortcut logic in evals in 5.8.x, but I couldn't find anything in the
various perl release notes that looked relevant to that.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
Running away is the coward's way out of a war;
appeasement is the coward's way into a war. -- Thorax
---
13 days until Bill of Rights day
Re: Honeypot email addresses
On 03/12/2014 09:18, Christian Grunfeld wrote: .if *anyone* sends *anything* to that address it is unsolicited mail - spam, so that IP sender is blacklisted and placed in a DNSBL as well because there is no possible legitimate reason to send to that address ït is not really true. If a spammer sends to a list of addresses and among them is a spamtrap address a user might respond to that list and so you'd be blocking a legit ip or domain ! It would be very rare, and if so you would ever more rare CC the entire list of addresses on your spam message - sure this was a lot more common in years gone by, but I've not seen any such evidence of it in almost 10 years, and if you did, well, that's not my problem, its the problem of your provider who obviously doesn't care enough to educate its users of the dangers of spam, period.
Re: Honeypot email addresses
On Dec 2, 2014, at 10:24 AM, Ted Mittelstaedt t...@ipinc.net wrote: On 12/2/2014 6:19 AM, LuKreme wrote: On Dec 1, 2014, at 10:28 PM, Ted Mittelstaedtt...@ipinc.net wrote: This is assuming of course that your instantly blocking everything from a sender that happens to email a honeypot. Right. That i the *point* of a honeypot. The only thing going to a honeypot is going to be a spammer. Most honeypots are not used in such a draconian fashion. Every single one I’ve ever seen has. i see tons of spam relayed through throwaway accounts on Yahoo, and even some from Gmail and Microsoft's various domains. This is to all manner of accounts, both valid and invalid, former accounts and accounts that never existed. So your saying it's OK to block those because you get a piece of spam from them to a honeypot? If a message claims to come from Yahoo and comes from xyz.tl it is already rejected. Or are you saying that with your honeypots that the large providers get a free pass to spam you when they email your honeypots? I don’t recall ever saying I had my own honeypots. -- Some books are undeservedly forgotten; none are undeservedly remembered
Re: Honeypot email addresses
On Dec 2, 2014, at 11:28 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.12.2014 um 19:22 schrieb Niamh Holding: Hello Reindl, Tuesday, December 2, 2014, 6:14:26 PM, you wrote: RH no, i am saying nobody right in his mind is rejecting mails because RH *one* RBL You do say the sweetest things! Should I be offended given that we block at SMTP time if an IP address is listed in just one of a chosen selection of RBLs... known senders are whitelisted prior to RBL checking. you should re-consider that, your users problems as said: the linux.com newsletter get blocked by b.barracudacentral.org which is normally a trustful blacklist (their URIBL's on the devices are crap playing lottery with email) a since we replaced the device i receive it again (b.barracudacentral.org is still used, but as *one* RBL in the postscreen mix) I have *never* considered Barracuda to be reliable. At least they have stopped their practice of listing my server and then sending me spam offering to sell me their crapware to keep it off blacklists for per month. another recent example: Spamhaus blocked GMX/11/Web.de completly *by a mistake*, no problem in case of scoring, a ruined weekend if we had used it as only source The extremely occasional mistaken black is more than made up for by the vast quantities of spam that are blocked every day. I reject at SMTP based on zen. If zen is mistaken, at least the sender doesn’t think the mail as delivered and f they (and their MUA) are competent, they know WHY their mail didn’t go through. -- Oh, the sweet wine of youth goes sour over time Seems like the more that you lose, the more you ache to find
spamassassin on fc20 improving accuracy
Hello, I've got a Postfix/Amavis/Spamassassin/Clamav setup running on an fc20 machine. It's all working except for the SA part, which is working that is it tags messages as spam or in my case not spam I see the headers. The problem is I'm using a completely virtual users setup user information comes out of MySQL, and I'm not sure SA is working as well as it should, pyzor, dcc, razor checks, bayes, I've not got any of that going and no new rules, I try to update them with sa-update and get nothing indicating success or failure. The issue is email that should be tagged as spam, I look at it and it's spam, is not being tagged. My program versions and are all installed via rpm packages, are Postfix 2.10, amavisd-new 2.91, Spamassassin 3.4.0, Perl 5.18, pyzor 0.5.0. I'd appreciate any suggestions as to how to improve accuracy. Thanks. Dave.
Re: Argument perl_version isn't numeric
On 12/2/2014 5:50 PM, Noel Butler wrote: On 02/12/2014 23:10, Kevin A. McGrail wrote: 5.10 is only what, six years old? Surely anyone running anything older have far greater issues :) (says the guy running a few slackware 13.1 boxes with 5.10.1 hehe but theyll join the 14 series this Christmas when I can take them offline to upgrade em, even -current is useing a 12 month old 5.18.1) There is a fairly consistent streak in some distros to backport patches to older versions rather than move the version forward. 5.8.8 is in pretty far spread use from my knowledge. Likely in antique versions of debian and Redhat (which again will have bigger issues), there surely must come a time when the line is drawn and say - you're unsupported from this_date, give them plenty of notice, I think 12 months notice is plenty of time for planned upgrades or devise workarounds, SA is not updated all that often, so a next major release would be about 12 months away, short of a serious exploit found anyway, so there's plenty of time for lazy admins to do what they actually get paid to do :) Well, I also can't justify requiring a newer version of Perl just for one regexp. Regards, KAM
Re: Argument perl_version isn't numeric
On 03/12/2014 12:10, Kevin A. McGrail wrote: Likely in antique versions of debian and Redhat (which again will have bigger issues), there surely must come a time when the line is drawn and say - you're unsupported from this_date, give them plenty of notice, I think 12 months notice is plenty of time for planned upgrades or devise workarounds, SA is not updated all that often, so a next major release would be about 12 months away, short of a serious exploit found anyway, so there's plenty of time for lazy admins to do what they actually get paid to do :) Well, I also can't justify requiring a newer version of Perl just for one regexp. Regards, KAM Sure, if that was truly the case nor would I, but if you are running that old perl, there is plenty of stuff thats outdated, and not all of the goodness gets backports, not just with perl, but with most other things.
different results when using --debug
i was testing with a sample message, and noticed that when running manually with --debug, there seem to be numerous differences in the results, such as scores for the same tests differing, visual ordering of results differing [is this significant?], and bayes not being listed when using --debug. am i doing something wrong? are my expectations misguided? i'm doing these tests as the user named amavis, which the amavis software runs as. spamassassin --test-mode --debug message3.txt Dec 2 23:32:41.224 [27222] dbg: logger: adding facilities: all Dec 2 23:32:41.224 [27222] dbg: logger: logging level is DBG Dec 2 23:32:41.224 [27222] dbg: generic: SpamAssassin version 3.4.0 Dec 2 23:32:41.224 [27222] dbg: generic: Perl 5.020001, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin Dec 2 23:32:41.224 [27222] dbg: config: timing enabled Dec 2 23:32:41.225 [27222] dbg: config: score set 0 chosen. Dec 2 23:32:41.226 [27222] dbg: util: running in taint mode? yes [...] Content analysis details: (10.7 points, 5.0 required) pts rule name description -- -- 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: ialloansystems.com] 1.7 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: ialloansystems.com] 1.6 RCVD_IN_BRBL_LASTEXT RBL: No description available. [94.73.46.5 listed in bb.barracudacentral.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 2.0 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/) 2.4 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 1.7 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 0.0 DIGEST_MULTIPLEMessage hits more than one network digest check -0.8 AWLAWL: From: address is in the auto white-list Dec 2 23:32:44.364 [27222] dbg: check: tagrun - tag DKIMDOMAIN is still blocking action 0 Dec 2 23:32:44.366 [27222] dbg: plugin: Mail::SpamAssassin::Plugin::MIMEHeader=HASH(0x2cb2be0) implements 'finish_tests', priority 0 Dec 2 23:32:44.366 [27222] dbg: plugin: Mail::SpamAssassin::Plugin::Check=HASH(0x2cb2e80) implements 'finish_tests', priority 0 Dec 2 23:32:44.388 [27222] dbg: netset: cache trusted_networks hits/attempts: 10/11, 90.9 % Dec 2 23:32:44.397 [27222] dbg: bayes: untie-ing spamassassin --test-mode message3.txt Received: from localhost by mfa.example.com with SpamAssassin (version 3.4.0); Tue, 02 Dec 2014 23:34:52 -0500 [...] Content analysis details: (8.9 points, 5.0 required) pts rule name description -- -- 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. [94.73.46.5 listed in bb.barracudacentral.org] 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: ialloansystems.com] 1.6 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: ialloansystems.com] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.] 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 1.4 PYZOR_CHECKListed in Pyzor (http://pyzor.sf.net/) 1.9 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 0.3 DIGEST_MULTIPLEMessage hits more than one network digest check 1.1 AWLAWL: From: address is in the auto white-list
