Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Ian Zimmerman
On 2017-09-19 19:53, David B Funk wrote:

> So now you have -two- dnsmasq kits, one installed by "apt" and managed
> thru the "systemctl" tools, and another one that somebody put there
> which is outside the realm of "apt" & "systemctl" (thus they don't
> know how to manange it).
> 
> You should really pick one method of installing/managing software and
> stick with it.
> 
> This is similar to the mess you get when you mix CPAN with
> yum/yast/rpm/apt for installing Perl modules.

Similar but worse, as you can have a safe CPAN + distro mix with local::lib.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Bill Cole
On 19 Sep 2017, at 22:36, Chris wrote:

> On Wed, 2017-09-20 at 04:31 +0200, Reindl Harald wrote:
>>
>> Am 20.09.2017 um 02:32 schrieb Chris:
>>>
>>> I then installed dnsmasq (apparently it wasn't installed)
>> frankly clean up your mess - you recently posted dnsmasq as well as 
>> named listening on different interfaces for DNS, now you say dnsmasq
>> was 
>> not installed
>
> Will do, sorry for all the noise the last few days. I'll see if I can
> figure this out myself.

Everyone here started clueless and when we obtained a little knowledge, got 
dangerous: mostly to ourselves. No apologies needed.

You have clearly done something on your system that confuse the specific 
problem you're having with SpamAssassin. I suspect the root issue is installing 
dnsmasq from the upstream source distribution (and maybe BIND also?) rather 
than using the Debian/Ubuntu package(s) via the apt and/or dpkg tools. That's 
not an uncommon class of mistake, but it is an especially risky move on a 
systemd-managed platform and especially on anything Debian-based because Debian 
makes substantial changes to some open source software which can cause unusual 
problems which are unique to the platform. The bottom line: on Ubuntu, use the 
Ubuntu software installation tools and do not try to install anything from 
upstream source that has a Ubuntu package.



signature.asc
Description: OpenPGP digital signature


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Wed, 2017-09-20 at 04:31 +0200, Reindl Harald wrote:
> 
> Am 20.09.2017 um 02:32 schrieb Chris:
> > 
> > I then installed dnsmasq (apparently it wasn't installed)
> frankly clean up your mess - you recently posted dnsmasq as well as 
> named listening on different interfaces for DNS, now you say dnsmasq
> was 
> not installed

Will do, sorry for all the noise the last few days. I'll see if I can
figure this out myself.


-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
21:35:17 up 48 min, 1 user, load average: 0.58, 0.39, 0.38
Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic


signature.asc
Description: This is a digitally signed message part


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Bill Cole
On 19 Sep 2017, at 16:40, Chris wrote:

> Here's the output now of the dig +trace
> tcp0  0
> 127.0.0.1:530.0.0.0:*   LISTEN  -  
>  
> tcp0  0
> 127.0.1.1:530.0.0.0:*   LISTEN  -  
>  
> udp0  0
> 127.0.0.1:530.0.0.0:*   -  
>  
> udp0  0
> 192.168.122.1:530.0.0.0:*   -  
>  
> udp0  0
> 127.0.1.1:530.0.0.0:*   -  
>  
> udp0  0
> 0.0.0.0:53530.0.0.0:*   -  
>  
> udp0  0
> 0.0.0.0:53530.0.0.0:*   -  
>  
> udp6   0  0
> :::5353 :::*-  
>  
> udp6   0  0
> :::5353 :::*   

That's netstat output and without the 'p' option it's not very enlightening. 
Also, grepping for ":53 " instead of ":53" will avoid getting the mDNS (5353) 
listeners. Weird to see those on a non-Mac, but I guess avahi is harmless...

> I'm getting different outputs each time I run dig +trace

As you should, for any name in a zone with multiple authoritative nameservers.

[...]
> I've disable dnsmasq in my /etc/NetworkManager/NetworkManager.conf via
> #dns=dnsmasq
>
> However, when restarting the network I see:
> dnsmasq[2323]: reading /etc/resolv.conf
> dnsmasq[2323]: using nameserver 127.0.0.1#53
> dnsmasq[2323]: using nameserver 127.0.0.1#53 
>
> NetworkManager[24113]:   [1505852393.3238]   nameserver
> '192.168.0.1'
> NetworkManager[24113]:   [1505852393.3238]   nameserver
> '205.171.2.226'

If you insist on using NetworkMangler, "dns=none" is better.

Also, that's NOT how you disable dnsmasq. That just tells NetworkMangler how 
exactly to screw up resolv.conf. It is documented in the NetworkManager.conf 
man page...

Since this is a modern Ubuntu, dnsmasq is managed by systemd, so you need to do 
something like:

systemctl stop dnsmasq
systemctl disable dnsmasq

And probably:

apt-get purge dnsmasq

> Unfortunately so far today since I've started trying to work this out
> there have been no queries to isipp by SA. I'll have to see what
> happens when there is one.
>
> I think David I may just be confusing myself more, at least the network
> is still up.

Then I guess a recommendation to also remove BIND and just install Unbound (a 
less complex recursive resolver daemon) instead would be unwelcome...


signature.asc
Description: OpenPGP digital signature


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 19:32 -0500, Chris wrote:
> On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
> > 
> > On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
> > > 
> > > 
> > > 
> > > Thanks Martin, here's what I get, it appears to not be running.
> > > 
> > > sudo systemctl stop dnsmasq
> > > [sudo] password for chris: 
> > > Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
> > > 
> > OK, that makes sense
> >  
> > > 
> > > 
> > > sudo systemctl disable dnsmasq
> > > Failed to execute operation: No such file or directory
> > > 
> > That's interesting: I've never seen that before:
> > 
> > Here's what I see of I enable dnsmasq, check its status, disable it
> > and
> > check status again:
> > 
> > $ sudo systemctl enable dnsmasq
> > Created symlink /etc/systemd/system/multi-
> > user.target.wants/dnsmasq.service →
> > /usr/lib/systemd/system/dnsmasq.service.
> > 
> > $ sudo systemctl status dnsmasq
> > ● dnsmasq.service - DNS caching server.
> >    Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
> > enabled;
> > vendor preset: disabled)
> >    Active: inactive (dead)
> > 
> > $ sudo systemctl disable dnsmasq
> > Removed /etc/systemd/system/multi-
> > user.target.wants/dnsmasq.service.
> > 
> > $ sudo systemctl status dnsmasq
> > ● dnsmasq.service - DNS caching server.
> >    Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
> > disabled;
> > vendor preset: disabled)
> >    Active: inactive (dead)
> > 
> > This is a Fedora 25 system which I use, amongst other things, as my
> > SA
> > and test system. My live Postfix and SA are on another system which
> > runs named. I don't use dnsmasq at all but it turns out to be part
> > of
> > the standard software installed by F25.
> > 
> > It would be interesting to know what 'systemctl status' shows on
> > your
> > system, though its quite possible it looks similar to what
> > 'systemctl
> > disable' showed. I can only guess that your system is a
> > transitional
> > systemd setup, i.e. systemctl is used for service management but
> > some
> > services (dnsmasq for one) are still running under the old systemV
> > init
> > scripts. Fedora installations used to work that way for some
> > services,
> > but that was a few versions ago (F21 or 22 at the latest).
> > 
> > 
> > Martin
> >  
> Hi Martin, here's what I see:
> 
> sudo systemctl status dnsmasq
> [sudo] password for chris: 
> ● dnsmasq.service
>    Loaded: not-found (Reason: No such file or directory)
>    Active: inactive (dead)
> chris@localhost:~$ sudo systemctl enable dnsmasq
> Failed to execute operation: No such file or directory
> chris@localhost:~$ sudo systemctl status dnsmasq
> ● dnsmasq.service
>    Loaded: not-found (Reason: No such file or directory)
>    Active: inactive (dead)
> 
> I then installed dnsmasq (apparently it wasn't installed)
> 
> Results are here - https://pastebin.com/MRR4NCMp

After a restart - status now shows:

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor
preset: enabled)
  Drop-In: /run/systemd/generator/dnsmasq.service.d
   └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
   Active: active (running) since Tue 2017-09-19 19:56:46 CDT; 4min 11s
ago
  Process: 1215 ExecStartPost=/etc/init.d/dnsmasq systemd-start-
resolvconf (code=exited, status=0/SUCCESS)
  Process: 1040 ExecStart=/etc/init.d/dnsmasq systemd-exec
(code=exited, status=0/SUCCESS)
  Process: 963 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited,
status=0/SUCCESS)
 Main PID: 1214 (dnsmasq)
   CGroup: /system.slice/dnsmasq.service
   └─1214 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u
dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-
dist,.dpkg-old,.dpkg-new --local-service --trust-a

Sep 19 19:56:40 localhost dnsmasq[963]: dnsmasq: syntax check OK.
Sep 19 19:56:46 localhost dnsmasq[1214]: started, version 2.75
cachesize 150
Sep 19 19:56:46 localhost dnsmasq[1214]: compile time options: IPv6
GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
DNSSEC loop-detect inotify
Sep 19 19:56:46 localhost dnsmasq[1214]: no servers found in
/var/run/dnsmasq/resolv.conf, will retry
Sep 19 19:56:46 localhost dnsmasq[1214]: read /etc/hosts - 6 addresses
Sep 19 19:56:46 localhost systemd[1]: Started dnsmasq - A lightweight
DHCP and caching DNS server.
Sep 19 19:57:05 localhost dnsmasq[1214]: reading
/var/run/dnsmasq/resolv.conf
Sep 19 19:57:05 localhost dnsmasq[1214]: using nameserver
192.168.0.1#53
Sep 19 19:57:05 localhost dnsmasq[1214]: using nameserver
205.171.2.226#53
Sep 19 19:57:05 localhost dnsmasq[1214]: ignoring nameserver 127.0.0.1
- local interface


-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
20:01:58 up 6 min, 1 user, load average: 5.08, 5.51, 2.71
Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic


signature.asc
Description: This is a digitally signed message part


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread David B Funk

On Tue, 19 Sep 2017, Chris wrote:


On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:

On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:



Thanks Martin, here's what I get, it appears to not be running.

sudo systemctl stop dnsmasq
[sudo] password for chris: 
Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.


OK, that makes sense
 


sudo systemctl disable dnsmasq
Failed to execute operation: No such file or directory


That's interesting: I've never seen that before:



[snip..]


It would be interesting to know what 'systemctl status' shows on your
system, though its quite possible it looks similar to what 'systemctl
disable' showed. I can only guess that your system is a transitional
systemd setup, i.e. systemctl is used for service management but some
services (dnsmasq for one) are still running under the old systemV
init
scripts. Fedora installations used to work that way for some
services,
but that was a few versions ago (F21 or 22 at the latest).


Martin
 

Hi Martin, here's what I see:

sudo systemctl status dnsmasq
[sudo] password for chris: 
● dnsmasq.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
chris@localhost:~$ sudo systemctl enable dnsmasq
Failed to execute operation: No such file or directory
chris@localhost:~$ sudo systemctl status dnsmasq
● dnsmasq.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

I then installed dnsmasq (apparently it wasn't installed)

Results are here - https://pastebin.com/MRR4NCMp


dnsmasq was already there (see your own previous posts) just not put there via 
the "apt" package management system. Thus "apt" didn't know about the rogue 
dnsmasq process, and it failed to start the newly installed one.
(as the rogue dnsmasq process was already there, running, and bound to the DNS 
socket).


So now you have -two- dnsmasq kits, one installed by "apt" and managed thru the 
"systemctl" tools, and another one that somebody put there which is outside the 
realm of "apt" & "systemctl" (thus they don't know how to manange it).


You should really pick one method of installing/managing software and stick with 
it.


This is similar to the mess you get when you mix CPAN with yum/yast/rpm/apt for 
installing Perl modules.



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Wed, 2017-09-20 at 00:40 +0100, Martin Gregorie wrote:
> On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
> > 
> > 
> > Thanks Martin, here's what I get, it appears to not be running.
> > 
> > sudo systemctl stop dnsmasq
> > [sudo] password for chris: 
> > Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
> > 
> OK, that makes sense
>  
> > 
> > sudo systemctl disable dnsmasq
> > Failed to execute operation: No such file or directory
> > 
> That's interesting: I've never seen that before:
> 
> Here's what I see of I enable dnsmasq, check its status, disable it
> and
> check status again:
> 
> $ sudo systemctl enable dnsmasq
> Created symlink /etc/systemd/system/multi-
> user.target.wants/dnsmasq.service →
> /usr/lib/systemd/system/dnsmasq.service.
> 
> $ sudo systemctl status dnsmasq
> ● dnsmasq.service - DNS caching server.
>    Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled;
> vendor preset: disabled)
>    Active: inactive (dead)
> 
> $ sudo systemctl disable dnsmasq
> Removed /etc/systemd/system/multi-user.target.wants/dnsmasq.service.
> 
> $ sudo systemctl status dnsmasq
> ● dnsmasq.service - DNS caching server.
>    Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled;
> vendor preset: disabled)
>    Active: inactive (dead)
> 
> This is a Fedora 25 system which I use, amongst other things, as my
> SA
> and test system. My live Postfix and SA are on another system which
> runs named. I don't use dnsmasq at all but it turns out to be part of
> the standard software installed by F25.
> 
> It would be interesting to know what 'systemctl status' shows on your
> system, though its quite possible it looks similar to what 'systemctl
> disable' showed. I can only guess that your system is a transitional
> systemd setup, i.e. systemctl is used for service management but some
> services (dnsmasq for one) are still running under the old systemV
> init
> scripts. Fedora installations used to work that way for some
> services,
> but that was a few versions ago (F21 or 22 at the latest).
> 
> 
> Martin
>  
Hi Martin, here's what I see:

sudo systemctl status dnsmasq
[sudo] password for chris: 
● dnsmasq.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
chris@localhost:~$ sudo systemctl enable dnsmasq
Failed to execute operation: No such file or directory
chris@localhost:~$ sudo systemctl status dnsmasq
● dnsmasq.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

I then installed dnsmasq (apparently it wasn't installed)

Results are here - https://pastebin.com/MRR4NCMp

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
19:25:14 up 1 day, 3:04, 2 users, load average: 0.37, 0.26, 0.19
Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic


signature.asc
Description: This is a digitally signed message part


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Martin Gregorie
On Tue, 2017-09-19 at 16:44 -0500, Chris wrote:
> 
> Thanks Martin, here's what I get, it appears to not be running.
> 
> sudo systemctl stop dnsmasq
> [sudo] password for chris: 
> Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.
> 
OK, that makes sense
 
> sudo systemctl disable dnsmasq
> Failed to execute operation: No such file or directory
> 
That's interesting: I've never seen that before:

Here's what I see of I enable dnsmasq, check its status, disable it and
check status again:

$ sudo systemctl enable dnsmasq
Created symlink /etc/systemd/system/multi-
user.target.wants/dnsmasq.service →
/usr/lib/systemd/system/dnsmasq.service.

$ sudo systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled;
vendor preset: disabled)
   Active: inactive (dead)

$ sudo systemctl disable dnsmasq
Removed /etc/systemd/system/multi-user.target.wants/dnsmasq.service.

$ sudo systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
   Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled;
vendor preset: disabled)
   Active: inactive (dead)

This is a Fedora 25 system which I use, amongst other things, as my SA
and test system. My live Postfix and SA are on another system which
runs named. I don't use dnsmasq at all but it turns out to be part of
the standard software installed by F25.

It would be interesting to know what 'systemctl status' shows on your
system, though its quite possible it looks similar to what 'systemctl
disable' showed. I can only guess that your system is a transitional
systemd setup, i.e. systemctl is used for service management but some
services (dnsmasq for one) are still running under the old systemV init
scripts. Fedora installations used to work that way for some services,
but that was a few versions ago (F21 or 22 at the latest).


