Re: NULL_IN_BODY: 1.6
Am 01.11.2014 um 21:20 schrieb Reindl Harald: > > > Am 01.11.2014 um 21:16 schrieb Robert Schetterer: >> Am 01.11.2014 um 20:10 schrieb Reindl Harald: >>> well, a message from china with a NULL char runied my saturday by freeze >>> our lmtpd-service again and again >> >> something for dovecot list ? > > nope -dbmail, sample is already upstream > >> - i grep'ed the last months maillog >>> and it was the only hit of this rule >>> >>> should that not be a block score? >>> (yes with milter SA rejects) >>> >>> 1.6 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message >>> >>> UPDATED: /etc/mail/spamassassin/local.cf >>> 238a239 >>> > score NULL_IN_BODY 8.0 >>> >> >> should be a good hint , if in trouble > > even better one of this two (postfix) where on the MX running SA i > prefer reject and on submisssion servers and ocal relays for webservers > the strip variant (recently added to any postfix instance here) > > message_reject_characters = \0 > message_strip_characters = \0 > i see its in postfix examples i had two NULL_IN_BODY in Oktober , but one was no SPAM comming from a german server and german domain, looks like newsletter their website is ok, so in rare cases it may produce false positve Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: NULL_IN_BODY: 1.6
Am 01.11.2014 um 21:16 schrieb Robert Schetterer: Am 01.11.2014 um 20:10 schrieb Reindl Harald: well, a message from china with a NULL char runied my saturday by freeze our lmtpd-service again and again something for dovecot list ? nope -dbmail, sample is already upstream - i grep'ed the last months maillog and it was the only hit of this rule should that not be a block score? (yes with milter SA rejects) 1.6 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message UPDATED: /etc/mail/spamassassin/local.cf 238a239 > score NULL_IN_BODY 8.0 should be a good hint , if in trouble even better one of this two (postfix) where on the MX running SA i prefer reject and on submisssion servers and ocal relays for webservers the strip variant (recently added to any postfix instance here) message_reject_characters = \0 message_strip_characters = \0 signature.asc Description: OpenPGP digital signature
Re: NULL_IN_BODY: 1.6
Am 01.11.2014 um 20:10 schrieb Reindl Harald: > well, a message from china with a NULL char runied my saturday by freeze > our lmtpd-service again and again something for dovecot list ? - i grep'ed the last months maillog > and it was the only hit of this rule > > should that not be a block score? > (yes with milter SA rejects) > > 1.6 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message > > UPDATED: /etc/mail/spamassassin/local.cf > 238a239 > > score NULL_IN_BODY 8.0 > should be a good hint , if in trouble Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
NULL_IN_BODY: 1.6
well, a message from china with a NULL char runied my saturday by freeze our lmtpd-service again and again - i grep'ed the last months maillog and it was the only hit of this rule should that not be a block score? (yes with milter SA rejects) 1.6 NULL_IN_BODY FULL: Message has NUL (ASCII 0) byte in message UPDATED: /etc/mail/spamassassin/local.cf 238a239 > score NULL_IN_BODY 8.0 signature.asc Description: OpenPGP digital signature
RE: dns: sendto() to [127.0.0.1]:53 failed: Connection refused, no more alternatives
Hi > I guess to make a long story short for some reason I have to restart SA after > a kernel update however I have no idea why and I'll have to test this theory > after the next kernel update. Is it possible this happens after every reboot? (it might look like a kernel update when you only reboot for kernel updates). SA checks for dns availability on start, maybe it gets confused if the resolver is not ready yet. You can give SA another restart at the end of the reboot cycle, edit /etc/rc.local and put "service spamassassin restart" (without quotes) just before exit 0 /MJ
Re: dns: sendto() to [127.0.0.1]:53 failed: Connection refused, no more alternatives
On Sat, 2014-11-01 at 06:41 -0400, Jason W. wrote: > On Fri, Oct 31, 2014 at 8:54 PM, Chris > wrote: > I am still fighting this issue. This has been going on since > Wednesday > morning since there was an update to the kernel. I have no > idea what to > check or even where to begin. If someone could help I'd really > appreciate it. > > > My guess would be your /etc/resolv.conf only has one nameserver listed > - 127.0.0.1 - and whatever resolver service you have running on your > server did not restart when you rebooted to update the kernel. > Hi Jason, actually my /etc/resolv.conf file has nameserver 127.0.1.1 as the only nameserver. I noticed this morning that the error is no longer there. The only thing I did last night was to restart SA although I know it has been running since the kernel update. Doing some back checking in my hourly syslog snippets I see that the last kernel update was on Oct 20th at 8pm. The error started immediately after that. My next SA update run was at 7:30 the next morning and SA was automatically restarted. The next message that came through did not have the error. The next kernel update was this past Wednesday which was installed just after SA update was run which due to rule updates restarted SA. Since then Thu and Fri there were no rule updates so SA was not automatically restarted. I guess to make a long story short for some reason I have to restart SA after a kernel update however I have no idea why and I'll have to test this theory after the next kernel update. Does any of the above make any sense? Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11°N 97.89°W (Elev. 1092 ft) 08:09:57 up 2 days, 13:06, 1 user, load average: 0.26, 0.20, 0.40 Ubuntu 14.04.1 LTS, kernel 3.13.0-39-generic
Re: dns: sendto() to [127.0.0.1]:53 failed: Connection refused, no more alternatives
On Fri, Oct 31, 2014 at 8:54 PM, Chris wrote: > I am still fighting this issue. This has been going on since Wednesday > morning since there was an update to the kernel. I have no idea what to > check or even where to begin. If someone could help I'd really > appreciate it. > My guess would be your /etc/resolv.conf only has one nameserver listed - 127.0.0.1 - and whatever resolver service you have running on your server did not restart when you rebooted to update the kernel. -- HTH, YMMV, HANW :) Jason The path to enlightenment is /usr/bin/enlightenment.
Re: SOUGHT 2.0 ?
On Thu, 30 Oct 2014 20:10:22 -, Bob Proulx wrote: Axb wrote: It would be nice to be able to use this experience to replace the SOUGHT rules for everyone BUT: ... All very good, reasonable and understandable reasons. And those reasons also aply to me too. Insert all of those reasons into why I didn't personally jump forward. Life has many annoying ways of getting in the way of some great ideas, and it's why an individual leaping forward has complications, however... Question is: Can we (the SA users) get a "project" together with enough members taking care of different tasks to ensure that the project doesn't die when one person decides to step out? Yes we can! I was disappointed to see that there wasn't a bunch of motivated people jumping in with both feet to maintain this. I totally understand everyone being in the same situation of never having enough time and resources to volunteer for something like this type of project. I am right there with you. I didn't want to see the option whither and die without voicing a positive cheer for it. Perhaps some more discussion would motivate more people to become involved. Well I think there are some legs to this too. I've been talking to Alex about some of the aspects and things I can do do to help. Like most of us I don't want to sign up for something that would be a monster resting purely on my shoulders, but having gone over a few bits and pieces it seems very manageable with just a bit of organisation and coordination. Which is why I've offered to throw my hat in the ring and do various bits to make this work. I really think that's the key aspect too, obviously we all share an interest and there's an overlap of skillsets too, which means once you start taking apart what's planned it becomes a lot less commitment for each of us. Alex auto generates rules for himself already, I have something I suspect is less sophisticated in place for my needs, we're seeing interest from other people already doing this kind of thing and those that aren't are pretty close in the various things we know they are doing. All in all it looks like it is close to being very viable. The big thing that should make this worth pursuing is the somewhat distributed nature of it all. I know in what we've discussed so far it's looking like we'll be able to avoid the single point of failure issue, and more importantly in terms of volunteering, the single point of pressure. Once set-up it's largely just a case of maintenance, and with people being involved we should be able to jump on a world cruise and be happy that we won't be woken somewhere near the Equator with a problem - there's redundancy forming already so I'll really emphasise that it won't be a huge burden on anyone. None of us already discussing this want that for ourselves and we don't want to push it on others either - we've got some experience of spreading the load across teams to make lives easier and it's basically a case of a little extra care and attention in planning should make the whole thing run smoothly. So anyone else want to raise their hands?
