Module submissions, reviews, etc.

2014-06-13 Thread Philip A. Prindeville 
What's the best place to get a module reviewed for inclusion into a future 
version of SA, or to discuss possible core changes to SA?

Thanks,

-Philip

Re: Magical mystery colon

2010-02-01 Thread Philip A. Prindeville 
On 02/01/2010 05:35 AM, Mark Martinec wrote:
> On Saturday January 30 2010 21:16:01 Philip A. Prindeville wrote:
>   
>> Also, how come the eval block:
>>   unless (eval "require $thing") {...}
>> doesn't contain a terminating ';', i.e.:
>> eval "require $thing;" instead?
>> 
> It is not needed. It is an 'eval EXPR', not 'eval BLOCK'.
> A semicolon in perl is a statement separator, not a statement terminator.
>
>   Mark
>   

Ok.  No one knows why I'm seeing the warnings from the cron job, however?

Re: Magical mystery colon

2010-01-31 Thread Philip A. Prindeville 
On 01/30/2010 12:24 PM, Karsten Bräckelmann wrote:
> On Sat, 2010-01-30 at 12:16 -0800, Philip A. Prindeville wrote:
>   
>> I ran "yum update" on my FC11 machine a couple of days ago, and now I'm
>> getting nightly cron errors:
>> 
> Would be nice and maybe even helpful to know, what command(s) that cron
> job executes, don't you think? :)
>   

Well, this is unmodified Fedora, so the same as every other Fedora box:

10 4 * * * root /usr/share/spamassassin/sa-update.cron 2>&1 | tee -a 
/var/log/sa-update.log


And that script contains:


#!/bin/bash
# *** DO NOT MODIFY THIS FILE ***
#
# /etc/mail/spamassassin/channel.d/*.conf
# Place files here to add custom channels.
#