Martin
 


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:
> On Tue, 2017-09-19 at 08:41 -0500, David Jones wrote:
> > 
> > On 09/19/2017 08:25 AM, Chris wrote:
> > > 
> > > 
> > > On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> > > > 
> > > > 
> > > > On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 09/18/2017 06:03 PM, Chris wrote:
> > > > [snip]
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > localhost dnsmasq[2323]: started, version 2.75 cachesize
> > > > > > 150
> > > > > > localhost dnsmasq[2323]: compile time options: IPv6 GNU-
> > > > > > getopt
> > > > > > DBus
> > > > > > i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth
> > > > > > DNSSEC
> > > > > > loop-
> > > > > > detect inotify
> > > > > > localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2
> > > > > > --
> > > > > > 192.168.122.254, lease time 1h
> > > > > > localhost dnsmasq-dhcp[2323]: DHCP, sockets bound
> > > > > > exclusively
> > > > > > to
> > > > > > interface virbr0
> > > > > > localhost dnsmasq[2323]: reading /etc/resolv.conf
> > > > > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > > > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > > > > localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
> > > > > > localhost dnsmasq[2323]: read
> > > > > > /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
> > > > > > localhost dnsmasq-dhcp[2323]: read
> > > > > > /var/lib/libvirt/dnsmasq/default.hostsfile
> > > > > > 
> > > > > > I'm not really running a mail server in the true sense of
> > > > > > the
> > > > > > word
> > > > > > I
> > > > > > believe. Fetchmail queries my email accounts and pipes the
> > > > > > messages
> > > > > > through procmail. Anything that doesn't already have a
> > > > > > recipe
> > > > > > is
> > > > > > run
> > > > > > through SA. I'm just using Bind to speed up the queries
> > > > > > that
> > > > > > SA
> > > > > > makes.
> > > > > > I believe I'm stating that correctly but who knows could be
> > > > > > way
> > > > > > off.
> > > > > > 
> > > > > > If I can give any other information I'll be glad to do it.
> > > > > > Again,
> > > > > > I
> > > > > > have no idea why the queries are going to 168.150.251.35.
> > > > > > There
> > > > > > hasn't
> > > > > > been another query to isipp since a bit after noon. I'll
> > > > > > see
> > > > > > what
> > > > > > happens the next time there is one.
> > > > > > 
> > > > > Run 'netstat -tunlap | grep ":53 "' and see what is listening
> > > > > on
> > > > > port
> > > > > 53
> > > > > as your DNS server.  You probably need to remove/uninstall
> > > > > dnsmasq.
> > > > > 
> > > > > Here's my output:
> > > > > 
> > > > > # netstat -tunlap | grep ":53 "
> > > > > tcp0  0 127.0.0.1:530.0.0.0:*
> > > > >  LISTEN  24019/pdns_recursor
> > > > > udp0  0 127.0.0.1:530.0.0.0:*
> > > > >  24019/pdns_recursor
> > > > > 
> > > > > Once you know you are only running named on port 53, then
> > > > > make
> > > > > sure
> > > > > your
> > > > > named.conf doesn't have any forwarders defined in the options
> > > > > section.
> > > > > 
> > > > > Now check your logs and see if you are still getting a lot of
> > > > > refused
> > > > > responses.  BIND should be doing full recursive lookups
> > > > > directly to
> > > > > the
> > > > > authoritative DNS servers just like you saw with the "dig
> > > > > +trace"
> > > > > command.
> > > > > 
> > > > David, here's my output. I ran as sudo to see all inclusive:
> > > > 
> > > > sudo netstat -tunlap | grep ":53"
> > > > [sudo] password for chris:
> > > > tcp0  0
> > > > 192.168.122.1:530.0.0.0:*   LISTEN  124
> > > > 5/
> > > > name
> > > > d
> > > >   
> > > > tcp0  0
> > > > 127.0.1.1:530.0.0.0:*   LISTEN  131
> > > > 6/
> > > > dnsm
> > > > as
> > > > q
> > > > tcp0  0
> > > > 192.168.0.51:53 0.0.0.0:*   LISTEN  124
> > > > 5/
> > > > name
> > > > d
> > > >   
> > > > tcp0  0
> > > > 127.0.0.1:530.0.0.0:*   LISTEN  124
> > > > 5/
> > > > name
> > > > d
> > > >   
> > > > tcp0  0
> > > > 192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -
> > > >    
> > > >   
> > > > tcp1  1
> > > > 192.168.0.51:33475  198.97.190.53:53CLOSING -
> > > >    
> > > >   
> > > > tcp0  0
> > > > 192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -
> > > >    
> > > >   
> > > > tcp0  0
> > > > 192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -
> > > >    
> > > >   
> > > > tcp0  0
> > > > 192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -
> > > >    
> > > >   
> > > > tcp0  0
> > > > 192.168.0.51:36143  199.19.56.1:53  

Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 14:47 -0700, John Hardin wrote:
> On Tue, 19 Sep 2017, Chris wrote:
> 
> > I'm getting different outputs each time I run dig +trace
> > 65.43.116.208.iadb.isipp.com
> >
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.1.255
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.0.2
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.3
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.101.202.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.0.1
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.1
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.4
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.101.201.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.3.100.10 
> > ;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in
> 67
> > ms
> >
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.0.2
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.3.100.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.4
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.0.1
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.101.202.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.1
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.2.255.3
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.101.201.10
> > 65.43.116.208.iadb.isipp.com. 3600 IN A   127.0.1.255
> 
> That just looks like sorting.
>   Today: Talk Like a Pirate day

Aargh, I guess that makes sense

Thanks

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
17:08:56 up 1 day, 48 min, 1 user, load average: 1.37, 1.07, 0.84
Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic


signature.asc
Description: This is a digitally signed message part


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread John Hardin

On Tue, 19 Sep 2017, Chris wrote:


I'm getting different outputs each time I run dig +trace
65.43.116.208.iadb.isipp.com

65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.1.255
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.2
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.3
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.202.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.4
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.201.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.3.100.10 
;; Received 201 bytes from 147.75.64.146#53(c.auth-ns.sonic.net) in 67
ms

65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.2
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.3.100.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.4
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.202.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.3
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.201.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.1.255


That just looks like sorting.

--
 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
---
  Programming is an art form that fights back.  -- Kevin S. Gallagher
---
 Today: Talk Like a Pirate day

Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 22:07 +0100, Martin Gregorie wrote:
> On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > I've disable dnsmasq in my
> > > > > > > /etc/NetworkManager/NetworkManager.conf
> > via
> > #dns=dnsmasq
> > 
> > However, when restarting the network I see:
> > dnsmasq[2323]: reading /etc/resolv.conf
> > dnsmasq[2323]: using nameserver 127.0.0.1#53
> > dnsmasq[2323]: using nameserver 127.0.0.1#53 
> > 
> > NetworkManager[24113]:   [1505852393.3238]   nameserver
> > '192.168.0.1'
> > NetworkManager[24113]:   [1505852393.3238]   nameserver
> > '205.171.2.226'
> > 
> If you want dnsmasq dead and assuming you're using systemd, do this:
> 
> sudo systemctl stop dnsmasq
> sudo systemctl disable dnsmasq
> 
> ...then it won't be restarted under any circumstances including a
> reboot.
> 
> If you're still on the old sysVinit system, do its equivalent so that
> dnsmasq isn't started at any runlevel.   
> 
> 
> Martin
> 
Thanks Martin, here's what I get, it appears to not be running.

sudo systemctl stop dnsmasq
[sudo] password for chris: 
Failed to stop dnsmasq.service: Unit dnsmasq.service not loaded.

sudo systemctl disable dnsmasq
Failed to execute operation: No such file or directory

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
16:33:34 up 1 day, 12 min, 1 user, load average: 0.28, 0.46, 0.76
Description:Ubuntu 16.04.3 LTS, kernel 4.10.0-35-generic


signature.asc
Description: This is a digitally signed message part


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Martin Gregorie
On Tue, 2017-09-19 at 15:40 -0500, Chris wrote:

> > > > > > I've disable dnsmasq in my
> > > > > > /etc/NetworkManager/NetworkManager.conf
> via
> #dns=dnsmasq
> 
> However, when restarting the network I see:
> dnsmasq[2323]: reading /etc/resolv.conf
> dnsmasq[2323]: using nameserver 127.0.0.1#53
> dnsmasq[2323]: using nameserver 127.0.0.1#53 
> 
> NetworkManager[24113]:   [1505852393.3238]   nameserver
> '192.168.0.1'
> NetworkManager[24113]:   [1505852393.3238]   nameserver
> '205.171.2.226'
> 
If you want dnsmasq dead and assuming you're using systemd, do this:

sudo systemctl stop dnsmasq
sudo systemctl disable dnsmasq

...then it won't be restarted under any circumstances including a
reboot.

If you're still on the old sysVinit system, do its equivalent so that
dnsmasq isn't started at any runlevel.   


Martin



Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 08:41 -0500, David Jones wrote:
> On 09/19/2017 08:25 AM, Chris wrote:
> > 
> > On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> > > 
> > > On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> > > > 
> > > > 
> > > > On 09/18/2017 06:03 PM, Chris wrote:
> > > [snip]
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > localhost dnsmasq[2323]: started, version 2.75 cachesize 150
> > > > > localhost dnsmasq[2323]: compile time options: IPv6 GNU-
> > > > > getopt
> > > > > DBus
> > > > > i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> > > > > loop-
> > > > > detect inotify
> > > > > localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
> > > > > 192.168.122.254, lease time 1h
> > > > > localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively
> > > > > to
> > > > > interface virbr0
> > > > > localhost dnsmasq[2323]: reading /etc/resolv.conf
> > > > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > > > localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
> > > > > localhost dnsmasq[2323]: read
> > > > > /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
> > > > > localhost dnsmasq-dhcp[2323]: read
> > > > > /var/lib/libvirt/dnsmasq/default.hostsfile
> > > > > 
> > > > > I'm not really running a mail server in the true sense of the
> > > > > word
> > > > > I
> > > > > believe. Fetchmail queries my email accounts and pipes the
> > > > > messages
> > > > > through procmail. Anything that doesn't already have a recipe
> > > > > is
> > > > > run
> > > > > through SA. I'm just using Bind to speed up the queries that
> > > > > SA
> > > > > makes.
> > > > > I believe I'm stating that correctly but who knows could be
> > > > > way
> > > > > off.
> > > > > 
> > > > > If I can give any other information I'll be glad to do it.
> > > > > Again,
> > > > > I
> > > > > have no idea why the queries are going to 168.150.251.35.
> > > > > There
> > > > > hasn't
> > > > > been another query to isipp since a bit after noon. I'll see
> > > > > what
> > > > > happens the next time there is one.
> > > > > 
> > > > Run 'netstat -tunlap | grep ":53 "' and see what is listening
> > > > on
> > > > port
> > > > 53
> > > > as your DNS server.  You probably need to remove/uninstall
> > > > dnsmasq.
> > > > 
> > > > Here's my output:
> > > > 
> > > > # netstat -tunlap | grep ":53 "
> > > > tcp0  0 127.0.0.1:530.0.0.0:*
> > > >  LISTEN  24019/pdns_recursor
> > > > udp0  0 127.0.0.1:530.0.0.0:*
> > > >  24019/pdns_recursor
> > > > 
> > > > Once you know you are only running named on port 53, then make
> > > > sure
> > > > your
> > > > named.conf doesn't have any forwarders defined in the options
> > > > section.
> > > > 
> > > > Now check your logs and see if you are still getting a lot of
> > > > refused
> > > > responses.  BIND should be doing full recursive lookups
> > > > directly to
> > > > the
> > > > authoritative DNS servers just like you saw with the "dig
> > > > +trace"
> > > > command.
> > > > 
> > > David, here's my output. I ran as sudo to see all inclusive:
> > > 
> > > sudo netstat -tunlap | grep ":53"
> > > [sudo] password for chris:
> > > tcp0  0
> > > 192.168.122.1:530.0.0.0:*   LISTEN  1245/
> > > name
> > > d
> > >   
> > > tcp0  0
> > > 127.0.1.1:530.0.0.0:*   LISTEN  1316/
> > > dnsm
> > > as
> > > q
> > > tcp0  0
> > > 192.168.0.51:53 0.0.0.0:*   LISTEN  1245/
> > > name
> > > d
> > >   
> > > tcp0  0
> > > 127.0.0.1:530.0.0.0:*   LISTEN  1245/
> > > name
> > > d
> > >   
> > > tcp0  0
> > > 192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -
> > >    
> > >   
> > > tcp1  1
> > > 192.168.0.51:33475  198.97.190.53:53CLOSING -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:36143  199.19.56.1:53  TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:47629  199.7.83.42:53  TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:58201  192.48.79.30:53 TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:53145  199.19.56.1:53  TIME_WAIT   -
> > >    
> > >   
> > > tcp0  0
> > > 192.168.0.51:55073  199.7.83.42:53  TIME_WAIT   -
> > >    
> > >   
> > > tcp

Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 10:06:58 -0500
David Jones wrote:

