Weird empty messages
Hi, We are seeing a trickle of weird empty messages. Here's a sample Sendmail log: May 8 11:33:31 colo3 sm-mta[1100]: t48FXPqL001100: from=ragland_rosell...@cttstone.com, size=18, class=0, nrcpts=1, msgid=8[10, proto=SMTP, daemon=MTA, relay=50-242-22-73-static.hfc.comcastbusiness.net [50.242.22.73] (may be forged) Note the size of 18 bytes. The entire message content consists of the single header: Message-ID: 8[10 and that's it! So, buggy ratware? Someone trying to exploit a vulnerable SMTP server? Bizarre... On one of our scanners: $ fgrep -c 'size=18,' /var/log/mail-daily/current.log 1993 (out of 459997 messages, so 0.4%) and: fgrep 'size=18,' /var/log/mail-daily/current.log | sed -e 's/.*msgid=//' -e 's/, .*//' | sort | uniq -c 199 0[10 202 1[10 182 2[10 209 3[10 188 4[10 196 5[10 212 6[10 226 7[10 193 8[10 191 9[10 Regards, Dianne.
Re: Weird empty messages
On 5/8/2015 11:46 AM, Dianne Skoll wrote: $ fgrep -c 'size=18,' /var/log/mail-daily/current.log We have apparently seen these for 54 days. Here's the first: Mar 17 05:12:00 intel1 sendmail[21710]: t2H9Bt6J021710: from=funemaf...@estroweb.com, size=18, class=0, nrcpts=3, msgid=5[10, proto=SMTP, daemon=MTA, relay=ip93-136.ibw.com [190.211.93.136] (may be forged) Haven't seen any get through our spam filters, though and they typically score really high (40+). Regards, KAM
Re: Weird empty messages
On Fri, 08 May 2015 13:14:56 -0400 Kevin A. McGrail kmcgr...@pccc.com wrote: Haven't seen any get through our spam filters, though and they typically score really high (40+). Yes, none have got through for us either... all scoring at least 15 or so. I'm just trying to figure out the motivation behind them (or indeed if it's a bug on the part of spamware authors.) Regards, Dianne.
Re: Weird empty messages
Massively broken ratware, safely rejectable with a MTA header rule detecting /^Message-ID: \\d\[\d/ On 08.05.2015 17:46, Dianne Skoll wrote: Hi, We are seeing a trickle of weird empty messages. Here's a sample Sendmail log: May 8 11:33:31 colo3 sm-mta[1100]: t48FXPqL001100: from=ragland_rosell...@cttstone.com, size=18, class=0, nrcpts=1, msgid=8[10, proto=SMTP, daemon=MTA, relay=50-242-22-73-static.hfc.comcastbusiness.net [50.242.22.73] (may be forged) Note the size of 18 bytes. The entire message content consists of the single header: Message-ID: 8[10 and that's it! So, buggy ratware? Someone trying to exploit a vulnerable SMTP server? Bizarre... On one of our scanners: $ fgrep -c 'size=18,' /var/log/mail-daily/current.log 1993 (out of 459997 messages, so 0.4%) and: fgrep 'size=18,' /var/log/mail-daily/current.log | sed -e 's/.*msgid=//' -e 's/, .*//' | sort | uniq -c 199 0[10 202 1[10 182 2[10 209 3[10 188 4[10 196 5[10 212 6[10 226 7[10 193 8[10 191 9[10 Regards, Dianne.
Re: check_rbl_txt and multiple elements
On Fri, May 08, 2015 at 01:55:47PM +0100, RW wrote: [Plugin::ASN] The plugin generates psuedo-headers you can run tests against. X-ASN and X-ASN-Route contain _ASN_ and _ASNCIDR_ respectively. Thank you very much! This is indeed easy to test. It would be great if this piece of information would find its way into the Pod text of ASN.pm (at least if it's meant as a stable interface).
Re: 3.4.1 Key issues: sa_compile test failures and txrep.pm uninitialized issues
On 6 May 2015, at 20:57, Kevin A. McGrail wrote: Hello SpamAssassin Users and Developers, I wanted to take a moment to provide my $0.02 on two in the wild issues with 3.4.1 that I've heard a lot about in the past few days: The first in the wild issue has been some failures on sa_compile.t. These errors are confirmed as solely test errors and do not indicate an issue with using compiled rules in production. You can see more about the issue on https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7181 and https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7005. If you are affected by this issue, an easy work around is to rename the re2c executable during cpan installations or make tests so that the sa_compile.t test is skipped. I would (for obvious reasons) add to that list https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7188 which is also worked around by skipping the test OR by applying the patch attached to the bug. It appears that this bug has been around a long time and went unnoticed because the bulk of people using /opt/$DIR as a prefix for build/test are MacPorts users and MacPorts doesn't run tests by default or ever test as root, so the most serious risk (damaging the operational rule config directories under /{etc,var}/opt/) is avoided. As with the other sa_compile.t issue, I don't see that as any sort of emergency issue. The tests implemented in that file are more for developers than for end-users in that they answer is rule compilation broken in general? without answering is my build able to compile rules?
Re: Weird empty messages
On 8 May 2015, at 11:46, Dianne Skoll wrote: Hi, We are seeing a trickle of weird empty messages. Here's a sample Sendmail log: May 8 11:33:31 colo3 sm-mta[1100]: t48FXPqL001100: from=ragland_rosell...@cttstone.com, size=18, class=0, nrcpts=1, msgid=8[10, proto=SMTP, daemon=MTA, relay=50-242-22-73-static.hfc.comcastbusiness.net [50.242.22.73] (may be forged) Note the size of 18 bytes. The entire message content consists of the single header: Message-ID: 8[10 and that's it! So, buggy ratware? Someone trying to exploit a vulnerable SMTP server? Bizarre... A blast from the past! Yes, it's buggy ratware. I haven't seen those in volume since ~2007. I believe the CBL treats that as a signature so if you're using it (or Spamhaus Zen) ahead of SA, you should see very few of those unless the senders have figured out how to hide from CBL detection.
Re: check_rbl_txt and multiple elements
On 5/8/2015 7:29 AM, Marc Andre Selig wrote: Questions: Why does process_dnsbl_set() join the elements of TXT records directly, instead of separating them with something? Is there any chance of having the old behaviour restored in official releases, or at least having some separation character in there? From off-list discussions, here's the answer from Mark: It would break SPF, DKIM, ADSP and DMARC. Plugin/AskDNS.pm: # RFC 5518: If the RDATA in a TXT record contains multiple # character-strings (as defined in Section 3.3 of [RFC1035]), # the code handling such reply from DNS MUST assemble all of these # marshaled text blocks into a single one before any syntactical # verification takes place. # The same goes for RFC 4408 (SPF), RFC 4871 (DKIM), RFC 5617 (ADSP), # draft-kucherawy-dmarc-base (DMARC), ... Regards, KAM
Re: check_rbl_txt and multiple elements
On Fri, 8 May 2015 13:29:36 +0200 Marc Andre Selig wrote: Is there a better way to do what I want? (I know about Plugin::ASN, of course, but IIUC it can only be used for tagging, not for assigning direct scores?) The plugin generates psuedo-headers you can run tests against. X-ASN and X-ASN-Route contain _ASN_ and _ASNCIDR_ respectively.
check_rbl_txt and multiple elements
Dear list members, upgrading to Debian Jessie has brought SpamAssassin 3.4.0 to a private server of mine. For its particular use case, I like to directly assign scores to autonomous systems whose owners provide snowshoe spamming services. (I realize this strategy may be less useful for large mail hosts, but for this system, it works perfectly.) Unfortunately, this breaks in 3.4.0. I use rules such as these: header __LOCAL_ASN eval:check_rbl_txt('asn-lastexternal', 'asn.routeviews.org') describe __LOCAL_ASN Successful ASN lookup from routeviews.org tflags __LOCAL_ASN net header LOCAL_SPAMMER_BADISP eval:check_rbl_sub('asn-lastexternal', '4321') describe LOCAL_SPAMMER_BADISP AS4321 (Bad ISP, Inc.) scoreLOCAL_SPAMMER_BADISP 3 [... and some more check_rbl_sub tests ...] The problem is that asn.routeviews.org returns ASN data as TXT records in this format: 4321 82.200.196.0 24 Up to 3.3.2, SpamAssassin made this available to check_rbl_sub as-is, so the rule given above worked. 3.4.0 however has the following in Dns.pm (and it's still identical in the nightlies distributed for mass-check): sub process_dnsbl_set { [...] my $rdatastr = $answer-UNIVERSAL::can('txtdata') ? join('',$answer-txtdata) : $answer-rdatastr; As a result, the record given above becomes 432182.200.196.024 which is impossible to parse (it could be AS 43218 with IP range 2.200.196.0/24, or AS 4321 with IP range 82.200.196.0/24, or even AS 432 with IP range 182.200.196.0/24). Patching that line to join with a space (join(' ', $answer-txtdata)...) makes my immediate problem go away, provided that I now look for '^54321 ' instead of '54321' in check_rbl_sub(). Questions: Why does process_dnsbl_set() join the elements of TXT records directly, instead of separating them with something? Is there any chance of having the old behaviour restored in official releases, or at least having some separation character in there? Is there a better way to do what I want? (I know about Plugin::ASN, of course, but IIUC it can only be used for tagging, not for assigning direct scores?) Full patch appended (there are two more similar cases, one of which is merely cosmetic). Regards Marc --- Dns.pm.orig 2015-01-31 19:08:37.0 + +++ Dns.pm 2015-05-08 09:00:12.082711483 + @@ -174,7 +174,7 @@ # txtdata returns a non- zone-file-format encoded result, unlike rdatastr; # avoid space-separated RDATA character-string fields if possible, # txtdata provides a list of strings in a list context since Net::DNS 0.69 -$log = join('',$answer-txtdata); +$log = join(' ',$answer-txtdata); local $1; $log =~ s{ (?! [(\[] ) (https? : // \S+)}{$1}xgi; } else { # assuming $answer-type eq 'A' @@ -219,7 +219,7 @@ # avoid space-separated RDATA character-string fields if possible, # txtdata provides a list of strings in a list context since Net::DNS 0.69 # - my $rdatastr = $answer-UNIVERSAL::can('txtdata') ? join('',$answer-txtdata) + my $rdatastr = $answer-UNIVERSAL::can('txtdata') ? join(' ',$answer-txtdata) : $answer-rdatastr; if (defined $qname defined $rdatastr) { my $qclass = $question-qclass; @@ -288,7 +288,7 @@ # avoid space-separated RDATA character-string fields if possible, # txtdata provides a list of strings in a list context since Net::DNS 0.69 # - my $rdatastr = $answer-UNIVERSAL::can('txtdata') ? join('',$answer-txtdata) + my $rdatastr = $answer-UNIVERSAL::can('txtdata') ? join(' ',$answer-txtdata) : $answer-rdatastr; while (my ($subtest, $rule) = each %{ $self-{dnspost}-{$set} }) {