Re: TxRep $msgscore warning

[J.J. Day]

>> On Apr 30, 2015, at 1:29 PM, Kevin A. McGrail  wrote:
>> 
>> On 4/30/2015 1:15 PM, Kevin A. McGrail wrote:
>> Can you add this block of code above line 1386 in the current TxRep.pm?  
>> Then we'll try and figure out how to enable the TxRep debug channel from MD 
>> so you can log the info and relay it.  It also should hide the informat
> Can you try this in your milter? Untested but based on discussions with DFS 
> from MD:  $SASpamTester = Mail::SpamAssassin->new( debug=>"TxRep" )
> 
> Regards,
> KAM

I may have done something wrong. Mimedefang is dying with an error.
I attached the defang log portion and the diffs for TxRep and mimedefang.

Regards,

Mimedefang log extract:

Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: started;
minSlaves=2, maxSlaves=10, maxRequests=500, maxIdleTime=300, busyTim
eout=600, clientTimeout=10
Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: Starting slave 0
(pid 12713) (1 running): Bringing slaves up to minSlaves (2)
Apr 30 14:51:22 mailsys mimedefang[12727]: IP validation header is
X-MIMEDefang-Relay-b2b825afac8a3d1ce58c1f997293ee3a75854c05
Apr 30 14:51:22 mailsys mimedefang[12727]: MIMEDefang alive.
slavesReservedForLoopback=-1 AllowNewConnectionsToQueue=0 doRelayCheck=
0 doHeloCheck=1 doSenderCheck=1 doRecipientCheck=1
Apr 30 14:51:22 mailsys mimedefang[12727]: Multiplexor alive - entering
main loop
Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: Slave 0 stderr:
Can't locate object method "new" via package "Mail::SpamAssas
sin" at /usr/local/etc/mimedefang/mimedefang-filter line 66.
Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: Slave 0 stderr:
Compilation failed in require at /usr/local/bin/mimedefang.pl
line 5279.
Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: Reap: slave 0 (pid
12713) exited normally with status 255 (SLAVE DIED UNEXPEC
TEDLY)
Apr 30 14:51:22 mailsys mimedefang-multiplexor[12711]: Slave 0 resource
usage: req=0, scans=0, user=0.337, sys=0.031, nswap=0, majfl
t=0, minflt=1966, maxrss=10788, bi=0, bo=0


TxRep diff:

#diff TxRep.original
/usr/local/lib/perl5/site_perl/5.16/Mail/SpamAssassin/Plugin/TxRep.pm 