>  header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/  
> >>>
> >>> The OP said there was a space after 'Subject:', so that rule
> >>> wouldn't detect it.

> My point was supposed to  be a single space should hit
> MISSING_SUBJECT and two or more would not.

but  neither 'Subject: \n' nor 'Subject:\n' triggers
MISSING_SUBJECT.

There probably is some scope for something like 

header EMPTY_SUBJECT  ALL =~ /^Subject:\s?$/mi

it might be more useful in meta rules e.g. combined with DCC. 


Re: OT - Hotmail/Outlook.com marking most of our email as Junk

2017-09-19 Thread Jerry Malcolm
My recommendation as a first step is to go to mail-tester.com. They will 
tell you to send an email to a temp email address, and they will analyze 
and grade your email as to 'spamy-ness'. Outlook, gmail, etc were 
flagging a lot of my emails.  After I finally fixed everything and got 
mail-tester.com to give me a perfect score, I haven't had any problem 
with getting flagged.


Jerry


On 9/19/2017 1:44 AM, G Roach wrote:
Microsoft use their own methods of detection including based on 
reputation and 'length of service' - ie, if you have only just started 
sending emails out from your own address (which you have) then they 
may well consider you suspicious. Theres not much yo can do about it. 
  More info here: https://mail.live.com/mail/troubleshooting.aspx




On 19/09/2017 07:25, Sebastian Arcus wrote:
This is a bit off topic as it is not directly related to SA, but I'm 
hoping that with the email and spam expertise on this group, someone 
might throw in a useful idea - which would be much appreciated.


I have this problem on one site where most emails we send to 
Hotmail/Outlook.com/Live.com email addresses end up in Junk at the 
recipient's end. Things I have tried:


1. I've setup SPF, DKIM, DMARC (and set it to 'reject').

2. We used to smart relay outbound email through the hosting provider 
(1and1), but now changed to send directly from our own IP address, so 
that we can control the reputation of the sending IP - no change.


3. I've checked our public IP and the domain name at mxtoolbox.com - 
all tests pass (the public IP has been delisted from the Spamhaus 
non-MX/end-user IP database).


4. I've setup forward and reverse DNS entries for our IP address.

5. I've checked with all DNS blocklists/blacklists I could find - our 
domain or IP address is not flagged up anywhere.


6. This is a small network which I've been managing for years - the 
domain name has not been used to send marketing/lists email of any 
sort - so the historic reputation should be fine.


7. I've setup a monitor and block on port 25 outbound on the network 
firewall - in case there is a trojan on a machine on the network 
sending out spam and ruining the reputation of our IP - it's never 
been triggered.


8. I've checked the contents of outgoing emails - this is an 
accountants practice - the email content is standard, there is 
nothing there which should trigger bayesian filters.


9. I've sent emails to other servers under my control running SA - 
the scores come out perfect at the receiving end.


10. The emails we send are operational and notices emails to 
customers - who need them. They call on the phone and complain they 
haven't received them - just to discover they were sent, but ended up 
in the junk.


11. Emails we send to any other domains are never a problem spam-wise.

I can't really think of anything else to try - have I missed 
anything? Are Hotmail/Outlook.com spam filters a complete lottery?






Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread David Jones

On 09/19/2017 09:35 AM, RW wrote:

On Tue, 19 Sep 2017 10:05:44 -0400
Kevin A. McGrail wrote:


On 9/19/2017 9:11 AM, David Jones wrote:

I have had these in place for years.  Maybe Kevin can consolidate
and integrate this into his KAM.cf so I could remove them or we
could eventually get them into the default SA ruleset after some
testing.


Hi David,

Thanks.  In addition to KAM.cf, I maintain a nonKAMrules.cf which
I've added these attributing them with the idea to test.  It's where
I throw rules in the PD from lists and things like that so I'm not
claiming ownership but like the ideas.

Note, I lowered the score on the 1st two.  I'm pretty sure those
might cause more FPs than intended.

https://www.pccc.com/downloads/SpamAssassin/contrib/nonKAMrules.cf



The second should be changed to something like


/^\s\s+$/

or

   /^\s{2,999}$/


The comment is a bit misleading

   "Subject is empty or only spaces commonly used by spammers to get
around subject checks"

since it doesn't check for an empty subject.



The word "empty" in the description was for the mail client showing what 
seemed to be a blank or empty subject when it technically wasn't.  These 
descriptions are shown to our Help Desk which will be less technical 
than we are on this list.


Please feel free to update/change anything to make it better or to 
follow common conventions.  I admit I was doing poor regex years ago and 
have gotten better the past year.


--
David Jones


Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread David Jones

On 09/19/2017 09:03 AM, RW wrote:

On Tue, 19 Sep 2017 08:32:12 -0500
David Jones wrote:


On 09/19/2017 08:20 AM, RW wrote:

On Tue, 19 Sep 2017 08:11:03 -0500
David Jones wrote:



header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/


The OP said there was a space after 'Subject:', so that rule
wouldn't detect it.
   


Mail headers always have a space after the colon which should not be
considered part of the header's value.


Obviously, but what I wrote is still true.


I didn't mean to sound like a jerk there.  My point was supposed to be a 
single space should hit MISSING_SUBJECT and two or more would not.





That ENA rule above would be
two spaces after the header's colon.  All of those rules I sent last
post detect something a little different and combined they cover most
of the tricks I have seen to get around the MISSING_SUBJECT rule.


I know what they do, I actually wrote the last two.



Thank you for those rules.  I probably did get them from you on this 
list a long time ago.



By the way, anything that hits ENA_SUBJ_IS_SPACE will also hit
ENA_SUBJ_ONLY_SPACES giving 5.4 points.



I noticed this too after posting but I have gone back to my reports.  I 
am seeing many hits today on ENA_SUBJ_ONLY_SPACES but no hits on 
ENA_SUBJ_IS_SPACE.  I should and will remove ENA_SUBJ_IS_SPACE.


--
David Jones


Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 10:05:44 -0400
Kevin A. McGrail wrote:

> On 9/19/2017 9:11 AM, David Jones wrote:
> > I have had these in place for years.  Maybe Kevin can consolidate
> > and integrate this into his KAM.cf so I could remove them or we
> > could eventually get them into the default SA ruleset after some
> > testing.   
> 
> Hi David,
> 
> Thanks.  In addition to KAM.cf, I maintain a nonKAMrules.cf which
> I've added these attributing them with the idea to test.  It's where
> I throw rules in the PD from lists and things like that so I'm not
> claiming ownership but like the ideas.
> 
> Note, I lowered the score on the 1st two.  I'm pretty sure those
> might cause more FPs than intended.
> 
> https://www.pccc.com/downloads/SpamAssassin/contrib/nonKAMrules.cf


The second should be changed to something like 


   /^\s\s+$/

or 

  /^\s{2,999}$/


The comment is a bit misleading

  "Subject is empty or only spaces commonly used by spammers to get
   around subject checks"

since it doesn't check for an empty subject.


Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread Kevin A. McGrail

On 9/19/2017 9:11 AM, David Jones wrote:
I have had these in place for years.  Maybe Kevin can consolidate and 
integrate this into his KAM.cf so I could remove them or we could 
eventually get them into the default SA ruleset after some testing. 


Hi David,

Thanks.  In addition to KAM.cf, I maintain a nonKAMrules.cf which I've 
added these attributing them with the idea to test.  It's where I throw 
rules in the PD from lists and things like that so I'm not claiming 
ownership but like the ideas.


Note, I lowered the score on the 1st two.  I'm pretty sure those might 
cause more FPs than intended.


