Re: learn ham

> On Jan 5, 2017, at 8:54 AM, Dave Funk wrote: > > On Thu, 5 Jan 2017, Nicola Piazzi wrote: > >> Each minute it learn messages of the last minute so it read and learn one >> time only for each message >> Messages are that it sends from internal, so il learn that

Re: Weird Spamassassin startup behaviour on Ubuntu 16.10

en.com>> wrote: Right, it was upgraded from Ubuntu 14.10 I thought apt-get dist-upgrade + update + upgrade is supposed to migrate that stuff? On 8/12/16 06:39, Shawn Bakhtiar wrote: Good point. Although since ubuntu 16.x systemD is the default init system, which begs the question, wa

Re: Weird Spamassassin startup behaviour on Ubuntu 16.10

; instruction. If it says upstart, then you'll most likely need to edit > /etc/init.d/spamassassin instead. > > On Wed, 7 Dec 2016, Shawn Bakhtiar wrote: > >> Yeah... it's missing the "after" directive in the [unit] section, which >> would have systemD wait unti

Re: Weird Spamassassin startup behaviour on Ubuntu 16.10

HUP $MAINPID [Install] WantedBy=multi-user.target Does this seem to be outdated and wrong? - Michael On 7/12/16 09:29, Shawn Bakhtiar wrote: With Ubuntu 16.10 you should be using systemd. you can enable dependencies (after directive) which can make sure that all the services you need are started

Re: Weird Spamassassin startup behaviour on Ubuntu 16.10

With Ubuntu 16.10 you should be using systemd. you can enable dependencies (after directive) which can make sure that all the services you need are started prior to (in the case of SA) the service you want. Check your systemD service configuration file:

Re: Anyone else just blocking the ".top" TLD?

7.59%) Per that, TOP accounts for 64% of the problem. SCIENCE is next at a mere 8%. While XYZ comes in at #15 on the SURBL abused domains list at present in raw numbers, as a percentage of it's email volume it seems it's abuse is quite low. From: Shawn Bakhtiar

Re: Anyone else just blocking the ".top" TLD?

Unless you have customers/employees/vendors complaining that they are not receiving legitimate email from that TLD why would you un block it?? On Nov 3, 2016, at 9:27 AM, Vincent Fox > wrote: Resurrecting thread TOP remains at the err...

Re: DNS Terminology

A forwarding name server simply forwards (proxies) the query to an upstream recursive server. On Sep 23, 2016, at 9:03 AM, RW > wrote: On Thu, 22 Sep 2016 20:24:21 -0700 (PDT) John Hardin wrote: Lists shouldn't have said

Re: Spam by IP-address? Spamassassin with geoiplookup?

> On Sep 20, 2016, at 8:13 AM, RW <rwmailli...@googlemail.com> wrote: > > On Tue, 20 Sep 2016 14:34:02 + > Shawn Bakhtiar wrote: > >> If you are strictly looking to block by IP addresses this is a far >> better task left to the firewall, and configured

Re: Spam by IP-address? Spamassassin with geoiplookup?

If you are strictly looking to block by IP addresses this is a far better task left to the firewall, and configured by networks not individual IP addresses. There are many ranges which should not be sending email directly (IE those allocated by providers to home users). Unfortunately finding

Re: spamassassin and caching nameservers

Not sure if this helps but I use bind dlz with a mysql back-end as DNSBL of last resort. We get the IP addresses from honeypot emails, and it works pretty good. I have a daemon running in the background that uses a few intermediary tables with metrics like last seen, rate, total count, etc.. to

Re: Matching infinite sets

On Aug 22, 2016, at 10:44 AM, Marc Perkel > wrote: On 08/22/16 09:06, Dianne Skoll wrote: On Mon, 22 Aug 2016 09:03:38 -0700 Marc Perkel > wrote: The ones that are

Re: Matching infinite sets

> On Aug 22, 2016, at 8:09 AM, John Hardin wrote: > > On Mon, 22 Aug 2016, Antony Stone wrote: > >> On Monday 22 August 2016 at 16:45:09, Dianne Skoll wrote: >> >>> On Mon, 22 Aug 2016 07:34:00 -0700 Marc Perkel wrote: > So. What percentage of emails using your

Re: I have some bad news

On Aug 17, 2016, at 3:43 AM, Matus UHLAR - fantomas > wrote: On 16.08.16 20:06, Marc Perkel wrote: What I'm doing is looking for fingerprints in email that intersect HAM and not in SPAM - which would be a HAM result. If it matches SPAM and does NOT

Re: I have some bad news

Marc, Let me first say I am truly sorry to here about your cancer. I lost my father to cancer just over a decade ago, after a long battle with sarcoma of the throat and tongue. So I pray and wish you the best. I sent this to you in January 2016 (don't recall if I ever got a reply to it) but

Re: Using Postfix and Postgrey - not scanning after hold

> On Jul 29, 2016, at 10:42 AM, Reindl Harald <h.rei...@thelounge.net> wrote: > > > Am 29.07.2016 um 19:26 schrieb Shawn Bakhtiar: >> >>> On Jul 29, 2016, at 10:12 AM, @lbutlr <krem...@kreme.com> wrote: >>> >>> On 29 Jul 2016, a

Re: Using Postfix and Postgrey - not scanning after hold

> On Jul 29, 2016, at 10:12 AM, @lbutlr wrote: > > On 29 Jul 2016, at 09:20, sha...@shanew.net wrote: >> I would generalize that even more to say that greylisting should come >> before any other content-based filtering (virus scanners, defanging, >> etc.). > > Greylisting is

Re: whitelist issues with sprintpcs.com

One possibility I don't see mentioned is to simply accept this at the MTA level. I've often had to do this when a sending domain is misconfigured but is part of our legitimate senders. It obviously opens up doors you'll have to monitor other ways. but in Sendmail it is as simple as adding the

Re: Which DNSBLs do you use?

> On Jun 17, 2016, at 7:25 AM, Vincent Fox wrote: > > Greylisting imo helps a lot with RBL lag. It can, but it's definitely a double edge sword. Depending on the way the remote MTA works, I've experienced emails being delayed for quite sometime. I had a lot of users

Re: Which DNSBLs do you use?

> On Jun 16, 2016, at 7:54 AM, Merijn van den Kroonenberg > wrote: > >> Agreed. >> >> We use sendmail, and check our DNSBL's their, it is much more efficient to >> use them before we ever engage SA. It is extremely rare to find an IP that >> lands on a reputable DNSBL and

Re: Which DNSBLs do you use?

> On Jun 16, 2016, at 7:31 AM, Reindl Harald <h.rei...@thelounge.net> wrote: > > > Am 16.06.2016 um 16:21 schrieb Shawn Bakhtiar: >> Agreed. >> >> We use sendmail, and check our DNSBL's their, it is much more efficient to >> use them before we ev

Re: Which DNSBLs do you use?

Agreed. We use sendmail, and check our DNSBL's their, it is much more efficient to use them before we ever engage SA. It is extremely rare to find an IP that lands on a reputable DNSBL and in those cases we can whitelist. Of course most of our traffic is B2B, not sure how effective this would

Re: Which DNSBLs do you use?

zen.spamhaus.org bl.spamcop.net b.barracudacentral.org dnsbl.inksystems.com <-- private internal one derived from honeypot email address we have. I have disabled dnsbl.sorbs.net as they are too aggressive for our purposes, they block a lot of Gmail et al, which a lot of our customers and

Re: URIBL/DNSBL from a database

I use to spend a lot of time blocking hosts and subnets, using IP tables, of malicious providers who would let any tom, dick, and Harry (no pun intended) to host spam hosts/relays on their servers. What I ended up doing is also blocking a lot SMB vendors from sending legitimate emails to users

Re: URIBL/DNSBL from a database

On Feb 12, 2016, at 5:39 AM, Alex > wrote: Hi, For some time now I've been cycling URLs and IPs through a mariadb database gathered from incoming mail on a honeypot I've created. Surprising how many are received ahead of

Re: OUTPUT OF SPAMASSASSIN

> On Jan 24, 2016, at 11:29 AM, Martin Gregorie wrote: > > On Mon, 2016-01-25 at 00:07 +0530, Sarang Shrivastava wrote: >> I am just a newbie who has started using SA. Someone on the mailing >> list suggested me to use -D option. So if this option is for >> debugging then

Re: My new method for blocking spam - REVEALED!

Sorry.. how is this different than Naive Bayes filtering?? "Naive Bayes classifiers work by correlating the use of tokens (typically words, or sometimes other things), with spam and non-spam e-mails and then using Bayes' theorem to calculate a probability that an email is or is not spam." —