Re: ISIPP - Re: bb.barracudacentral.org
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, RWwrote: 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
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
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
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
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
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
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, RWwrote: 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
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
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
Is it purposeful extra space though that might indicate spaminess? Spample? Regards, KAM On September 19, 2017 8:13:09 AM EDT, RWwrote: >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
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
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
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
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?