https://www.pccc.com/downloads/SpamAssassin/contrib/nonKAMrules.cf


Regards,
KAM



Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 08:32:12 -0500
David Jones wrote:

> On 09/19/2017 08:20 AM, RW wrote:
> > On Tue, 19 Sep 2017 08:11:03 -0500
> > David Jones wrote:

> >> header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/  
> > 
> > The OP said there was a space after 'Subject:', so that rule
> > wouldn't detect it.
> >   
> 
> Mail headers always have a space after the colon which should not be 
> considered part of the header's value.  

Obviously, but what I wrote is still true.

> That ENA rule above would be
> two spaces after the header's colon.  All of those rules I sent last
> post detect something a little different and combined they cover most
> of the tricks I have seen to get around the MISSING_SUBJECT rule.

I know what they do, I actually wrote the last two.

By the way, anything that hits ENA_SUBJ_IS_SPACE will also hit
ENA_SUBJ_ONLY_SPACES giving 5.4 points.


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread David Jones

On 09/19/2017 08:25 AM, Chris wrote:

On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:

On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:


On 09/18/2017 06:03 PM, Chris wrote:

[snip]





localhost dnsmasq[2323]: started, version 2.75 cachesize 150
localhost dnsmasq[2323]: compile time options: IPv6 GNU-getopt
DBus
i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
loop-
detect inotify
localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
192.168.122.254, lease time 1h
localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively to
interface virbr0
localhost dnsmasq[2323]: reading /etc/resolv.conf
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
localhost dnsmasq[2323]: read
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
localhost dnsmasq-dhcp[2323]: read
/var/lib/libvirt/dnsmasq/default.hostsfile

I'm not really running a mail server in the true sense of the
word
I
believe. Fetchmail queries my email accounts and pipes the
messages
through procmail. Anything that doesn't already have a recipe is
run
through SA. I'm just using Bind to speed up the queries that SA
makes.
I believe I'm stating that correctly but who knows could be way
off.

If I can give any other information I'll be glad to do it. Again,
I
have no idea why the queries are going to 168.150.251.35. There
hasn't
been another query to isipp since a bit after noon. I'll see what
happens the next time there is one.


Run 'netstat -tunlap | grep ":53 "' and see what is listening on
port
53
as your DNS server.  You probably need to remove/uninstall dnsmasq.

Here's my output:

# netstat -tunlap | grep ":53 "
tcp0  0 127.0.0.1:530.0.0.0:*
 LISTEN  24019/pdns_recursor
udp0  0 127.0.0.1:530.0.0.0:*
 24019/pdns_recursor

Once you know you are only running named on port 53, then make sure
your
named.conf doesn't have any forwarders defined in the options
section.

Now check your logs and see if you are still getting a lot of
refused
responses.  BIND should be doing full recursive lookups directly to
the
authoritative DNS servers just like you saw with the "dig +trace"
command.


David, here's my output. I ran as sudo to see all inclusive:

sudo netstat -tunlap | grep ":53"
[sudo] password for chris:
tcp0  0
192.168.122.1:530.0.0.0:*   LISTEN  1245/name
d
  
tcp0  0

127.0.1.1:530.0.0.0:*   LISTEN  1316/dnsm
as
q
tcp0  0
192.168.0.51:53 0.0.0.0:*   LISTEN  1245/name
d
  
tcp0  0

127.0.0.1:530.0.0.0:*   LISTEN  1245/name
d
  
tcp0  0

192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -
   
  
tcp1  1

192.168.0.51:33475  198.97.190.53:53CLOSING -
   
  
tcp0  0

192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:36143  199.19.56.1:53  TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:47629  199.7.83.42:53  TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:58201  192.48.79.30:53 TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:53145  199.19.56.1:53  TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:55073  199.7.83.42:53  TIME_WAIT   -
   
  
tcp0  0

192.168.0.51:41719  192.48.79.30:53 TIME_WAIT   -
   
  
tcp1  1

192.168.0.51:40633  198.97.190.53:53CLOSING -
   
  
udp0  0

192.168.122.1:530.0.0.0:*   2323/dnsm
as
q
udp0  0
192.168.122.1:530.0.0.0:*   1245/name
d
  
udp0  0

127.0.1.1:530.0.0.0:*   1316/dnsm
as
q
udp0  0
192.168.0.51:53 0.0.0.0:*   1245/name
d
  
udp0  0

127.0.0.1:530.0.0.0:*   1245/name
d
  
udp0  0

0.0.0.0:53530.0.0.0:*   1533/snap
we
b
udp0  0
0.0.0.0:53530.0.0.0:*   1004/avah
i-
daemon:
udp6   0  0
:::5353 :::*1533/snap
we
b
udp6   0  0
:::5353 :::*1004/avah
i-
daemon:



I neglected to insert my /etc/bind/named.conf.options file

acl goodclients {
 127.0.0.1;
 localhost;
 localnets;
};