# list files in a directory consisting only of alphanumerics, hyphens and
# underscores
# $1 - directory to list
# $2 - optional suffix to limit which files are selected
run_parts_list() {
if [ $# -lt 1 ]; then
echo "ERROR: Usage: run_parts_list " > /dev/stderr
exit 1
fi
if [ ! -d "$1" ]; then
echo "ERROR: Not a directory: $1" > /dev/stderr
exit 1
fi

if [ -d "$1" ]; then
if [ -n "$2" ]; then
find_opts='-name *'$2
fi
find -L $1 -mindepth 1 -maxdepth 1 -type f $find_opts | sort -n
fi
}

# Proceed with sa-update if spam daemon is running or forced in 
/etc/sysconfig/sa-update
unset SAUPDATE
[ -f /etc/sysconfig/sa-update ] && . /etc/sysconfig/sa-update
for daemon in spamd amavisd; do
/sbin/pidof $daemon >& /dev/null
[ $? -eq 0 ] && SAUPDATE=yes
done
[ -f /var/run/mimedefang.pid ] && SAUPDATE=yes

# Skip sa-update if daemon not detected
[ -z "$SAUPDATE" ] && exit 0

# sa-update must create keyring
if [ ! -d /etc/mail/spamassassin/sa-update-keys ]; then
sa-update
fi

# Initialize Channels and Keys
CHANNELLIST=""
KEYLIST=""
# Process each channel defined in /etc/mail/spamassassin/channel.d/
for file in $(run_parts_list /etc/mail/spamassassin/channel.d/ .conf); do 
# Validate config file
PREFIXES="CHANNELURL KEYID BEGIN"
for prefix in $PREFIXES; do
if ! grep -q "$prefix" $file; then
echo "ERROR: $file missing $prefix"
exit 255
fi
done
. $file
#echo "CHANNELURL=$CHANNELURL"
#echo "KEYID=$KEYID"
CHANNELLIST="$CHANNELLIST $CHANNELURL"
KEYLIST="$KEYLIST $KEYID"
sa-update --import $file
done

# Sleep random amount of time before proceeding to avoid overwhelming the 
servers
sleep $(expr $RANDOM % 7200)

unset arglist
# Run sa-update on each channel, restart spam daemon if success
for channel in $CHANNELLIST; do
arglist="$arglist --channel $channel"
done
for keyid in $KEYLIST; do
arglist="$arglist --gpgkey $keyid"
done
/usr/bin/sa-update $arglist
if [ $? -eq 0 ]; then
/etc/init.d/spamassassin condrestart > /dev/null
[ -f /etc/init.d/amavisd ] && /etc/init.d/amavisd condrestart > /dev/null
[ -f /var/run/mimedefang.pid ] && /etc/init.d/mimedefang reload > /dev/null
fi



>   
>> plugin: failed to parse plugin (from @INC): syntax error at (eval 84) line 
>> 1, near "require Mail::SpamAssassin:"
>>
>> plugin: failed to parse plugin (from @INC): syntax error at (eval 148) line 
>> 1, near "require Mail::SpamAssassin:"
>>
>> I've seen this message periodically, but never figured out what
>> generated it.
>>
>> Can someone set me straight?  It of course doesn't mention a file, so
>> it's hard to know where it's coming from.
>> 
>

Magical mystery colon

2010-01-30 Thread Philip A. Prindeville 
I ran "yum update" on my FC11 machine a couple of days ago, and now I'm
getting nightly cron errors:

plugin: failed to parse plugin (from @INC): syntax error at (eval 84) line 1, 
near "require Mail::SpamAssassin:"

plugin: failed to parse plugin (from @INC): syntax error at (eval 148) line 1, 
near "require Mail::SpamAssassin:"

I've seen this message periodically, but never figured out what generated it.

Can someone set me straight?  It of course doesn't mention a file, so it's hard 
to know where it's coming from.

Also, how come the eval block:


foreach $thing (qw(Anomy::HTMLCleaner Archive::Zip Digest::SHA1 
HTML::Parser HTML::TokeParser IO::Socket IO::Stringy MIME::Base64 MIME::Tools 
MIME::Words Mail::Mailer Mail::SpamAssassin Net::DNS Unix::Syslog )) {
unless (eval "require $thing") {
printf("%-30s: missing\n", $thing);
next;
}

doesn't contain a terminating ';', i.e.:

eval "require $thing;" instead?

Thanks,

-Philip

Holding yahoo!'s feet to the fire

2009-12-07 Thread Philip A. Prindeville 
Some good news... possibly.

I finally complained to ARIN (for the 4th time) that the contact information 
for the Inktomi address blocks was incorrect, as Inktomi hasn't existed as a 
corporate (and legal) entity for some time... it was acquired by Yahoo! 3 years 
ago, and their address blocks have all been repurposed for Yahoo! server 
infrastructure and as such should reflect that reality.

So ARIN flagged the address block registry information as INVALID, and will ask 
the Yahoo contact person (Joan Luster) to address this issue next time they are 
in communication with her.

Why is this useful?

Well, every time I personally report an issue with them, I get the very 
annoying auto-reply that says:


> Once you have identified the IP address, you can conduct an IP lookup to
> determine which ISP provides this person with Internet access. One such 
> lookup tool you may want to try is:
>
>http://www.arin.net/whois/
>
> You can then attempt to contact that ISP to report any abuse activities 
> occurring within their service.
>   

which raises my blood pressure, because ARIN whois indicates they *are* the 
owner of that netblock (as Inktomi).

The upshot is that the OrgID: and NetName: records will no longer be INKT and 
INKTOMI-NET-* respectively... so that gives them one less rock to hide under.

(And it's entirely possible their autoresponders are mistakenly keying off 
these particular record fields when doing prefiltering... giving them the 
benefit of the doubt.)

We'll see how it goes, and I'll try to keep the list current.

Keep your fingers crossed.

-Philip

Re: Undisclosed recipients :; -- again

2009-12-02 Thread Philip A. Prindeville 
On 11/30/2009 03:15 AM, Matus UHLAR - fantomas wrote:
> On 27.11.09 14:04, Philip A. Prindeville wrote:
>   
>> for the ruleset:
>> 
>   
>> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
>> 
> just FYI, sendmail can be configured to do different things when To: is
> missing - there's sendmail option NoRecipientAction, configured by setting
> confNO_RCPT_ACTION m4 directive. The default value is "none" but e.g. Debian
> was setting it to "add-to-undisclosed" which causes MISSING_HEADERS not
> hitting (only from milter, which appears to be called before the headers are
> "fixed").
>
> Maybe you should look at your MTA's configuratioon options if it doesn't
> cause different rules hitting/not hitting, e.g. sendmail adds Date: and
> Message-Id headers which cause MISSING_DATE and MISSING_MID. I was not able
> to find how disable this behaviour in sendmail.
>
>   

Odd.  This is on FC11:

[r...@mail mail]# grep confNO_RCPT_ACTION /usr/share/sendmail-cf/*/*
/usr/share/sendmail-cf/m4/proto.m4:_OPTION(NoRecipientAction, 
`confNO_RCPT_ACTION', `none')
[r...@mail mail]# grep NoRecipientAction *.cf
sendmail.cf:#O NoRecipientAction=none
submit.cf:#O NoRecipientAction=none
[r...@mail mail]# 

Added:

define(`confNO_RCPT_ACTION', `none')dnl


to the sendmail.mc, made sendmail.cf, did a service restart... will see what 
happens.

I can't remember: if an option is commented, is that showing us the default 
value typically?

-Philip

Re: Undisclosed recipients :; -- again

2009-11-27 Thread Philip A. Prindeville 

John Hardin wrote:

On Fri, 27 Nov 2009, Philip A. Prindeville wrote:


header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/

Just how do I go about figuring out what the "To:raw" value is (for 
example)?


  header  __TO_RAW  To:raw =~ /.+/

If you're analyzing something that may have multiple occurrences, 
you'll need a tflags multiple:


  body__ALL_BODY  /.+/
  tflags  __ALL_BODY  multiple



Interesting, thanks:

[31209] dbg: rules: ran header rule __TO_RAW ==> got hit: " undisclosed 
recipients: ;_"


wondering why it contains the leading space, and what the trailing 
underscore is for...


On a side node, I never figured out why I see:

[31209] warn: plugin: failed to parse plugin (from @INC): syntax error at (eval 43) line 
1, near "require Mail::SpamAssassin:"

This seems to be a known issue.  What's the fix?

Re: Undisclosed recipients :; -- again

2009-11-27 Thread Philip A. Prindeville 

John Hardin wrote:

On Mon, 23 Nov 2009, LuKreme wrote:

On Nov 23, 2009, at 12:05, Philip Prindeville 
 wrote:



I want to block all messages that I'm getting that have:

To: undisclosed recipients: ;


undisclosed recipients is used for Bcc: mail

I used it all the time. And you WILL 'block' legitimate mail.


Granted, but in metas such a test can be useful:

http://ruleqa.spamassassin.org/?rule=%2FTO_NO&srcpath=jhardin



Speaking of tests, I saved out some messages that should have matched my 
rule but didn't into files, and ran them against spamassassin as:


spamassassin -D < /tmp/emails/XXX.eml

and I saw:

[28655] dbg: rules: ran header rule __L_UNDISCLOSED2 ==> got hit: "negative 
match"


for the ruleset:


header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
header __L_UNDISCLOSED2 Cc =~ /^$/
meta L_UNDISCLOSED  (__L_UNDISCLOSED1 && __L_UNDISCLOSED2)
describe L_UNDISCLOSED  To: list is meaningless and no Cc:
score L_UNDISCLOSED 10.0



but didn't see __L_UNDISCLOSED1 match. Also, what does "negative match" 
mean? That it didn't match?


Lots of other rules (like __L_UNDISCLOSED1) didn't match, but I didn't 
see debug for those...


Just how do I go about figuring out what the "To:raw" value is (for 
example)?


Thanks,

-Philip

More of a philosophical question

2009-11-11 Thread Philip A. Prindeville 
This isn't so much of a technical question as a policy one.

I get a lot of spam which looks like:

Return-Path: 
Received: from web.biz.mail.sk1.yahoo.com (web.biz.mail.sk1.yahoo.com 
[74.6.114.43])
by mail.redfish-solutions.com (8.14.3/8.14.3) with SMTP id nA8KXHbF007914
for ; Sun, 8 Nov 2009 13:33:23 -0700
Received: (qmail 77790 invoked by uid 60001); 8 Nov 2009 20:33:17 -
Message-ID: <223519.76757...@web.biz.mail.sk1.yahoo.com>
X-YMail-OSG: 
ITTxzA0VM1nOPGrQYX7tAeYtgFhkzLHYo.qDHS6MrLwhvvaHzfjqTAnctUdZXTeTR0y.mWitx7Ou0luQLKnF_GvxGk_gsyrhQiecygtXxr.GNWFkWrkP57qwERbf1Af794h0lXoiyXseb3DTTSqteQCJJ4R8cnSOGFAQavXbUa1QwMHI24mWQEyMF4VkVtpK30oRxlaHVfyGuTXo9pDtTd3mfZScylE6lSYlZjaU8EFS8b8xILkwduj7dx_FW.i4q._BpZayBZY5A5rQb2y03bhl6aTzM9nfbFpY..dlKU7NJVZhLnPeDNRv8z3ZUCBQfsJCq2M5y9Os913jTPXpB1loucgEzfYocoVj6I081B.QNiRFwnUtANDRTHDyGogYeSccqeiSzPxhABGFEtTWY2D08epaNJbwPjU66HDWEjzzNUbzBXyRny0UzKp4HLBUX5tbKNJ8kbHotjEE7xtmcpzoqm.YpfEDl_9omvGsW1e7rThr60pemte_xsNIcarBts2PAXSgzJrZ8zveH287WUmL29olqa3kkksEeVIi4cFsYWNQgSuPqQXV6TLpim1VNZ8c_bzZ5J35fEiL1iJeDWndc.SFtUMwf2leifGkzwDYSrWxOmhux7a_.AC30.BaJQypPZx6YlCXVWlJ3PIIeP0O_.NLtkltfStJB_lS69d6vSh437.X25YQtDTOo3MxMqjNgPznHdmQZ4SFJtF9lfmcksrvoSlXDkiCwGl2qfo.Iuxuh0c.KyVqFlzdy8GgUQJpw9yPwB_aTG.kIs.8gIuUQ3AY3wkI0QEfDOWbqDN2Gr3uLzwvrJLo9UJ4HTDAni7dvTSnM2INbXq7YdCgpfBZ7_AhpLTvvXhY_Yu.aoLjLh1Ill2BwfLJGCZr3bNct0pTw2_o5FXrupA.1Pk3t04NhCaQ0Y0St36th.K7a7smbRBcZusdDeQewQ7l.kEf0i.2YTbqFLUyI4QJwhXs18Kj1g_SQf3shYJxhlHF6FvRqX88D6kLJjPspPvh4eC_XiYxBtaarV0ZXoBBVKUjSj04DP8RSrFZ1DBGT5s2Uz.ZUY78.ilZcXnhFt1Dz4JwjnG0a35n8xWOx6JbWTD5d25EDahowx340TjnAGyjlfxfzgdFPlaQC54EEbDZpvjU8fbah53jJkST2JdvVUEKivsflAEEU7Y5_l8LQzENtjAAYop8dpHadyQn1lAYzRwrpHF7ViBGMwd3gihfVZs_3onzYsoYsvwkNolkWORQcvbGWxFKfuQMJDL9Iaw4QKX0iIGErAWHIkWHnF6B48RFDMrGVyVrwjEhT7X50IKYbwK.EZid2Eme9x2ElFgATPBSmjhom14Ay9DuY77cJuY_MohirOKsbTgl3_nwv704SGy6.Vg.oAaEP29c8cOcMwXpzZDUeO0ZHXcIn9f7ujQlssq9EF4Yn79sQcgkBNeRMFAkLx_cx5Ez5a9rslAITdPSuHfK.X0YH3GAmV.ONy7VE9Uta5Tk4Z3JmjtHJ0AIrCIGy7ZonllVcF1nWkv4BA083jOSbsQqFBXtU5uOnhE-
Received: from [41.207.162.4] by web.biz.mail.sk1.yahoo.com via HTTP; Sun, 
08 Nov 2009 12:33:16 PST
X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.347.3
Date: Sun, 8 Nov 2009 12:33:16 -0800 (PST)
From: Evan Lawson 
Subject: Hello Dear Friend
To: undisclosed recipients: ;
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


And I report this to Yahoo!.  They then answer:



We understand your frustration in receiving unsolicited email. While we
investigate all reported violations against the Yahoo! Terms of Service
(TOS), in this particular case the message you received was not sent by
a Yahoo! Mail user.

Yahoo! has no control over activities outside its service, and therefore
we cannot take action. You may try contacting the sender's email
provider, by identifying the sender's domain and contacting the
administrator of that domain. The sender's provider should be in a
better position to take appropriate action against the sender's account.

which sounds to me like they are effectively admitting that they run an
Open Relay, which is against US law, as I remember.

It's also factually incorrect.  The message didn't originate outside of
their service, since the line "Received: ... via HTTP" is basically
meaningless.  HTTP isn't a mail protocol.  This tells me that the
message originated via a Webmail submission on their website, which
means that someone had to log in with credentials... which means that
(a) they do in fact have control over whether that user's credentials
get yanked or not, and (b) the message didn't originate outside of their
service.

This has been going on for 4 years, and I'm tired of their shirking
their responsibility.

We don't have a lot of users, so I'd be happy to blacklist Yahoo! until
they clean up their act... unfortunately a couple of correspondents to
this domain are Yahoo! users.

So what is the best course of action to take against Yahoo!?

I filed an IC3 complaint against them for passing phishing and operating
an Open Relay, but nothing came of it.

How has everyone else made their peace with this?

Thanks,

-Philip