1384a1385,1406
>  {
> #Bug 7164, trying to find out reason for these: _WARN: Use of
uninitialized value $msgscore in addition (+) at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.
> no warnings;
> 
> unless (defined $msgscore) {
>   #Output some params and the calling function so we can identify
more about this bug
>   dbg("TxRep: Parameters: self: $self storage: $storage pms: $pms,
key: $key, id: $id, ip: $ip, signedby: $signedby, msgscore: $msgscore");
>   dbg("TxRep: weight: $weight");
> 
>   my ($package, $filename, $line) = caller();
> 
>   chomp($package);
>   chomp($filename);
>   chomp($line);
> 
>   dbg("TxRep: $msgscore undefined - Caller Info: Package: $package
- Filename: $filename - Line: $line");
> 
>   #Define $msgscore as a triage to hide warnings while we find the
root cause
>   $msgscore = 0;
> }
>   }
> 


Mimedefang diff:

#diff /usr/local/etc/mimedefang/mimedefang-filter
/usr/local/etc/mimedefang/mimedefang-filter.before.patch

63,68d62
< # TxRep $msgscore debug patch activation 
< # per KAM email 4/30/2015 @ 13:29
< #***
< $SASpamTester = Mail::SpamAssassin->new(debug=>"TxRep");
< 
< #***

ANNOUNCE: Apache SpamAssassin 3.4.1 available

[Kevin A. McGrail]

On behalf of the project, I am pleased to announce the release of Apache 
SpamAssassin v3.4.1.


Downloads are available at http://spamassassin.apache.org/downloads.cgi

regards,
KAM



Release Notes -- Apache SpamAssassin -- Version 3.4.1

Introduction


Apache SpamAssassin 3.4.1 represents more than a year of development
and nearly 500 tweaks, changes, upgrades and bug fixes over the previous
release. Highlights include: Improved automation to help combat spammers
that are abusing new top level domains; Tweaks to the SPF support to
block more spoofed emails; Increased character set normalization to
make rules easier to develop, block more international spam and stop
spammers from using alternate character sets to bypass tests;
Continued refinement to the native IPv6 support; and Improved Bayesian
classification with better debugging and attachment hashing.

Many thanks to the committers, contributors, rule testers, mass checkers,
and code testers who have made this release possible.  And please
recognize Joe Quinn for stepping up in the role of an assistant
Release Manager.

Notable features:
=

New plugins
---

There are three new plugins added with this release:

  Mail::SpamAssassin::Plugin::TxRep
  Mail::SpamAssassin::Plugin::PDFInfo
  Mail::SpamAssassin::Plugin::URILocalBL

The TxRep (Reputation) plugin is designed as a substantially improved
replacement of the AWL plugin. It adjusts the final message spam score
by looking up and taking in consideration the reputation of the sender.
It cannot coexist with the old AWL plugin, which must be disabled when
the TxRep is loaded.

The PDFInfo plugin helps detecting spam with attached PDF files.

The URILocalBL plugin creates some new rule test types, such as
"uri_block_cc", "uri_block_cidr", and "uri_block_isp".  These rules
apply to the URIs found in the HTML portion of a message, i.e.
 markup.

All these three plugins are disabled by default. To enable, uncomment
the loadplugin configuration options in file v341.pre, or add them to
some local .pre file such as local.pre .

Plugins are documented in their respective man pages.


Notable changes
---

A new subsystem RegistryBoundaries for recognizing and updating a list
of top-level domains and registry boundaries has been introduced, which
allows dynamically updating both lists through rule updates instead of
having them hard-wired in the code.

A subroutine Node::_normalize has been rewritten. The new behavior
is documented with the 'normalize_charset' option in the
Mail::SpamAssassin::Conf man page. (Bug 7144, Bug 7126, Bug 7133)

Tokenization of UTF-8 -encoded or normalized text has been improved
in the Bayes plugin. (Bug 7130, Bug 7135, Bug 7141)

SHA1 digests of all MIME parts (including non-textual) can now be
contributed to Bayes tokens, which allows the bayes classifier to assess
also the non-textual content. The set of sources of bayes tokens is
configurable with a new configuration option 'bayes_token_sources'
as documented in the Mail::SpamAssassin::Conf man page. (Bug 7115)
It is disabled by default for backward compatibility.


New configuration options
-

The 'normalize_charset' configuration option already existed in previous
versions, but functionality has been re-implemented with more emphasis
on the declared character set of each textual MIME part, instead of
relying on guesswork by Encode::Detect::Detector. When enabled, non-UTF8
textual parts of a mail message are decoded into Unicode and re-encoded
into UTF-8 before passing them to HTML decoding and to rules processing.
This makes it easier to write regular expressions and strings in rules
using UTF-8 encoding, and allows plugins (such as tokenization in a
Bayes plugin) to recognize multibyte characters and words in non-English
languages, instead of 'randomly' considering some non-ASCII octets in
multibyte characters as delimiters. Please see documentation for this
configuration option in the Mail::SpamAssassin::Conf man page.

A new configuration option 'bayes_token_sources' allows more control
on the sources of tokens for the Bayes plugin. For compatibility the
default set of sources is unchanged, but consider:
bayes_token_sources all
or: bayes_token_sources mimepart
to include SHA1 digests of all MIME parts in a message as Bayes tokens.
Please see documentation for this option in the Mail::SpamAssassin::Conf
man page.

A new configuration option 'dkim_minimum_key_bits' with a default value
of 1024 bits now controls the smallest size of a signing key (in bits)
for a valid signature to be considered for whitelisting. Please see
documentation for this option in the Mail::SpamAssassin::Plugin::DKIM
man page.

A new configuration option 'parse_dkim_uris' allows DKIM header fields
to be parsed for URIs and to be processed alongside other URIs found in
the body.

A configuration option 'dns_server' can now specify a scoped link-local
IPv6 address, e.g.:  dns_serve

Re: TxRep $msgscore warning

[Kevin A. McGrail]

On 4/30/2015 1:15 PM, Kevin A. McGrail wrote:
Can you add this block of code above line 1386 in the current 
TxRep.pm?  Then we'll try and figure out how to enable the TxRep debug 
channel from MD so you can log the info and relay it.  It also should 
hide the informat
Can you try this in your milter? Untested but based on discussions with 
DFS from MD:  $SASpamTester = Mail::SpamAssassin->new( debug=>"TxRep" )


Regards,
KAM

Re: TxRep $msgscore warning

[Kevin A. McGrail]

On 4/30/2015 11:44 AM, J.J. Day wrote:
FWIW, I switched to TxRep several months ago. Every message generates 
both error lines. I have added a test to initialize $msgscore to avoid 
filling my log files. Spam messages seem to all generate a negative 
offset of ~1/3 the total. I copied a sample to the end.


My setup is:
FreeBSD 10.0
Sendmail 8.14.7
Mimedefang 2.75
SpamAssassin 3.4.0
Cyrus 2.4.17

I hope this helps.
Interesting. So you are using the API.  On your same box if you run 
spamassassin -t with your sample, can you recreate the issue?


Otherwise, the sample doesn't help us because we can't recreate the 
issue, unfortunately.



DFS, with MD calling SA as an API, how do you turn on a debug channel?  
Happen to know?



Can you add this block of code above line 1386 in the current TxRep.pm?  
Then we'll try and figure out how to enable the TxRep debug channel from 
MD so you can log the info and relay it.  It also should hide the informat



 {
#Bug 7164, trying to find out reason for these: _WARN: Use of 
uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.

no warnings;

unless (defined $msgscore) {
  #Output some params and the calling function so we can identify 
more about this bug
  dbg("TxRep: Parameters: self: $self storage: $storage pms: $pms, 
key: $key, id: $id, ip: $ip, signedby: $signedby, msgscore: $msgscore");

  dbg("TxRep: weight: $weight");

  my ($package, $filename, $line) = caller();

  chomp($package);
  chomp($filename);
  chomp($line);

  dbg("TxRep: $msgscore undefined - Caller Info: Package: $package 
- Filename: $filename - Line: $line");


  #Define $msgscore as a triage to hide warnings while we find the 
root cause

  $msgscore = 0;
}
  }

Here's more detail about where it needs to be:

sub check_reputation {
###
  my ($self, $storage, $pms, $key, $id, $ip, $signedby, $msgscore) = @_;

  my $delta  = 0;
  my $weight = ($key eq 'MSG_ID')? 1 : 
eval('$pms->{main}->{conf}->{txrep_weight_'.lc($key).'}');


--> Block here

  if (defined $weight && $weight) {

Regards,
KAM

Re: TxRep $msgscore warning

[J.J. Day]

FWIW, I switched to TxRep several months ago. Every message generates both 
error lines. I have added a test to initialize $msgscore to avoid filling my 
log files. Spam messages seem to all generate a negative offset of ~1/3 the 
total. I copied a sample to the end.

My setup is:
FreeBSD 10.0
Sendmail 8.14.7
Mimedefang 2.75
SpamAssassin 3.4.0
Cyrus 2.4.17

I hope this helps. 

JJ Day

>> On Apr 30, 2015, at 8:36 AM, Joe Quinn  wrote:
>> 
>>> On 4/30/2015 9:22 AM, Joe Quinn wrote:
 On 4/30/2015 9:10 AM, Birta Levente wrote:
> On 30/04/2015 15:55, Joe Quinn wrote:
> On 4/30/2015 7:09 AM, Birta Levente wrote:
> Hi
> 
> I saw the bug report about TxRep warning:
> _WARN: Use of uninitialized value $msgscore in addition (+) at 
> /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.
> _WARN: Use of uninitialized value $msgscore in subtraction (-)
> 
> 
> I just wonder if there is any workaroung for that or if exists any effect 
> of this warning?
> 
> Thanks
 We know about the issue but have been having trouble reproducing it in a 
 way we can experiment on to find where the bug is.
 
 Can you generate a reproduction or post samples and relevant txrep rows to 
 this bug?
 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164
>>> 
>>> I will, but only next week.
>>> What you mean in samples? Full email with body or just headers?
>> Full email would be best. It can be something contrived if it can reproduce 
>> the issue on your system. And since we're not sure what causes it, your 
>> TxRep configuration and any rows of your txrep table that match will be 
>> helpful too.
>> 
>> The warning should be harmless and won't affect your mail flow in the 
>> meantime.
> Can you also include how you call spamassassin? Are you using built-in glue 
> from a milter like MD, or spamassassin, or spamc/spamd?


Sample spam

> From: "Evgeniya" 
> Date: April 25, 2015 at 12:07:46 AM CDT
> To: yoko@
> Subject: Hello yoko
> Reply-To: yokor...@okloksp.com.br
> 
> Hello yoko!!! My name is Evgeniya, to me of 25 years. I live in Russia.
> I saw your your profile and you interested me very much! 
> I want to find the man of my dream.
> 
> I would like to get acquainted with the person who might appreciate my care, 
> tenderness and love.
> I want, that you would be responsible, capable to give a hand of the help and 
> to sympathize with me in any problems.
> 
> If you agree with me write to me, I shall be glad. I shall answer you soon. 
> In my turn I shall try be the offer, loving, devoted, responsible woman.
> 
> If you decide to write to me, I wait for your answer very much !!! 
> 
> My Email al.buloychick2...@yandex.ru
> 
> Spam detection software, running on the system "",
> has identified this incoming email as possible spam.  The original
> message has been attached to this so you can view it or label
> similar future email.  If you have any questions, see
> The administrator of that system for details.
> 
> Content preview:  Hello yoko!!! My name isEvgeniya, to me of 25 years. I live
>   in Russia. I saw your your profile and you interested me very much! I want
>   to find the man of my dream. I would like to get acquainted with the person
>   who might appreciate my care,tenderness and love. I want, that you would
>  be responsible, capable to give a hand of the help and tosympathize with me
>   in any problems. [...] 
> 
> Content analysis details:   (10.3 points, 4.7 required)
> 
> pts rule name  description
>  -- --
> 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
>  [Blocked - see ]
> 1.6 RCVD_IN_BRBL_LASTEXT   RBL: No description available.
>[115.167.70.173 listed in bb.barracudacentral.org]
> 0.7 RCVD_IN_XBLRBL: Received via a relay in Spamhaus XBL
>[115.167.70.173 listed in zen.spamhaus.org]
> 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
> 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
>https://senderscore.org/blacklistlookup/
>   [115.167.70.173 listed in bl.score.senderscore.com]
> 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
>[115.167.70.173 listed in psbl.surriel.com]
> 3.0 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
>[115.167.70.173 listed in bl.mailspike.net]
> 0.0 HTML_MESSAGE   BODY: HTML included in message
> 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted
> 1.3 RDNS_NONE  Delivered to internal network by a host with no 
> rDNS
> 0.0 HELO_MISC_IP   Looking for more Dynamic IP Relays
> -5.2 TXREP  TXREP: Score normalizing based on sender's 
> reputation
> 
> 

Re: AWL defeating my SPAM classification

[Reindl Harald]

Am 30.04.2015 um 17:06 schrieb Benny Pedersen:

Matus UHLAR - fantomas skrev den 2015-04-30 12:55:


no, it's the "dig" command that does the trace, not the nameserver.
This says nothing about your nameserver configuration, and it can't since
nameserver does not provide that info.


dig respects resolv.conf with nameserver 127.0.0.1

try it :)

dig @8.8.8.8 +trace example.org


that's bullshit - it just asks there for the root-ns
how does that help?

you should try to understand the context
where is my forwarder named is using in the trace output?
nowhere! and so *how* would that help to
answer the question if the nameserver does forwarding
or recursion? it don't - period

[harry@srv-rhsoft:~]$ dig +trace example.org | grep 10.0.0.6
[harry@srv-rhsoft:~]$

[harry@srv-rhsoft:~]$ dig +trace example.org
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> +trace example.org
;; global options: +cmd
.   2825IN  NS  l.root-servers.net.
.   2825IN  NS  m.root-servers.net.
.   2825IN  NS  j.root-servers.net.
.   2825IN  NS  b.root-servers.net.
.   2825IN  NS  f.root-servers.net.
.   2825IN  NS  h.root-servers.net.
.   2825IN  NS  d.root-servers.net.
.   2825IN  NS  i.root-servers.net.
.   2825IN  NS  c.root-servers.net.
.   2825IN  NS  k.root-servers.net.
.   2825IN  NS  a.root-servers.net.
.   2825IN  NS  e.root-servers.net.
.   2825IN  NS  g.root-servers.net.
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

org.172800  IN  NS  d0.org.afilias-nst.org.
org.172800  IN  NS  a2.org.afilias-nst.info.
org.172800  IN  NS  b2.org.afilias-nst.org.
org.172800  IN  NS  b0.org.afilias-nst.org.
org.172800  IN  NS  a0.org.afilias-nst.info.
org.172800  IN  NS  c0.org.afilias-nst.info.
org.86400   IN  DS  21366 7 1 
E6C1716CFB6BDC84E84CE1AB5510DAC69173B5B2
org.86400   IN  DS  21366 7 2 
96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA
org.86400   IN  RRSIG   DS 8 1 86400 
2015051005 2015043004 48613 . 
CCXS9dvxUkQCVXzNYBnGgI4+9E0pRURKT5Bp7gBhTO28rQsoP64lbCxU 
/0R13vcKBxS1ANPZnOreayAjlNCrL4ME2/09pKaBY/2OjaGc61+11W1g 
+pggqcoxLOEdsp3Pg9oWVVDYNAmh3akVIMJIOjRGy3q3I7ntBhfjh0bf dZE=

;; Received 685 bytes from 192.228.79.201#53(b.root-servers.net) in 187 ms

example.org.86400   IN  NS  a.iana-servers.net.
example.org.86400   IN  NS  b.iana-servers.net.
example.org.86400   IN  DS  31589 8 1 
7B8370002875DDA781390A8E586C31493847D9BC
example.org.86400   IN  DS  31589 8 2 
3FDC4C11FA3AD3535EA8C1CE3EAF7BFA5CA9AE8A834D98FEE10085CF AEB625AA
example.org.86400   IN  RRSIG   DS 7 2 86400 
20150516154903 20150425144903 3213 org. 
F4xyrnEiyAh73FDVDCksE2gwPci27NyrDBOvAheul5LnaMyCg4PrWWly 
+vGTYbTv6A/OSS3Hc+1XdzvG39sN2fdGSBEXvGib1MVq0upC5dFA/RSu 
sB3CauiWON2zxIptGrDnGOS0DenYSzPP8wDghMeykr+k5FT6RuuDVAFr Uvg=

;; Received 335 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 38 ms

example.org.86400   IN  A   93.184.216.34
example.org.86400   IN  RRSIG   A 8 2 86400 
20150507130447 20150430112531 23014 example.org. 
o95kdPQLidVQavRj2zcvtJPzra2mQ4VdWPlnnGUkd+/Wvv9/AT7TRArc 
vjcdXhH7s9X0J6Jray7VA3SvqvEXixwqSbOUjS3WNXZ70pR0hz+9hAPl 
/t2uIMDpIUFWSeZkBBU2Q+nPZ6z9zCi6f7FpRNFaV4CXN9gTrU/g9mXb ZiI=

example.org.172800  IN  NS  a.iana-servers.net.
example.org.172800  IN  NS  b.iana-servers.net.
example.org.172800  IN  RRSIG   NS 8 2 172800 
20150507230256 20150430112531 23014 example.org. 
RPb4E38QRr2myhjs88BsIE3RhApL4TgJv+7rEgaMvxUYOs6g8nasKO2N 
NbuJMRvJaTSEpQHlq6YpEMmhLgXKBk+szv964RAwj/zZOjgEh816ORyZ 
GdA1cnvtHp7vFcRnQgGRsPTWFrYKpa22zimfi87fK/OBSPjONf4pGk/s TEc=

;; Received 534 bytes from 199.43.133.53#53(b.iana-servers.net) in 174 ms



signature.asc
Description: OpenPGP digital signature

Re: TxRep $msgscore warning

[Kevin A. McGrail]

On 4/30/2015 9:56 AM, Birta Levente wrote:

Spamassassin called through amavisd as a content filter in postfix.

I just see, if I send an emtpy mail (just the subject is "test") 
through my server, fire the warning.
The mail is sent as an authenticated user, in amavis I have special 
policy bank for authenticated users.

But the warnings I saw when mails coming from outside too.

OK, well that error means msgscore isn't defined in check_reputation and 
there is at least one call to that function without a message score such 
as this call with only 6 parameters (msgscore is #8)


my $msg_rep = $self->check_reputations($pms, 'MSG_ID', $msg_id, undef, 
$date, undef);


Overall, I checked and we use spamc/spamd and have never seen the 
scenario you are having.


My thoughts are to have you edit your TxRep.pm, restart amavisd and look 
at the logs for the next time it happens and give us the log out from 
the dbg and the errors.


Not sure how you turn on debugging with amavis so hoping someone on list 
can say how to turn on --debug=TxRep so we can log the TxRep log issues?


Can you add this block of code above line 1386 in the current TxRep.pm?

  {
#Bug 7164, trying to find out reason for these: _WARN: Use of 
uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.

no warnings;

dbg("TxRep: Parameters: self: $self storage: $storage pms: $pms, 
key: $key, id: $id, ip: $ip, signedby: $signedby, msgscore: $msgscore");

dbg("TxRep: weight: $weight");
  }


Here's more detail about where it needs to be:

sub check_reputation {
###
  my ($self, $storage, $pms, $key, $id, $ip, $signedby, $msgscore) = @_;

  my $delta  = 0;
  my $weight = ($key eq 'MSG_ID')? 1 : 
eval('$pms->{main}->{conf}->{txrep_weight_'.lc($key).'}');


--> Block here

  if (defined $weight && $weight) {


regards,
KAM

Re: AWL defeating my SPAM classification

[Benny Pedersen]

Matus UHLAR - fantomas skrev den 2015-04-30 12:55:


no, it's the "dig" command that does the trace, not the nameserver.
This says nothing about your nameserver configuration, and it can't 
since

nameserver does not provide that info.


dig respects resolv.conf with nameserver 127.0.0.1

try it :)

dig @8.8.8.8 +trace example.org

Re: AWL defeating my SPAM classification

[Benny Pedersen]

Tom Robinson skrev den 2015-04-30 04:35:

Finally that makes sense. I will add the forwarding in as per the 
documentation.


remove forwarding is safe, only use forward dns on zones you self build 
or have rsync access to

Re: AWL defeating my SPAM classification

[Benny Pedersen]

Tom Robinson skrev den 2015-04-30 04:14:


Actually, looking for this config I can't seem to find it. My
spamassassin is linked in with qmail
using qmail-scanner-queue.pl. That script looks in
/home/qscand/.spamassassin/user_prefs but I also
have configs in /etc/mail/spamassassin. What am I looking for exactly?


dig +trace apache.org
dig +trace google.com

did you see route on how dns treverse nameservers ?

when you use forwards in the chain it ignores this, and thus others use 
your free limit on blacklists, and it will in some time begin to give no 
results, leading to see diff problems in awl since its recorded before 
with a diff spam score on the same ips


to solve it completely remove ALL forwards in your nameserver, and ONLY 
use forward pr zone as needed, thus do not use forward in options 
section in named.conf with is global fault :=)


i have seen domains that blocked my ips in there acl for being for them 
a dynamic ip, all thay got back was that it was for them impossible to 
send more mail until that was resolved


my ips was ripe listed in seperate, if admins had checked this it was 
clearly not a dynamic ip, and problem had not arrised for them


in resolv.conf use nameserver 127.0.0.1, and configure your dns server 
to only listen on 127.0.0.1 or if needed lan interfaces, no listning on 
public ips

Re: AWL defeating my SPAM classification

[Dave Pooser]

On 4/30/15, 5:55 AM, "Matus UHLAR - fantomas"  wrote:

>no, it's the "dig" command that does the trace, not the nameserver.
>This says nothing about your nameserver configuration, and it can't since
>nameserver does not provide that info.

I stand corrected-- I had tested on another machine that used a forwarding
server and had seen different results that did NOT include the root
servers (it queried the local router, then the Verizon forwarder, then
uribl directly) -- but that was probably either because Verizon does DNS
hijacking or a difference between the dig implementations on MacOS and
Ubuntu. Sorry for the noise!


-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com

Re: TxRep $msgscore warning

[Birta Levente]

On 30/04/2015 16:35, Joe Quinn wrote:

On 4/30/2015 9:22 AM, Joe Quinn wrote:

On 4/30/2015 9:10 AM, Birta Levente wrote:

On 30/04/2015 15:55, Joe Quinn wrote:

On 4/30/2015 7:09 AM, Birta Levente wrote:

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm 
line 1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

We know about the issue but have been having trouble reproducing it 
in a way we can experiment on to find where the bug is.


Can you generate a reproduction or post samples and relevant txrep 
rows to this bug?

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164


I will, but only next week.
What you mean in samples? Full email with body or just headers?

Full email would be best. It can be something contrived if it can 
reproduce the issue on your system. And since we're not sure what 
causes it, your TxRep configuration and any rows of your txrep table 
that match will be helpful too.


The warning should be harmless and won't affect your mail flow in the 
meantime.
Can you also include how you call spamassassin? Are you using built-in 
glue from a milter like MD, or spamassassin, or spamc/spamd?


Spamassassin called through amavisd as a content filter in postfix.

I just see, if I send an emtpy mail (just the subject is "test") through 
my server, fire the warning.
The mail is sent as an authenticated user, in amavis I have special 
policy bank for authenticated users.

But the warnings I saw when mails coming from outside too.

--
   Levi

Re: TxRep $msgscore warning

[Joe Quinn]

On 4/30/2015 9:22 AM, Joe Quinn wrote:

On 4/30/2015 9:10 AM, Birta Levente wrote:

On 30/04/2015 15:55, Joe Quinn wrote:

On 4/30/2015 7:09 AM, Birta Levente wrote:

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 
1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

We know about the issue but have been having trouble reproducing it 
in a way we can experiment on to find where the bug is.


Can you generate a reproduction or post samples and relevant txrep 
rows to this bug?

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164


I will, but only next week.
What you mean in samples? Full email with body or just headers?

Full email would be best. It can be something contrived if it can 
reproduce the issue on your system. And since we're not sure what 
causes it, your TxRep configuration and any rows of your txrep table 
that match will be helpful too.


The warning should be harmless and won't affect your mail flow in the 
meantime.
Can you also include how you call spamassassin? Are you using built-in 
glue from a milter like MD, or spamassassin, or spamc/spamd?

Re: TxRep $msgscore warning

[Joe Quinn]

On 4/30/2015 9:10 AM, Birta Levente wrote:

On 30/04/2015 15:55, Joe Quinn wrote:

On 4/30/2015 7:09 AM, Birta Levente wrote:

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 
1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

We know about the issue but have been having trouble reproducing it 
in a way we can experiment on to find where the bug is.


Can you generate a reproduction or post samples and relevant txrep 
rows to this bug?

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164


I will, but only next week.
What you mean in samples? Full email with body or just headers?

Full email would be best. It can be something contrived if it can 
reproduce the issue on your system. And since we're not sure what causes 
it, your TxRep configuration and any rows of your txrep table that match 
will be helpful too.


The warning should be harmless and won't affect your mail flow in the 
meantime.

Re: TxRep $msgscore warning

[Birta Levente]

On 30/04/2015 15:55, Joe Quinn wrote:

On 4/30/2015 7:09 AM, Birta Levente wrote:

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 
1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

We know about the issue but have been having trouble reproducing it in 
a way we can experiment on to find where the bug is.


Can you generate a reproduction or post samples and relevant txrep 
rows to this bug?

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164


I will, but only next week.
What you mean in samples? Full email with body or just headers?

--
   Levi

Re: TxRep $msgscore warning

[Joe Quinn]

On 4/30/2015 7:09 AM, Birta Levente wrote:

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

We know about the issue but have been having trouble reproducing it in a 
way we can experiment on to find where the bug is.


Can you generate a reproduction or post samples and relevant txrep rows 
to this bug?

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7164

TxRep $msgscore warning

[Birta Levente]

Hi

I saw the bug report about TxRep warning:
_WARN: Use of uninitialized value $msgscore in addition (+) at 
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/TxRep.pm line 1415.

_WARN: Use of uninitialized value $msgscore in subtraction (-)


I just wonder if there is any workaroung for that or if exists any 
effect of this warning?


Thanks

--
   Levi

Re: AWL defeating my SPAM classification

[Matus UHLAR - fantomas]

On 30/04/15 09:56, Marieke Janssen wrote:

  0.0 URIBL_BLOCKED  ADMINISTRATOR NOTICE: The query to URIBL was 
blocked.
 See
 
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
  for more information.
 [URIs: world-plants.ru]

You are blocked, This probably means you are using either public
nameservers or do too much queries.  Running a dedicated nameserver on
localhost (dnsmasq,bind,unbound,whatever) can solve this (and besides
that, it speeds things up).  If you fix this chances are you get scores
high enough to compensate/correct AWL.


On 30.04.15 12:10, Tom Robinson wrote:

I have the mail server and a separate name server set up in a DMZ. The name
server already runs as a caching nameserver but does forwarding to our ISP. 
I'm not sure how the non-caching works to eliminate this problem.  Is it

correct that currently, because I'm forwarding, the DNSBL query is denied
because the DNSBL server thinks I'm the ISP making a query?  Sorry, I'm not
understanding the mechanism.


when you are forwarding, your nameserver asks forwarders for the data.
The DNSBL server apparently block your forwarders because they make too many
queries.


If bind is going to forward lookups for DNSBL servers to a null list, will
the cache have a record to look up at all?



e.g.
/* Disable forwarding for DNSBL queries */
zone "multi.uribl.com" { type forward; forward first; forwarders {}; };
zone "dnsbl.sorbs.net" { type forward; forward first; forwarders {}; };

Does this rely on the caching namesever having already looked up and cached
the DNSBL servers?


it will iterate the usual way without forwarders - from root servers etc.



BTW, I do have rbldnsd set up on the caching nameserver in my DMZ. Is that
useful in any way to resolve this issue?


you can set up forwarding to the rbldnsd server, if it contains proper
zones.

--
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759

Re: AWL defeating my SPAM classification

[Reindl Harald]

Am 30.04.2015 um 12:55 schrieb Matus UHLAR - fantomas:

On 4/30/15, 12:16 AM, "Tom Robinson"  wrote:

BTW, where can I see the results of my configuration changes? It
would be
nice to confirm that my
changes have rectified the situation.


On 30.04.15 01:38, Dave Pooser wrote:

On the server (via SSH or console) use the +trace argument to dig, and
then look for lines starting with ';;':

postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
;; global options: +cmd
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms

So you can see that my mail server is querying its local DNS resolver,
which is querying the root servers and then working its way down to the
appropriate uribl.com server. In your case your actual IPs will be
different, but the pattern should still hold.


no, it's the "dig" command that does the trace, not the nameserver.
This says nothing about your nameserver configuration, and it can't since
nameserver does not provide that info


correct because the nameserver of the machine below *for sure* does not 
recursion but is a forwarder to a local cache which don't appear


[harry@srv-rhsoft:~]$ dig +trace example.com.multi.uribl.com | grep ';;'
;; global options: +cmd
;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
;; Received 751 bytes from 202.12.27.33#53(m.root-servers.net) in 43 ms
;; Received 698 bytes from 192.41.162.30#53(l.gtld-servers.net) in 186 ms
;; Received 544 bytes from 94.228.131.217#53(p.icudp.net) in 32 ms
;; Received 90 bytes from 184.73.199.129#53(ee.uribl.com) in 173 ms



signature.asc
Description: OpenPGP digital signature

Re: AWL defeating my SPAM classification

[David Jones]

>On the server (via SSH or console) use the +trace argument to dig, and
>then look for lines starting with ';;':

>postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
>;; global options: +cmd
>;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
>;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
>;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
>;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
>;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms

>So you can see that my mail server is querying its local DNS resolver,
>which is querying the root servers and then working its way down to the
>appropriate uribl.com server. In your case your actual IPs will be
>different, but the pattern should still hold.

dig +trace always does a full root server lookup so it's not showing the same
path that the /etc/resolv.conf will take.
He will have to run a regular query and see if he gets back 127.0.0.1.  If so,
then the current resolv.conf path is still being blocked.

>--
>Dave Pooser
>Cat-Herder-in-Chief, Pooserville.com

Re: AWL defeating my SPAM classification

[Matus UHLAR - fantomas]

On 4/30/15, 12:16 AM, "Tom Robinson"  wrote:

BTW, where can I see the results of my configuration changes? It would be
nice to confirm that my
changes have rectified the situation.


On 30.04.15 01:38, Dave Pooser wrote:

On the server (via SSH or console) use the +trace argument to dig, and
then look for lines starting with ';;':

postmstr@smtp:~$ dig +trace example.com.multi.uribl.com | grep ';;'
;; global options: +cmd
;; Received 913 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
;; Received 760 bytes from 199.7.91.13#53(d.root-servers.net) in 48 ms
;; Received 707 bytes from 192.54.112.30#53(h.gtld-servers.net) in 124 ms
;; Received 553 bytes from 54.149.125.143#53(o.icudp.com) in 74 ms
;; Received 206 bytes from 52.68.34.21#53(gg.uribl.com) in 147 ms

So you can see that my mail server is querying its local DNS resolver,
which is querying the root servers and then working its way down to the
appropriate uribl.com server. In your case your actual IPs will be
different, but the pattern should still hold.


no, it's the "dig" command that does the trace, not the nameserver.
This says nothing about your nameserver configuration, and it can't since
nameserver does not provide that info.

--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease