Re: URIBL_BLOCKED while using local BIND

[Matus UHLAR - fantomas]

On 16.09.15 09:50, Bowie Bailey wrote:
The SA config is probably a better solution than the bind exemptions.  


I would say just the opposite. For example, MTA at SMTP level can look up
RBLs, and SA would benefit from having records in local cache.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes. 

Re: Heads up: Net::DNS update may have quietly broken your SpamAssassin.

[Mark Martinec]

Olivier Nicole wrote:

"Bill Cole"  writes:

I noticed today that the hit rate on URIBL* rules had dropped to to 
zero

since my last round of updates, and after many hours of trying to
determine why which included reviewing BIND configs and packet 
captures

and dissection, I nailed it down to SA making DNS queries without the
"recursion desired" flag. Since my local nameservers isn't 
authoritative

for much, this meant a whole lot of "no answer, no error" DNS replies.

It turns out that this is due to an internal change introduced in 
recent

versions of Net::DNS, which SA relied upon to set the RD flag
automatically. See
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 for details 
and

a patch.


Thank you. I just check and for what it is worth, recent installations 
of

SA on FreeBSD do include the patch.

Best regards,
Olivier


Not to forget the fix at:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283
which is also needed with Net::DNS 1.01 or later.

Already cherrypicked in the FreeBSD port of SpamAssassin:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283

Mark

Re: Heads up: Net::DNS update may have quietly broken your SpamAssassin.

[Mark Martinec]

Not to forget the fix at:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283
which is also needed with Net::DNS 1.01 or later.


Sorry, wrong link, should be:
  https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7231


Already cherrypicked in the FreeBSD port of SpamAssassin:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202283



Mark

Re: Resume / Doc Spam

[Anthony Kamau]

On 09/09/15 07:26, John Schmerold wrote:



I haven't had the courage to open in word, if I open in 7zip, I see 
following files:

 Directory of C:\


No courage needed.  Simply install Sanboxie [0] (preferably in a VM) and 
you can safely open any application inside the sandbox and see what it 
invokes.


Cheers,
AK.

[0] - http://www.sandboxie.com/index.php?HowItWorks

Re: Heads up: Net::DNS update may have quietly broken your SpamAssassin.

[Olivier Nicole]

"Bill Cole"  writes:

> I noticed today that the hit rate on URIBL* rules had dropped to to zero 
> since my last round of updates, and after many hours of trying to 
> determine why which included reviewing BIND configs and packet captures 
> and dissection, I nailed it down to SA making DNS queries without the 
> "recursion desired" flag. Since my local nameservers isn't authoritative 
> for much, this meant a whole lot of "no answer, no error" DNS replies.
>
> It turns out that this is due to an internal change introduced in recent 
> versions of Net::DNS, which SA relied upon to set the RD flag 
> automatically. See 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7223 for details and 
> a patch.

Thank you. I just check and for what it is worth, recent installations of
SA on FreeBSD do include the patch.

Best regards,

Olivier

>

-- 

Re: Resume / Doc Spam

[Dianne Skoll]

On Fri, 18 Sep 2015 21:51:59 +1000
Anthony Kamau  wrote:

> No courage needed.  Simply install Sanboxie [0] (preferably in a VM)
> and you can safely open any application inside the sandbox and see
> what it invokes.

Or use LibreOffice which has macros turned off by default, but lets
you examine existing macros in the macro organizer.

Regards,

Dianne.

Re: URIBL_BLOCKED while using local BIND

[Bowie Bailey]

On 9/18/2015 4:25 PM, Matus UHLAR - fantomas wrote:

On 16.09.15 09:50, Bowie Bailey wrote:
The SA config is probably a better solution than the bind exemptions. 


I would say just the opposite. For example, MTA at SMTP level can look up
RBLs, and SA would benefit from having records in local cache


True.  I was thinking more in terms of the amount of work needed in 
setup and maintenance.  Whenever SA changes it's RBL list (which is, 
admittedly, not that often), you need to update the exemption list in 
bind.  And if you make a typo in the domain name, it is not immediately 
obvious since you are still getting results from the query.


On the other hand, if you point SA to it's own non-forwarding DNS 
server, it just works and you don't have to touch it again.


--
Bowie

RE: What is the meaning of "host=NULL"

[Ken Johnson]

Bill,

Thanks for the helpful reply.  I performed a reverse lookup on several of
the IPs, but didn't take the next step of looking up the name in the PTR.

Ken


On 17 Sep 2015, at 15:35, Ken Johnson wrote:

> Spamassassin is run by Exim.
>
> Spamassassin version:
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07)
> X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +)
> from dpkg: spamassassin 3.4.0-2~bpo70+1
>
> Platform: Debian 7.8
>
> A recent surge in unfiltered spam made me re-examine log files.  Every 
> message I found that generated a log entry like this:
>
> :2015-09-09 07:35:40 1ZZeb1-00053O-Hy SA: Action: scanned but message 
> isn't
> spam: score=3.7 required=4.0 (scanned in 13/13 secs | Message-Id:
> NDY1OGI4NmNhYjc3YTU3YmM3MzExYjBhMTY0MzY2ZWM_@URLTHATMUSTNOTBENAMED). 
> From
>  (host=NULL [45.58.126.146]) for x...@y.com
>
> which included the string "(host=NULL " was a message I could safely 
> filter out.  Or at least, could safely add two or three to the score.
>
> What condition or attribute of received mail corresponds to a log 
> entry of "host=NULL"?

Bill Cole wrote:

That precise wording seems to be an artifact of the Exim-SA plumbing (I've
never seen SA itself generate "host=NULL" anywhere I use it) but based on
the context and DNS fact, it would appear to be an indication that there is
no valid hostname discernible for that IP address. In this specific case,
the IP has a PTR record but the name in that PTR record has no A record
confirming the name-IP relationship (or any records at
all.)