options {
directory 

Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread David Jones

On 09/19/2017 08:20 AM, RW wrote:

On Tue, 19 Sep 2017 08:11:03 -0500
David Jones wrote:


On 09/19/2017 07:23 AM, Kevin A. McGrail wrote:

Is it purposeful extra space though that might indicate spaminess?
Spample? Regards,
KAM

On September 19, 2017 8:13:09 AM EDT, RW
 wrote:

 On Tue, 19 Sep 2017 09:27:13 +0100
 Sebastian Arcus wrote:

 I've had a number of emails with no subject not triggering
the MISSING_SUBJECT rule - only to discover that the spammers have
added a white space after 'Subject:' - which appears to fool the
code into
 thinking that there is an actual subject. Would it be
possible to 'smarten up' the code a bit to recognise this?


 The space doesn't make a difference.

 The test is for a missing subject not an empty subject. Some
people send emails without setting a subject but the client will
normally still add the header.
   


I have had these in place for years.  Maybe Kevin can consolidate and
integrate this into his KAM.cf so I could remove them or we could
eventually get them into the default SA ruleset after some testing.

header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/


The OP said there was a space after 'Subject:', so that rule wouldn't
detect it.



Mail headers always have a space after the colon which should not be 
considered part of the header's value.  That ENA rule above would be two 
spaces after the header's colon.  All of those rules I sent last post 
detect something a little different and combined they cover most of the 
tricks I have seen to get around the MISSING_SUBJECT rule.


--
David Jones


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread David Jones

On 09/19/2017 08:16 AM, Chris wrote:

On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:

On 09/18/2017 06:03 PM, Chris wrote:

[snip]


localhost dnsmasq[2323]: started, version 2.75 cachesize 150
localhost dnsmasq[2323]: compile time options: IPv6 GNU-getopt DBus
i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-
detect inotify
localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
192.168.122.254, lease time 1h
localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively to
interface virbr0
localhost dnsmasq[2323]: reading /etc/resolv.conf
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
localhost dnsmasq[2323]: read
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
localhost dnsmasq-dhcp[2323]: read
/var/lib/libvirt/dnsmasq/default.hostsfile

I'm not really running a mail server in the true sense of the word
I
believe. Fetchmail queries my email accounts and pipes the messages
through procmail. Anything that doesn't already have a recipe is
run
through SA. I'm just using Bind to speed up the queries that SA
makes.
I believe I'm stating that correctly but who knows could be way
off.

If I can give any other information I'll be glad to do it. Again, I
have no idea why the queries are going to 168.150.251.35. There
hasn't
been another query to isipp since a bit after noon. I'll see what
happens the next time there is one.


Run 'netstat -tunlap | grep ":53 "' and see what is listening on port
53
as your DNS server.  You probably need to remove/uninstall dnsmasq.

Here's my output:

# netstat -tunlap | grep ":53 "
tcp0  0 127.0.0.1:530.0.0.0:*
 LISTEN  24019/pdns_recursor
udp0  0 127.0.0.1:530.0.0.0:*
 24019/pdns_recursor

Once you know you are only running named on port 53, then make sure
your
named.conf doesn't have any forwarders defined in the options
section.

Now check your logs and see if you are still getting a lot of
refused
responses.  BIND should be doing full recursive lookups directly to
the
authoritative DNS servers just like you saw with the "dig +trace"
command.


David, here's my output. I ran as sudo to see all inclusive:

sudo netstat -tunlap | grep ":53"
[sudo] password for chris:
tcp0  0
192.168.122.1:530.0.0.0:*   LISTEN  1245/named
  
tcp0  0

127.0.1.1:530.0.0.0:*   LISTEN  1316/dnsmas
q
tcp0  0
192.168.0.51:53 0.0.0.0:*   LISTEN  1245/named
  
tcp0  0

127.0.0.1:530.0.0.0:*   LISTEN  1245/named
  
tcp0  0

192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -
  
tcp1  1

192.168.0.51:33475  198.97.190.53:53CLOSING -
  
tcp0  0

192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -
  
tcp0  0

192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -
  
tcp0  0

192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -
  
tcp0  0

192.168.0.51:36143  199.19.56.1:53  TIME_WAIT   -
  
tcp0  0

192.168.0.51:47629  199.7.83.42:53  TIME_WAIT   -
  
tcp0  0

192.168.0.51:58201  192.48.79.30:53 TIME_WAIT   -
  
tcp0  0

192.168.0.51:53145  199.19.56.1:53  TIME_WAIT   -
  
tcp0  0

192.168.0.51:55073  199.7.83.42:53  TIME_WAIT   -
  
tcp0  0

192.168.0.51:41719  192.48.79.30:53 TIME_WAIT   -
  
tcp1  1

192.168.0.51:40633  198.97.190.53:53CLOSING -
  
udp0  0

192.168.122.1:530.0.0.0:*   2323/dnsmas
q
udp0  0
192.168.122.1:530.0.0.0:*   1245/named
  
udp0  0

127.0.1.1:530.0.0.0:*   1316/dnsmas
q
udp0  0
192.168.0.51:53 0.0.0.0:*   1245/named
  
udp0  0

127.0.0.1:530.0.0.0:*   1245/named
  
udp0  0

0.0.0.0:53530.0.0.0:*   1533/snapwe
b
udp0  0
0.0.0.0:53530.0.0.0:*   1004/avahi-
daemon:
udp6   0  0
:::5353 :::*1533/snapwe
b
udp6   0  0
:::5353 :::*1004/avahi-
daemon:

Chris



Wow.  I don't think I have ever seen anything listening on 127.0.1.1 
before.  I would uninstall dnsmasq and make sure named is only listening 
on 127.0.0.1 just to make sure that nothing else outside of your box 
would try to use it.  A mail server should not have any 

Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 08:16 -0500, Chris wrote:
> On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> > 
> > On 09/18/2017 06:03 PM, Chris wrote:
> [snip]
> > 
> > > 
> > > 
> > > localhost dnsmasq[2323]: started, version 2.75 cachesize 150
> > > localhost dnsmasq[2323]: compile time options: IPv6 GNU-getopt
> > > DBus
> > > i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> > > loop-
> > > detect inotify
> > > localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
> > > 192.168.122.254, lease time 1h
> > > localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively to
> > > interface virbr0
> > > localhost dnsmasq[2323]: reading /etc/resolv.conf
> > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > > localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
> > > localhost dnsmasq[2323]: read
> > > /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
> > > localhost dnsmasq-dhcp[2323]: read
> > > /var/lib/libvirt/dnsmasq/default.hostsfile
> > > 
> > > I'm not really running a mail server in the true sense of the
> > > word
> > > I
> > > believe. Fetchmail queries my email accounts and pipes the
> > > messages
> > > through procmail. Anything that doesn't already have a recipe is
> > > run
> > > through SA. I'm just using Bind to speed up the queries that SA
> > > makes.
> > > I believe I'm stating that correctly but who knows could be way
> > > off.
> > > 
> > > If I can give any other information I'll be glad to do it. Again,
> > > I
> > > have no idea why the queries are going to 168.150.251.35. There
> > > hasn't
> > > been another query to isipp since a bit after noon. I'll see what
> > > happens the next time there is one.
> > > 
> > Run 'netstat -tunlap | grep ":53 "' and see what is listening on
> > port
> > 53 
> > as your DNS server.  You probably need to remove/uninstall dnsmasq.
> > 
> > Here's my output:
> > 
> > # netstat -tunlap | grep ":53 "
> > tcp0  0 127.0.0.1:530.0.0.0:* 
> > LISTEN  24019/pdns_recursor
> > udp0  0 127.0.0.1:530.0.0.0:* 
> > 24019/pdns_recursor
> > 
> > Once you know you are only running named on port 53, then make sure
> > your 
> > named.conf doesn't have any forwarders defined in the options
> > section.
> > 
> > Now check your logs and see if you are still getting a lot of
> > refused 
> > responses.  BIND should be doing full recursive lookups directly to
> > the 
> > authoritative DNS servers just like you saw with the "dig +trace"
> > command.
> > 
> David, here's my output. I ran as sudo to see all inclusive:
> 
> sudo netstat -tunlap | grep ":53"
> [sudo] password for chris: 
> tcp0  0
> 192.168.122.1:530.0.0.0:*   LISTEN  1245/name
> d 
>  
> tcp0  0
> 127.0.1.1:530.0.0.0:*   LISTEN  1316/dnsm
> as
> q
> tcp0  0
> 192.168.0.51:53 0.0.0.0:*   LISTEN  1245/name
> d 
>  
> tcp0  0
> 127.0.0.1:530.0.0.0:*   LISTEN  1245/name
> d 
>  
> tcp0  0
> 192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -
>   
>  
> tcp1  1
> 192.168.0.51:33475  198.97.190.53:53CLOSING -
>   
>  
> tcp0  0
> 192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:36143  199.19.56.1:53  TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:47629  199.7.83.42:53  TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:58201  192.48.79.30:53 TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:53145  199.19.56.1:53  TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:55073  199.7.83.42:53  TIME_WAIT   -
>   
>  
> tcp0  0
> 192.168.0.51:41719  192.48.79.30:53 TIME_WAIT   -
>   
>  
> tcp1  1
> 192.168.0.51:40633  198.97.190.53:53CLOSING -
>   
>  
> udp0  0
> 192.168.122.1:530.0.0.0:*   2323/dnsm
> as
> q
> udp0  0
> 192.168.122.1:530.0.0.0:*   1245/name
> d 
>  
> udp0  0
> 127.0.1.1:530.0.0.0:*   1316/dnsm
> as
> q
> udp0  0
> 192.168.0.51:53 0.0.0.0:*   1245/name
> d 
>  
> udp0  0
> 127.0.0.1:530.0.0.0:*   1245/name
> d 
>  
> udp  

Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 08:11:03 -0500
David Jones wrote:

> On 09/19/2017 07:23 AM, Kevin A. McGrail wrote:
> > Is it purposeful extra space though that might indicate spaminess?
> > Spample? Regards,
> > KAM
> > 
> > On September 19, 2017 8:13:09 AM EDT, RW
> >  wrote:
> > 
> > On Tue, 19 Sep 2017 09:27:13 +0100
> > Sebastian Arcus wrote:
> > 
> > I've had a number of emails with no subject not triggering
> > the MISSING_SUBJECT rule - only to discover that the spammers have
> > added a white space after 'Subject:' - which appears to fool the
> > code into
> > thinking that there is an actual subject. Would it be
> > possible to 'smarten up' the code a bit to recognise this?
> > 
> > 
> > The space doesn't make a difference.
> > 
> > The test is for a missing subject not an empty subject. Some
> > people send emails without setting a subject but the client will
> > normally still add the header.
> >   
> 
> I have had these in place for years.  Maybe Kevin can consolidate and 
> integrate this into his KAM.cf so I could remove them or we could 
> eventually get them into the default SA ruleset after some testing.
> 
> header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/

The OP said there was a space after 'Subject:', so that rule wouldn't
detect it.


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread Chris
On Tue, 2017-09-19 at 07:45 -0500, David Jones wrote:
> On 09/18/2017 06:03 PM, Chris wrote:
[snip]
> > 
> > localhost dnsmasq[2323]: started, version 2.75 cachesize 150
> > localhost dnsmasq[2323]: compile time options: IPv6 GNU-getopt DBus
> > i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-
> > detect inotify
> > localhost dnsmasq-dhcp[2323]: DHCP, IP range 192.168.122.2 --
> > 192.168.122.254, lease time 1h
> > localhost dnsmasq-dhcp[2323]: DHCP, sockets bound exclusively to
> > interface virbr0
> > localhost dnsmasq[2323]: reading /etc/resolv.conf
> > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > localhost dnsmasq[2323]: using nameserver 127.0.0.1#53
> > localhost dnsmasq[2323]: read /etc/hosts - 7 addresses
> > localhost dnsmasq[2323]: read
> > /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
> > localhost dnsmasq-dhcp[2323]: read
> > /var/lib/libvirt/dnsmasq/default.hostsfile
> > 
> > I'm not really running a mail server in the true sense of the word
> > I
> > believe. Fetchmail queries my email accounts and pipes the messages
> > through procmail. Anything that doesn't already have a recipe is
> > run
> > through SA. I'm just using Bind to speed up the queries that SA
> > makes.
> > I believe I'm stating that correctly but who knows could be way
> > off.
> > 
> > If I can give any other information I'll be glad to do it. Again, I
> > have no idea why the queries are going to 168.150.251.35. There
> > hasn't
> > been another query to isipp since a bit after noon. I'll see what
> > happens the next time there is one.
> > 
> Run 'netstat -tunlap | grep ":53 "' and see what is listening on port
> 53 
> as your DNS server.  You probably need to remove/uninstall dnsmasq.
> 
> Here's my output:
> 
> # netstat -tunlap | grep ":53 "
> tcp0  0 127.0.0.1:530.0.0.0:* 
> LISTEN  24019/pdns_recursor
> udp0  0 127.0.0.1:530.0.0.0:* 
> 24019/pdns_recursor
> 
> Once you know you are only running named on port 53, then make sure
> your 
> named.conf doesn't have any forwarders defined in the options
> section.
> 
> Now check your logs and see if you are still getting a lot of
> refused 
> responses.  BIND should be doing full recursive lookups directly to
> the 
> authoritative DNS servers just like you saw with the "dig +trace"
> command.
> 
David, here's my output. I ran as sudo to see all inclusive:

sudo netstat -tunlap | grep ":53"
[sudo] password for chris: 
tcp0  0
192.168.122.1:530.0.0.0:*   LISTEN  1245/named 
 
tcp0  0
127.0.1.1:530.0.0.0:*   LISTEN  1316/dnsmas
q
tcp0  0
192.168.0.51:53 0.0.0.0:*   LISTEN  1245/named 
 
tcp0  0
127.0.0.1:530.0.0.0:*   LISTEN  1245/named 
 
tcp0  0
192.168.0.51:56697  192.52.178.30:53TIME_WAIT   -  
 
tcp1  1
192.168.0.51:33475  198.97.190.53:53CLOSING -  
 
tcp0  0
192.168.0.51:52483  192.5.6.30:53   TIME_WAIT   -  
 
tcp0  0
192.168.0.51:57335  192.5.6.30:53   TIME_WAIT   -  
 
tcp0  0
192.168.0.51:56609  192.52.178.30:53TIME_WAIT   -  
 
tcp0  0
192.168.0.51:36143  199.19.56.1:53  TIME_WAIT   -  
 
tcp0  0
192.168.0.51:47629  199.7.83.42:53  TIME_WAIT   -  
 
tcp0  0
192.168.0.51:58201  192.48.79.30:53 TIME_WAIT   -  
 
tcp0  0
192.168.0.51:53145  199.19.56.1:53  TIME_WAIT   -  
 
tcp0  0
192.168.0.51:55073  199.7.83.42:53  TIME_WAIT   -  
 
tcp0  0
192.168.0.51:41719  192.48.79.30:53 TIME_WAIT   -  
 
tcp1  1
192.168.0.51:40633  198.97.190.53:53CLOSING -  
 
udp0  0
192.168.122.1:530.0.0.0:*   2323/dnsmas
q
udp0  0
192.168.122.1:530.0.0.0:*   1245/named 
 
udp0  0
127.0.1.1:530.0.0.0:*   1316/dnsmas
q
udp0  0
192.168.0.51:53 0.0.0.0:*   1245/named 
 
udp0  0
127.0.0.1:530.0.0.0:*   1245/named 
 
udp0  0
0.0.0.0:53530.0.0.0:*   1533/snapwe
b
udp0  0
0.0.0.0:53530.0.0.0:*   1004/avahi-
daemon: 
udp6   0  0
:::5353 :::*1533/snapwe
b
udp6   0  0
:::5353 :::*1004/avahi-
daemon: 

Chris

-- 
Chris
KeyID 

Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 13:13:09 +0100
RW wrote:

> On Tue, 19 Sep 2017 09:27:13 +0100
> Sebastian Arcus wrote:
> 
> > I've had a number of emails with no subject not triggering the 
> > MISSING_SUBJECT rule - only to discover that the spammers have added
> > a white space after 'Subject:' 

> Some  people send emails without setting a subject but the client will 
> normally
> still add the header. 

I checked that and some do and some don't. 

gmail adds a Subject header with a space.


Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread David Jones

On 09/19/2017 07:23 AM, Kevin A. McGrail wrote:

Is it purposeful extra space though that might indicate spaminess? Spample?
Regards,
KAM

On September 19, 2017 8:13:09 AM EDT, RW  wrote:

On Tue, 19 Sep 2017 09:27:13 +0100
Sebastian Arcus wrote:

I've had a number of emails with no subject not triggering the
MISSING_SUBJECT rule - only to discover that the spammers have added
a white space after 'Subject:' - which appears to fool the code
into
thinking that there is an actual subject. Would it be possible to
'smarten up' the code a bit to recognise this?


The space doesn't make a difference.

The test is for a missing subject not an empty subject. Some  people
send emails without setting a subject but the client will normally
still add the header.



I have had these in place for years.  Maybe Kevin can consolidate and 
integrate this into his KAM.cf so I could remove them or we could 
eventually get them into the default SA ruleset after some testing.


header  ENA_SUBJ_IS_SPACE   Subject =~ /^ $/
describeENA_SUBJ_IS_SPACE   Subject is a space
score   ENA_SUBJ_IS_SPACE   3.2

header  ENA_SUBJ_ONLY_SPACESSubject =~ /^\s+$/
describeENA_SUBJ_ONLY_SPACESSubject is empty or only spaces 
commonly used by spammers to get around subject checks

score   ENA_SUBJ_ONLY_SPACES2.2

header  ENA_SUBJ_ONLY_FWD   Subject =~ 
/(^Fw:\s+$|^Fw\s+$|^Fwd:\s+$|^Fwd\s+$|^Fwd: \(\d\)$|^Fwd: \[\d\]$)/i

describeENA_SUBJ_ONLY_FWD   Subject is only "Fwd:"
score   ENA_SUBJ_ONLY_FWD   2.2

header  ENA_SUBJ_ONLY_RESubject =~ 
/(^Re:\s+$|^Re\s+$|^Re: \(\d\)$|^Re: \[\d\]$)/i

describeENA_SUBJ_ONLY_RESubject is only "Re:"
score   ENA_SUBJ_ONLY_RE2.2

header  ENA_SUBJ_LONG_WORD  Subject =~ 
/\b[^[:space:][:punct:]]{30}/

describeENA_SUBJ_LONG_WORD  Subject has a very long word
score   ENA_SUBJ_LONG_WORD  2.2

header  ENA_SUBJ_ODD_CASE   Subject =~ 
/(?:[[:lower:]][[:upper:]].{0,15}){3}/

describeENA_SUBJ_ODD_CASE   Subject has odd case
score   ENA_SUBJ_ODD_CASE   3.2


--
David Jones


Re: OT - Hotmail/Outlook.com marking most of our email as Junk

2017-09-19 Thread David Jones

On 09/19/2017 01:25 AM, Sebastian Arcus wrote:
This is a bit off topic as it is not directly related to SA, but I'm 
hoping that with the email and spam expertise on this group, someone 
might throw in a useful idea - which would be much appreciated.


I have this problem on one site where most emails we send to 
Hotmail/Outlook.com/Live.com email addresses end up in Junk at the 
recipient's end. Things I have tried:


1. I've setup SPF, DKIM, DMARC (and set it to 'reject').

2. We used to smart relay outbound email through the hosting provider 
(1and1), but now changed to send directly from our own IP address, so 
that we can control the reputation of the sending IP - no change.


3. I've checked our public IP and the domain name at mxtoolbox.com - all 
tests pass (the public IP has been delisted from the Spamhaus 
non-MX/end-user IP database).


4. I've setup forward and reverse DNS entries for our IP address.

5. I've checked with all DNS blocklists/blacklists I could find - our 
domain or IP address is not flagged up anywhere.


6. This is a small network which I've been managing for years - the 
domain name has not been used to send marketing/lists email of any sort 
- so the historic reputation should be fine.


7. I've setup a monitor and block on port 25 outbound on the network 
firewall - in case there is a trojan on a machine on the network sending 
out spam and ruining the reputation of our IP - it's never been triggered.


8. I've checked the contents of outgoing emails - this is an accountants 
practice - the email content is standard, there is nothing there which 
should trigger bayesian filters.


9. I've sent emails to other servers under my control running SA - the 
scores come out perfect at the receiving end.


10. The emails we send are operational and notices emails to customers - 
who need them. They call on the phone and complain they haven't received 
them - just to discover they were sent, but ended up in the junk.


11. Emails we send to any other domains are never a problem spam-wise.

I can't really think of anything else to try - have I missed anything? 
Are Hotmail/Outlook.com spam filters a complete lottery?


It would help to see an example of this email in pastbin.  I beleive you 
when you say you have everything setup correctly but seeing an example 
may trigger an idea.


Also, you should try to send an email to https://www.mail-tester.com and 
see how it's scored.  This is an easy way to check everything above from 
a receiver's perspective.  From everything you have said above, you 
should get a score of 10 with a good/normal subject and message body.


--
David Jones


Re: ISIPP - Re: bb.barracudacentral.org

2017-09-19 Thread David Jones

On 09/18/2017 06:03 PM, Chris wrote:

On Mon, 2017-09-18 at 12:32 -0500, David Jones wrote:

On 09/18/2017 11:52 AM, Chris wrote:


On Mon, 2017-09-18 at 11:40 -0500, David Jones wrote:


On 09/18/2017 11:14 AM, Chris wrote:



On Mon, 2017-09-18 at 11:11 -0400, Bill Cole wrote:



On 18 Sep 2017, at 10:57, Chris wrote:

[...]








I am receiving many hits on *_IADB_* rules just fine
recently
for
emails
from constantcontact.com and others.

I'm receiving rule hits:

TOP HAM RULES FIRED
RANKRULE NAME   COUNT  %OFMAIL
%OFSPAM  %OFHAM
40RCVD_IN_IADB_SPF4 4.260.0
0
   4.5
5
43RCVD_IN_IADB_LISTED 4 4.260.0
0
   4.5
5
48RCVD_IN_IADB_DK 4 4.260.0
0
   4.5
5
51RCVD_IN_IADB_RDNS   3 3.190.0
0
   3.4
1
55RCVD_IN_IADB_SENDERID   3 3.190.0
0
   3.4
1
81RCVD_IN_IADB_OPTIN  1 1.060.0
0
   1.1
4

Yesterday instead of seeing host unreachable as I posted
above
I'm
seeing this

Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected
RCODE
resolving 'isipp.com/NS/IN': 168.150.251.35#53
Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected
RCODE
resolving 'concerto.isipp.com/A/IN': 168.150.251.35#53
Sep 17 09:30:41 localhost named[1284]: REFUSED unexpected
RCODE
resolving '10.232.124.38.iadb.isipp.com/A/IN':
168.150.251.35#53

Why are you asking 168.150.251.35 to do DNS resolution for
you?
It is
not authoritative for isipp.com, so presumably you have a
specific
local config causing you to use it. It is explicitly refusing
to
do
DNS resolution for you.

I honestly have no idea where that came about. I know that on
Saturday
I was seeing this:

SERVFAIL unexpected RCODE resolving
'121.244.54.142.iadb.isipp.com/A/IN': 67.227.187.192#53

Then yesterday I started seeing

named[1284]: REFUSED unexpected RCODE resolving
'isipp.com/NS/IN':
168.150.251.35#53

So to be honest I have no idea where it's coming from.
Something
appears to be messed up somewhere to be sure. However, I've
made
absolutely no changes to anything.


Check your /etc/resolv.conf and make sure that something didn't
change
it.  Most SA instances should have a local DNS caching server so
/etc/resolv.conf should be pointing to 127.0.0.1 and the local
DNS
server should be doing it's own recursive lookups -- not
forwarding
to
any other DNS server so your queries don't get combined with
others
and
go over daily usages limits that many RBLs have.  This has been
covered
extensively on this list if you want to search the archives for
URIBL_BLOCKED.

Run a "dig +trace" from the SA server where the /etc/resolv.conf
is
pointed to 127.0.0.1 to troubleshoot and you should get some
responses
similar to this:

dig +trace 65.43.116.208.iadb.isipp.com

...
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.3
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.4
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.2
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.202
.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.3.100.1
0
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.201
.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.1.255

If you don't get some 127.xx.xx.xx responses then look at the dig
output
to see where things stop.  The first "hop" should be from
127.0.0.1
then
start walking down the DNS tree from right to left.


Here's what I see:

65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.201.1
0
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.3.100.10
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.1
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.4
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.0.2
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.2.255.3
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.101.202.1
0
65.43.116.208.iadb.isipp.com. 3600 IN   A   127.0.1.255
iadb.isipp.com. 172800  IN  NS  ns
1.ns
.isipp.com.
iadb.isipp.com. 172800  IN  NS  c.
auth
-ns.sonic.net.
iadb.isipp.com. 172800  IN  NS  ns
01.b
ackupdns.com.
iadb.isipp.com. 172800  IN  NS  ns
2.pr
gmr.com.
iadb.isipp.com. 172800  IN  NS  ns
2.ns
.isipp.com.
iadb.isipp.com. 172800  IN  NS  a.
auth
-ns.sonic.net.
iadb.isipp.com. 172800  IN  NS  b.
auth
-ns.sonic.net.
;; Received 434 bytes from 216.218.223.67#53(ns2.prgmr.com) in 66
ms


cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE
OVERWRITTEN
nameserver 127.0.0.1


nameserver 127.0.0.1
search PK5001Z


I was showing a good lookup and you got back the same results as I

Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread Kevin A. McGrail
Is it purposeful extra space though that might indicate spaminess?  Spample? 
Regards,
KAM

On September 19, 2017 8:13:09 AM EDT, RW  wrote:
>On Tue, 19 Sep 2017 09:27:13 +0100
>Sebastian Arcus wrote:
>
>> I've had a number of emails with no subject not triggering the 
>> MISSING_SUBJECT rule - only to discover that the spammers have added
>> a white space after 'Subject:' - which appears to fool the code into 
>> thinking that there is an actual subject. Would it be possible to 
>> 'smarten up' the code a bit to recognise this?
>
>The space doesn't make a difference.
>
>The test is for a missing subject not an empty subject. Some  people
>send emails without setting a subject but the client will normally
>still add the header.   


Re: MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread RW
On Tue, 19 Sep 2017 09:27:13 +0100
Sebastian Arcus wrote:

> I've had a number of emails with no subject not triggering the 
> MISSING_SUBJECT rule - only to discover that the spammers have added
> a white space after 'Subject:' - which appears to fool the code into 
> thinking that there is an actual subject. Would it be possible to 
> 'smarten up' the code a bit to recognise this?

The space doesn't make a difference.

The test is for a missing subject not an empty subject. Some  people
send emails without setting a subject but the client will normally
still add the header.   


Re: OT - Hotmail/Outlook.com marking most of our email as Junk

2017-09-19 Thread G Roach
Microsoft use their own methods of detection including based on 
reputation and 'length of service' - ie, if you have only just started 
sending emails out from your own address (which you have) then they may 
well consider you suspicious. Theres not much yo can do about it.   More 
info here: https://mail.live.com/mail/troubleshooting.aspx




On 19/09/2017 07:25, Sebastian Arcus wrote:
This is a bit off topic as it is not directly related to SA, but I'm 
hoping that with the email and spam expertise on this group, someone 
might throw in a useful idea - which would be much appreciated.


I have this problem on one site where most emails we send to 
Hotmail/Outlook.com/Live.com email addresses end up in Junk at the 
recipient's end. Things I have tried:


1. I've setup SPF, DKIM, DMARC (and set it to 'reject').

2. We used to smart relay outbound email through the hosting provider 
(1and1), but now changed to send directly from our own IP address, so 
that we can control the reputation of the sending IP - no change.


3. I've checked our public IP and the domain name at mxtoolbox.com - 
all tests pass (the public IP has been delisted from the Spamhaus 
non-MX/end-user IP database).


4. I've setup forward and reverse DNS entries for our IP address.

5. I've checked with all DNS blocklists/blacklists I could find - our 
domain or IP address is not flagged up anywhere.


6. This is a small network which I've been managing for years - the 
domain name has not been used to send marketing/lists email of any 
sort - so the historic reputation should be fine.


7. I've setup a monitor and block on port 25 outbound on the network 
firewall - in case there is a trojan on a machine on the network 
sending out spam and ruining the reputation of our IP - it's never 
been triggered.


8. I've checked the contents of outgoing emails - this is an 
accountants practice - the email content is standard, there is nothing 
there which should trigger bayesian filters.


9. I've sent emails to other servers under my control running SA - the 
scores come out perfect at the receiving end.


10. The emails we send are operational and notices emails to customers 
- who need them. They call on the phone and complain they haven't 
received them - just to discover they were sent, but ended up in the 
junk.


11. Emails we send to any other domains are never a problem spam-wise.

I can't really think of anything else to try - have I missed anything? 
Are Hotmail/Outlook.com spam filters a complete lottery?




MISSING_SUBJECT not triggered if subject contains whitespace

2017-09-19 Thread Sebastian Arcus
I've had a number of emails with no subject not triggering the 
MISSING_SUBJECT rule - only to discover that the spammers have added a 
white space after 'Subject:' - which appears to fool the code into 
thinking that there is an actual subject. Would it be possible to 
'smarten up' the code a bit to recognise this?


OT - Hotmail/Outlook.com marking most of our email as Junk

2017-09-19 Thread Sebastian Arcus
This is a bit off topic as it is not directly related to SA, but I'm 
hoping that with the email and spam expertise on this group, someone 
might throw in a useful idea - which would be much appreciated.


I have this problem on one site where most emails we send to 
Hotmail/Outlook.com/Live.com email addresses end up in Junk at the 
recipient's end. Things I have tried:


1. I've setup SPF, DKIM, DMARC (and set it to 'reject').

2. We used to smart relay outbound email through the hosting provider 
(1and1), but now changed to send directly from our own IP address, so 
that we can control the reputation of the sending IP - no change.


3. I've checked our public IP and the domain name at mxtoolbox.com - all 
tests pass (the public IP has been delisted from the Spamhaus 
non-MX/end-user IP database).


4. I've setup forward and reverse DNS entries for our IP address.

5. I've checked with all DNS blocklists/blacklists I could find - our 
domain or IP address is not flagged up anywhere.


6. This is a small network which I've been managing for years - the 
domain name has not been used to send marketing/lists email of any sort 
- so the historic reputation should be fine.


7. I've setup a monitor and block on port 25 outbound on the network 
firewall - in case there is a trojan on a machine on the network sending 
out spam and ruining the reputation of our IP - it's never been triggered.


8. I've checked the contents of outgoing emails - this is an accountants 
practice - the email content is standard, there is nothing there which 
should trigger bayesian filters.


9. I've sent emails to other servers under my control running SA - the 
scores come out perfect at the receiving end.


10. The emails we send are operational and notices emails to customers - 
who need them. They call on the phone and complain they haven't received 
them - just to discover they were sent, but ended up in the junk.


11. Emails we send to any other domains are never a problem spam-wise.

I can't really think of anything else to try - have I missed anything? 
Are Hotmail/Outlook.com spam filters a complete lottery?