SpamAssassin not parsing/sseing all headers?
Hi! I'm using SpamAssassin in an amavisd-new/Milter setup. Recently, I found some mails from a mailinglist, which contained a whopping 48 identical (!) DKIM Headers - in some cases the amount of headers would exceed 32KB! SpamAssassin was tagging these mails as spam, since it couldn't see Date:/Subject: and other headers. My interim "solution" is to delete the DKIM headers. But the real questing is: Why is SA not seeing all the headers? -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin https://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: SpamAssassin not parsing/seeing all headers?
* Ralf Hildebrandt : > But the real question is: Why is SA not seeing all the headers? Looking at the archives, I find this: https://lists.gt.net/spamassassin/users/172198 "Specifically, I have been adding characters and addresses to the list of email addresses in the To: header to see at what point my rule stops being hit. As far as I can tell, it is a byte limit, not a number of email addresses limit. The byte limit (at least in my configuration) seems to be approximately 8KB" And: "Pretty sure it's hardcoded at 8k. This was done several years ago to protect against DoS type situations." If that's the case, is that limit still up-to-date? The default in Postfix (bytes): # postconf -d header_size_limit header_size_limit = 102400 But curently we're using a conservativ 32KB instead. -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin https://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: Outgoing email without DMARC
On Mon, 1 May 2017 19:30:01 -0700 Marc Perkel wrote: > Might be slightly off topic but I've been running into more delivery > problems with outgoing email because I don't use DMARC. How do you know it's because you don't use DMARC.
Re: short-circuit ALL_TRUSTED
On Mon, 01 May 2017 12:26:55 -0400 micah anderson wrote: > internal_networks 10.0. > > but things are not shortcircuiting, you can see it is finding the > relay as trusted and internal in this line: > > Apr 24 15:32:38.862 [29876] dbg: received-header: relay 10.0.1.163 > trusted? yes internal? yes msa? no > > but I'm not clear how it decides if it should short circuit or not. > Can anyone clarify? > X-Spam-Status: No, ... UNPARSEABLE_RELAY It's because the other received header is not parseable, UNPARSEABLE_RELAY prevents ALL_TRUSTED from being hit. Probably because it's missing "by " >Received: from [127.0.0.1] (localhost [127.0.0.1]) > (Authenticated sender: foodefai) > with ESMTPSA id 7492F1C05F2
Re: SpamAssassin not parsing/seeing all headers?
On Tue, 2 May 2017 12:42:52 +0200 Ralf Hildebrandt wrote: > * Ralf Hildebrandt : > > > But the real question is: Why is SA not seeing all the headers? > > Looking at the archives, I find this: > https://lists.gt.net/spamassassin/users/172198 > > "Specifically, I have been adding characters and addresses to the > list of email addresses in the To: header to see at what point my > rule stops being hit. As far as I can tell, it is a byte limit, not a > number of email addresses limit. > > The byte limit (at least in my configuration) seems to be > approximately 8KB" > > And: > > "Pretty sure it's hardcoded at 8k. This was done several years ago to > protect against DoS type situations." That's the limit for a specific header. The relevant limit here is the limit for total headers of 64k.
Re: SpamAssassin not parsing/seeing all headers?
On Tue, 2 May 2017 14:14:19 +0200 Reindl Harald wrote: against DoS type situations." > > > > > > That's the limit for a specific header. The relevant limit here is > > the limit for total headers of 64k. > > that's both too low and makes it easiy to bypass SA It wouldn't make it bypass SA. > 64 KB - have you seen typical headers from microsoft these days as > well as others? They are much smaller than that. It remains to be seen whether this limit is causing the OPs problem. > 8 KB - well, if someone encodes his whole payload base64 encoded in > the subject you are there It's pretty unlikely that anyone is going to read a subject beyond the first 8K of decoded text.
Re: Outgoing email without DMARC
On 5/1/2017 10:30 PM, Marc Perkel wrote: Might be slightly off topic but I've been running into more delivery problems with outgoing email because I don't use DMARC. I don't know a lot about it but is there some simple way I can get around this? Kind of a pain in the rear. Marc, This probably has more to do with DKIM than DMARC? Either way... you're not willing to jump (or haven't yet jumped) though the hoops that the largest ISPs/hosters want us all to jump through... meanwhile... so many of them (and for many many years) have sent such high volumes AND high percentages of outbound spam to all of our SMTPs - to such an extent that you and I would be out of business if our SMTP outbound traffic did that for just one week. I sort of wish they (or many of them... "if the shoe fits...") would clean up their own act FIRST - get the basics done FIRST - before imposing new standards on the rest of us. I'm in the same boat - I'm now having to set aside dozens of hours to get all various domains updated to DKIM so that they'll have more success sending to a certain large/famous hoster - who has sent my server a shitload of spam over the past several years (not just volume-wise - but percentage-wise... I'd be run out of town if I did that) -- Rob McEwen
Re: SpamAssassin not parsing/seeing all headers?
On Tue, 2 May 2017 14:04:48 +0100 RW wrote: > > 64 KB - have you seen typical headers from microsoft these days as > > well as others? > > They are much smaller than that. It remains to be seen whether this > limit is causing the OPs problem. And I don't think it is. The 64k limit doesn't seem to affect "exists:" rules. Perhaps there's something in amavisd-new that can't cope with the dkim headers and has done something that breaks SA's header parsing. This wouldn't necessarily show-up in the delivered email. Try running one through spamassassin -D.
Re: SpamAssassin not parsing/seeing all headers?
> Perhaps there's something in amavisd-new that can't cope with the > dkim headers and has done something that breaks SA's header parsing. > This wouldn't necessarily show-up in the delivered email. Indeed. amavisd+SA says: X-Spam-Status: Yes, score=5.763 tagged_above=2 required=4 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, EMPTY_MESSAGE=2.32, MISSING_DATE=1.36, MISSING_FROM=1, MISSING_HEADERS=1.021, MISSING_MID=0.497, MISSING_SUBJECT=1.799, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, TXREP=-0.842, CRM114.UNSURE(-2.55)=0.510] autolearn=no autolearn_force=no while piping the mail through spamassassin -D says: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID shortcircuit=no autolearn=no autolearn_force=no version=3.4.1 -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebra...@charite.deCampus Benjamin Franklin https://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Re: Outgoing email without DMARC
On 05/02/17 03:54, RW wrote: On Mon, 1 May 2017 19:30:01 -0700 Marc Perkel wrote: Might be slightly off topic but I've been running into more delivery problems with outgoing email because I don't use DMARC. How do you know it's because you don't use DMARC. The rejection message specified dmarc as the reason. -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: Outgoing email without DMARC
On 05/02/17 07:14, Rob McEwen wrote: On 5/1/2017 10:30 PM, Marc Perkel wrote: Might be slightly off topic but I've been running into more delivery problems with outgoing email because I don't use DMARC. I don't know a lot about it but is there some simple way I can get around this? Kind of a pain in the rear. Marc, This probably has more to do with DKIM than DMARC? Either way... you're not willing to jump (or haven't yet jumped) though the hoops that the largest ISPs/hosters want us all to jump through... meanwhile... so many of them (and for many many years) have sent such high volumes AND high percentages of outbound spam to all of our SMTPs - to such an extent that you and I would be out of business if our SMTP outbound traffic did that for just one week. I sort of wish they (or many of them... "if the shoe fits...") would clean up their own act FIRST - get the basics done FIRST - before imposing new standards on the rest of us. I'm in the same boat - I'm now having to set aside dozens of hours to get all various domains updated to DKIM so that they'll have more success sending to a certain large/famous hoster - who has sent my server a shitload of spam over the past several years (not just volume-wise - but percentage-wise... I'd be run out of town if I did that) Yeah - I know what you mean. Many of these ISPs would be blacklisted if they weren't so big. I get an amazing amount of spam from the big guys. I was just wondering what I could do to get by. -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: ANY_BOUNCE_MESSAGE questions
On 30 Apr 2017, at 10:17, David Jones wrote: 99_mailspike.cf --- shortcircuit RCVD_IN_MSPIKE_H5 on score RCVD_IN_MSPIKE_H4 -3.2 score RCVD_IN_MSPIKE_H3 -2.2 score RCVD_IN_MSPIKE_H2 -1.2 score RCVD_IN_MSPIKE_WL -0.82 score RCVD_IN_MSPIKE_BL 1.2 score RCVD_IN_MSPIKE_L2 0.2 score RCVD_IN_MSPIKE_L3 1.2 score RCVD_IN_MSPIKE_L4 2.2 score RCVD_IN_MSPIKE_L5 3.2 Scoring RCVD_IN_MSPIKE_WL and RCVD_IN_MSPIKE_BL so strongly seems odd, as those will always hit if any of the RCVD_IN_MSPIKE_H* and RCVD_IN_MSPIKE_L* respectively. Also, in my experience those scores vastly overvalue the "good" classes. I have received every major class of spam from H4 and H3 sources, including trojans, advance fee fraud, bank phishing, ISP phishing, penis pill ads, replica watch ads, and whois-scraped solicitation for various sorts of domain promotion (violating the whois data usage rules of the relevant domain registries.) There has also been a few bits of "mainsleaze" spam (nominally legitimate companies adhering to relevant laws) but those tend to come more from H5 sources. Perversely, H2 is a better correlated to non-spamminess than either H3 or H4 in my recent (2015-now) logs and this is consistent with the scores determined by the RuleQA process: H2 is stronger than H5 and all the other rules are scores +/- 0.01
Mailspike scores
I was checking to see what the scores for mailspike were on my server and I noticed that there are two sets of scores. 50_scores.cf: score RCVD_IN_MSPIKE_ZBI 2.7 50_scores.cf: score RCVD_IN_MSPIKE_L5 2.5 50_scores.cf: score RCVD_IN_MSPIKE_L4 1.7 50_scores.cf: score RCVD_IN_MSPIKE_L3 0.9 50_scores.cf: score RCVD_IN_MSPIKE_H3 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H4 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H5 -1.0 50_scores.cf: score RCVD_IN_MSPIKE_BL 0.01 50_scores.cf: score RCVD_IN_MSPIKE_WL -0.01 72_scores.cf:score RCVD_IN_MSPIKE_BL 0.001 0.010 0.001 0.010 72_scores.cf:score RCVD_IN_MSPIKE_H2 0.001 -2.800 0.001 -2.800 72_scores.cf:score RCVD_IN_MSPIKE_H3 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H4 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H5 0.001 -1.000 0.001 -1.000 72_scores.cf:score RCVD_IN_MSPIKE_L2 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L3 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L4 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L5 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_WL 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_ZBI0.001 0.001 0.001 0.001 Is this expected? -- Bowie
Re: Outgoing email without DMARC
Am 02.05.2017 um 17:09 schrieb Marc Perkel: > > > On 05/02/17 03:54, RW wrote: >> On Mon, 1 May 2017 19:30:01 -0700 >> Marc Perkel wrote: >> >>> Might be slightly off topic but I've been running into more delivery >>> problems with outgoing email because I don't use DMARC. >> How do you know it's because you don't use DMARC. >> >> > > The rejection message specified dmarc as the reason. may you provide - src ip - RFC5321.MailFrom - RFC5322.From - the rejection message Andreas
Re: Mailspike scores
On Tue, 2 May 2017, Bowie Bailey wrote: I was checking to see what the scores for mailspike were on my server and I noticed that there are two sets of scores. 50_scores.cf: score RCVD_IN_MSPIKE_ZBI 2.7 50_scores.cf: score RCVD_IN_MSPIKE_L5 2.5 50_scores.cf: score RCVD_IN_MSPIKE_L4 1.7 50_scores.cf: score RCVD_IN_MSPIKE_L3 0.9 50_scores.cf: score RCVD_IN_MSPIKE_H3 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H4 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H5 -1.0 50_scores.cf: score RCVD_IN_MSPIKE_BL 0.01 50_scores.cf: score RCVD_IN_MSPIKE_WL -0.01 72_scores.cf:score RCVD_IN_MSPIKE_BL 0.001 0.010 0.001 0.010 72_scores.cf:score RCVD_IN_MSPIKE_H2 0.001 -2.800 0.001 -2.800 72_scores.cf:score RCVD_IN_MSPIKE_H3 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H4 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H5 0.001 -1.000 0.001 -1.000 72_scores.cf:score RCVD_IN_MSPIKE_L2 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L3 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L4 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L5 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_WL 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_ZBI0.001 0.001 0.001 -1.001 Is this expected? 50_scores is handcoded default scores, 72_scores is generated from masscheck. -- 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 --- How do you argue with people to whom math is an opinion? -- Unknown --- 6 days until the 72nd anniversary of VE day
Re: Mailspike scores
On 5/2/2017 11:53 AM, John Hardin wrote: On Tue, 2 May 2017, Bowie Bailey wrote: I was checking to see what the scores for mailspike were on my server and I noticed that there are two sets of scores. 50_scores.cf: score RCVD_IN_MSPIKE_ZBI 2.7 50_scores.cf: score RCVD_IN_MSPIKE_L5 2.5 50_scores.cf: score RCVD_IN_MSPIKE_L4 1.7 50_scores.cf: score RCVD_IN_MSPIKE_L3 0.9 50_scores.cf: score RCVD_IN_MSPIKE_H3 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H4 -0.01 50_scores.cf: score RCVD_IN_MSPIKE_H5 -1.0 50_scores.cf: score RCVD_IN_MSPIKE_BL 0.01 50_scores.cf: score RCVD_IN_MSPIKE_WL -0.01 72_scores.cf:score RCVD_IN_MSPIKE_BL 0.001 0.010 0.001 0.010 72_scores.cf:score RCVD_IN_MSPIKE_H2 0.001 -2.800 0.001 -2.800 72_scores.cf:score RCVD_IN_MSPIKE_H3 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H4 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_H5 0.001 -1.000 0.001 -1.000 72_scores.cf:score RCVD_IN_MSPIKE_L2 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L3 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L4 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_L5 0.001 0.001 0.001 0.001 72_scores.cf:score RCVD_IN_MSPIKE_WL 0.001 -0.010 0.001 -0.010 72_scores.cf:score RCVD_IN_MSPIKE_ZBI0.001 0.001 0.001 -1.001 Is this expected? 50_scores is handcoded default scores, 72_scores is generated from masscheck That's what I thought, but what's the point of having handcoded scores that are overridden by the generated scores? -- Bowie
Re: Mailspike scores
On Tue, 2 May 2017, Bowie Bailey wrote: On 5/2/2017 11:53 AM, John Hardin wrote: On Tue, 2 May 2017, Bowie Bailey wrote: > I was checking to see what the scores for mailspike were on my server > and I noticed that there are two sets of scores. > > Is this expected? 50_scores is handcoded default scores, 72_scores is generated from masscheck That's what I thought, but what's the point of having handcoded scores that are overridden by the generated scores? Reasonable default values are always a good idea. -- 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 --- USMC Rules of Gunfighting #4: If your shooting stance is good, you're probably not moving fast enough nor using cover correctly. --- 6 days until the 72nd anniversary of VE day
Re: ANY_BOUNCE_MESSAGE questions
On Mon, 2017-05-01 at 17:13 +0200, Matus UHLAR - fantomas wrote: Is there something on vbounce that does notappl for you? loading it and settings proper whitelist_bounce_relays should hit all bounces that did not come as response to mail from your systems... On 01.05.17 19:11, Martin Gregorie wrote: Obvious spam was being rejected by apparently legit MTAswhich weren't using SPF checks before bouncing the spam. Their wrappers looked legit and the rejected spam had either my usual address or the address of my POP3 mailbox on my ISP's mailhost forged as the sender. vbounce certainly didn't stop any of this stuff (mostly Russian girlie spam) it's not supposed to stop it, but to detect it. classic score is 0.1 iirc. note that bounces that contain your relays (see whitelist_bounce_relays) are not scored. maybe you just did not set up whitelist_bounce_relays? or I would not have concocted my mail bounce rule, which I did around Oct 2014 - Jan 2015: did vbounce even exist then? and long long before... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Re: Outgoing email without DMARC
On Mon, 1 May 2017 19:30:01 -0700 Marc Perkel wrote: Might be slightly off topic but I've been running into more delivery problems with outgoing email because I don't use DMARC. On 05/02/17 03:54, RW wrote: How do you know it's because you don't use DMARC. On 02.05.17 08:09, Marc Perkel wrote: The rejection message specified dmarc as the reason. show us the message. Doesn't it just recommmend using DMARC as one of ways to fix your problem? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse
Re: Mailspike scores
On Tue, 2 May 2017 09:20:49 -0700 (PDT) John Hardin wrote: > On Tue, 2 May 2017, Bowie Bailey wrote: > > > On 5/2/2017 11:53 AM, John Hardin wrote: > >> On Tue, 2 May 2017, Bowie Bailey wrote: > >> > >> > I was checking to see what the scores for mailspike were on my > >> > server and I noticed that there are two sets of scores. > >> > > >> > Is this expected? > >> > >> 50_scores is handcoded default scores, 72_scores is generated from > >> masscheck > > > > That's what I thought, but what's the point of having handcoded > > scores that are overridden by the generated scores? > > Reasonable default values are always a good idea. It looks like 72_scores only holds scores for rules from 72_active.cf plus scores for MSPIKE rules and SURBL_BLOCKED (what's that doing there?). If 72_scores holds generated scores why are so many of then 1.000? You say that 50_scores is "handcoded default scores", but at the top of the file there's a big block of scores that are claimed to have been set by perceptron, which I understand fell-off a long time ago. They certainly look autogenerated. On the face of it it looks a lot of the rules I assumed were autoscored are using scores generated years ago.
Re: Mailspike scores
On Tue, 2 May 2017, RW wrote: On Tue, 2 May 2017 09:20:49 -0700 (PDT) John Hardin wrote: On Tue, 2 May 2017, Bowie Bailey wrote: On 5/2/2017 11:53 AM, John Hardin wrote: On Tue, 2 May 2017, Bowie Bailey wrote: I was checking to see what the scores for mailspike were on my server and I noticed that there are two sets of scores. Is this expected? 50_scores is handcoded default scores, 72_scores is generated from masscheck That's what I thought, but what's the point of having handcoded scores that are overridden by the generated scores? Reasonable default values are always a good idea. It looks like 72_scores only holds scores for rules from 72_active.cf plus scores for MSPIKE rules and SURBL_BLOCKED (what's that doing there?). If 72_scores holds generated scores why are so many of then 1.000? Limits? You say that 50_scores is "handcoded default scores", but at the top of the file there's a big block of scores that are claimed to have been set by perceptron, which I understand fell-off a long time ago. They certainly look autogenerated. Check the revision history in SVN. http://svn.apache.org/viewvc/spamassassin/trunk/rules/50_scores.cf On the face of it it looks a lot of the rules I assumed were autoscored are using scores generated years ago. Potentially. I have not done a detailed review. -- 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 --- Maxim IV: Close air support covereth a multitude of sins. --- 6 days until the 72nd anniversary of VE day
Any ETA as to when rule updates will begin again?
Back on the 15th of March this was posted to the list: "I posted this to the dev and ruleqa mailing lists, then realized that it is also relevant to people on this list who run rule updates. We are in the process of migrating off old machines to a new one for the masschecks and rule update processing. Unfortunately the required shutdown of the old machines has happened before everything was complete on the replacement. The existing data is safe and is being migrated. However submission of new masscheck data and generation and download of rule updates are not running until the new machine is brought up. I don't have a specific ETA for the new machine right now, just the assurance that the work is in progress. I'll post more details when I get them. Regards, Sidney Markowitz Chair, Apache SpamAssassin Project Management Committee" Since it's now been a month and a half is there any ETA as to when rule updates will begin again? I've been showing the same channel version since 16 March as shown in the attached. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 19:43:42 up 1 day, 2:26, 1 user, load average: 0.29, 0.27, 0.20 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-77-generic --- Begin Message --- May 2 12:02:04.234 [6197] dbg: logger: adding facilities: all May 2 12:02:04.234 [6197] dbg: logger: logging level is DBG May 2 12:02:04.234 [6197] dbg: generic: SpamAssassin version 3.4.1 May 2 12:02:04.234 [6197] dbg: generic: Perl 5.022001, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin May 2 12:02:04.234 [6197] dbg: config: timing enabled May 2 12:02:04.235 [6197] dbg: config: score set 0 chosen. May 2 12:02:04.241 [6197] dbg: generic: sa-update version svn1652181 May 2 12:02:04.241 [6197] dbg: generic: using update directory: /var/lib/spamassassin/3.004001 May 2 12:02:05.002 [6197] dbg: diag: perl platform: 5.022001 linux May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: Digest::SHA1, version 2.13 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: HTML::Parser, version 3.72 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: Net::DNS, version 0.81 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: NetAddr::IP, version 4.078 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: Time::HiRes, version 1.9726 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: Archive::Tar, version 2.04 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: IO::Zlib, version 1.10 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: Digest::SHA1, version 2.13 May 2 12:02:05.002 [6197] dbg: diag: [...] module installed: MIME::Base64, version 3.15 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: DB_File, version 1.835 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Net::SMTP, version 3.05 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Mail::SPF, version v2.009 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Geo::IP, version 1.45 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Net::CIDR::Lite, version 0.21 May 2 12:02:05.003 [6197] dbg: diag: [...] module not installed: Razor2::Client::Agent ('require' failed) May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: IO::Socket::IP, version 0.37 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: IO::Socket::INET6, version 2.72 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: IO::Socket::SSL, version 2.024 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Compress::Zlib, version 2.068 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Mail::DKIM, version 0.4 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: DBI, version 1.634 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Getopt::Long, version 2.45 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: LWP::UserAgent, version 6.15 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: HTTP::Date, version 6.02 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Encode::Detect::Detector, version 1.01 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Net::Patricia, version 1.22 May 2 12:02:05.003 [6197] dbg: diag: [...] module installed: Net::DNS::Nameserver, version 1276 May 2 12:02:05.004 [6197] dbg: gpg: adding key id 6C6191E3 May 2 12:02:05.004 [6197] dbg: gpg: adding key id E8B493D6 May 2 12:02:05.004 [6197] dbg: gpg: Searching for 'gpg' May 2 12:02:05.004 [6197] dbg: util: current PATH is: /usr/bin:/bin May 2 12:02:05.004 [6197] dbg: util: executable for gpg was found at /usr/bin/gpg May 2 12:02:05.004 [6197] dbg: gpg: found /usr/bin/gpg May 2 12:02:05.028 [6197] dbg: gpg: release trusted key id list: 0C2B1D7175B852C64B3CDC716C55397824F434CE 6C6191E3 E8B493D6 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 May 2 12:02:
Re: Any ETA as to when rule updates will begin again?
On 5/2/2017 8:52 PM, Chris wrote: Since it's now been a month and a half is there any ETA as to when rule updates will begin again? I've been showing the same channel version since 16 March as shown in the attached. As a volunteer project, there is no ETA. I can tell you my goal is to get it running before ApacheCon in Miami in 2 weeks and perhaps to have a Hackathon during the Con to get it running if it isn't fixed beforehand. There is work going on to get it back online but there have been no substantial rule changes that it would be a silver bullet so there is very little concern that it is down at the moment beyond that fact that it makes building a release difficult without rewriting the release build process. Which I've been doing anyway so we aren't dependent on that infrastructure anyway. Regards, KAM
Re: Any ETA as to when rule updates will begin again?
On Tue, 2017-05-02 at 21:52 -0400, Kevin A. McGrail wrote: > On 5/2/2017 8:52 PM, Chris wrote: > > > > Since it's now been a month and a half is there any ETA as to when > > rule > > updates will begin again? I've been showing the same channel > > version > > since 16 March as shown in the attached. > As a volunteer project, there is no ETA. I can tell you my goal is > to > get it running before ApacheCon in Miami in 2 weeks and perhaps to > have > a Hackathon during the Con to get it running if it isn't fixed > beforehand. > > There is work going on to get it back online but there have been no > substantial rule changes that it would be a silver bullet so there > is > very little concern that it is down at the moment beyond that fact > that > it makes building a release difficult without rewriting the release > build process. Which I've been doing anyway so we aren't dependent > on > that infrastructure anyway. > > Regards, > > KAM > Thanks for the update Kevin, much appreciated. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 20:54:43 up 1 day, 3:37, 1 user, load average: 0.16, 0.19, 0.22 Description:Ubuntu 16.04.2 LTS, kernel 4.4.0-77-generic signature.asc Description: This is a digitally signed message part