Re: Spam messages bypassing SA
Jeff Mincy wrote: > I agree with everything you wrote but only when bayes autolearning is > turned off. Bayes learning holds an exclusive lock to the bayes > database particularly during expiration. But the example was calling spamc. Bayes autolearning would be occuring in the spamd side of things. The spamc shouldn't need to know about it. The spamd side worries about that. That is rather the entire point of using the client-server model. Otherwise one would simply run the full perl spamassassin there instead. (There are other reasons for the client server too. And yet more for running the full perl spamassassin inline. There is no canonical correct way.) For my personal mail I run the full perl spamassassin. For mailing lists I run it through spamc-spamd. And as John noted it is much better to run sa-learn --expire as a separate process, probably cron driven, and not inline with the SA run. > If spamc does bayes autolearning and starts an expiration then other > spamc runs for that user will be locked out of bayes. At some point > you start getting timeouts at different points in the email delivery > chain. Any time supply (spamd) can't keep up with demand (spamc) there may be timeouts and other failures. The question is where might those occur. In the suggested recipe a timeout between spamc and spamd would cause the spamc to exit with EX_TEMPFAIL (75) which would cause procmail to exit the same which would cause the MTA to requeue and retry the message later. For spamc-spamd use I pump the mail off through spamc and let spamd queue and process as fast as it can. In my environment I am not experiencing timeouts. But if for some reason the resources of supply did not keep up with demand then the message would simply queue for retry later when resources may be available. If the system was overloaded then that is about the best that can be done anyway. If that happened often then increasing the compute resources on the spamd side would allow it to keep up better. Serializing spamc will definitely give spamd plenty of time between messages so that the system won't be overloaded. But if the system is dedicated to handling mail and anti-spam then it won't be able to be highly utilized. Running more in parallel will usually utilize resources more efficiently. In my environment spamc and spamd are on different systems. Therefore making use of parallel compute resources is a good thing. But if in your environment everything happens on one single system then serialization may be best. It is your judgement call and every environment is different. > I have a separate sa-learn (or spamc -L) procmail recipe that has a > serialization lock. I run sa-learn --expire from cron. I run spamc --learntype=spam otherwise using a different invocation not involving procmail. Bob
Re: procmail (was Re: Spam messages bypassing SA)
On Oct 28, 2014 at 07:40 -0400, David F. Skoll wrote: =>On Mon, 27 Oct 2014 23:50:20 -0700 =>Ian Zimmerman wrote: => =>> Or you could run dovecot and its sieve plugin. Sieve is a real =>> standard (RFC 5228) which procmail never was. => =>It may be a standard, but it's nowhere near as flexible as Perl. =>I have very unusual filtering requirements (for example, rules that change =>depending on time-of-day or depending on who has the support pager that week) =>that are best expressed with a proper programming language. This is for the archives, not to change Ian or David's opinions Check out some of the sieve extensions. You (general) might be surprised that sieve can do what is described above. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: Spam messages bypassing SA
On 10/27/2014 8:37 PM, Bob Proulx wrote: In the first email: # The lock file ensures that only 1 spamassassin invocation happens # at 1 time, to keep the load down. Thanks, that was my thought as well and your analysis on using spamc and removing the lock was EXACTLY where my thought process was going! Regards, KAM
Re: Spam messages bypassing SA
On Tue, 28 Oct 2014, Jeff Mincy wrote: I agree with everything you wrote but only when bayes autolearning is turned off. Bayes learning holds an exclusive lock to the bayes database particularly during expiration. If spamc does bayes autolearning and starts an expiration then other spamc runs for that user will be locked out of bayes. At some point you start getting timeouts at different points in the email delivery chain. Automatic expiry is strongly discouraged for this reason; there should be a scheduled cron job that does the expiry. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...the Fates notice those who buy chainsaws... -- www.darwinawards.com --- 3 days until Halloween
Re: Spam messages bypassing SA
From: Bob Proulx
Date: Mon, 27 Oct 2014 18:37:35 -0600
In the first email:
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 40
| spamc -x
Kevin A. McGrail wrote:
> geoff.spamassassin140903 wrote:
> > Kevin A. McGrail wrote:
> > > Using procmail without MTA glue is OK for many uses. I am wondering
how
> > > many spamd connections you allow and if you have checked your logs?
> > >
> > > I also cannot remember but the uses of a lock file seem odd for
> > > something that can thread. Any one know if that is a good idea to
> > > remove?
> >
> > I wonder if you could explain in simple terms what the lockfile achieves
> > in this situation? Is it even possible that it could cause messages to
> > bypass SA?
>
> I don't think a lockfile achieves anything because it's a call to a
program.
> Procmail has some weird syntax so hopefully someone with some procmail-fu
> can tell us if a lock on a procmail system call does anything.
Well... The comment in the example explains what the lock is
attempting to do. I think that comment got missed in the follow-ups.
The lock will restrict spamassassin invocations to one at a time to
prevent a high system load average running too many spamassassin
processes all at once. It will serialize spamassassin invocations to
one at a time instead of many in parallel.
Normally the MTA will receive incoming messages and will fork a
process for each incoming connection. If the outside world connects
and sends 100 messages all at once then there will be 100 MTA
processes running in parallel. If 10,000 all at once then probably
some MTA process limit will prevent forking that many depending upon
your configuration. Each of those will try to send the message
through procmail and spamassassin in parallel too. Running 10,000
procmail processes in parallel probably won't be a problem since it is
light weight. However running perl spamassassin 100 or 1,000 times in
parallel all at once can be quite a resource hit to a moderate system!
By putting the lock in the procmail rule it prevents more than one
perl spamassassin process from running at a time. This keeps the
system from being overloaded due to a spike from the outside world. I
want to emphasize that the outside world impacts the system and can
have an effect of a DDoS just by overwhelming the system with external
connections. The MTA has limits to prevent this but while those are
tuned for normal delivery the MTA maintainers won't know if you are
running each message through spamasassin and causing a higher load
because of it. The default MTA limits are probably too high when
considering running the message through spamassassin too.
The procmail example comes from the wiki page example:
http://wiki.apache.org/spamassassin/UsedViaProcmail
The wiki page example is launching "spamassassin" not "spamc". That
is an important difference to this case. Someone has changed that to
spamc in the above and preserved all else including the serialization
lock. The spamc talks to a spamd and so the number of parallel
processes spamd can handle depends upon the spamd configuration. In
the spamc use I would be inclined to remove the serialization lock.
Let it be throttled at the spamd side of things instead. That would
make the most sense to me. Then tune spamd's limits as needed.
In summary I suggest removing the serialization lock from the spamc
recipe. Give it a try and monitor system resource utilization. Start
tuning at spamd. Tune other things as needed afterward.
:0fw
| spamc -x
:0e
{
EXITCODE=$?
}
Bob
I agree with everything you wrote but only when bayes autolearning is
turned off. Bayes learning holds an exclusive lock to the bayes
database particularly during expiration.
If spamc does bayes autolearning and starts an expiration then other
spamc runs for that user will be locked out of bayes. At some point
you start getting timeouts at different points in the email delivery
chain.
I have a separate sa-learn (or spamc -L) procmail recipe that has a
serialization lock.
-jeff
Re: procmail (was Re: Spam messages bypassing SA)
On Mon, 27 Oct 2014 23:50:20 -0700 Ian Zimmerman wrote: > Or you could run dovecot and its sieve plugin. Sieve is a real > standard (RFC 5228) which procmail never was. It may be a standard, but it's nowhere near as flexible as Perl. I have very unusual filtering requirements (for example, rules that change depending on time-of-day or depending on who has the support pager that week) that are best expressed with a proper programming language. Regards, David.
Re: procmail (was Re: Spam messages bypassing SA)
On Fri, 24 Oct 2014 08:43:41 -0400, "David F. Skoll" wrote: David> Procmail is also unmaintained abandonware, as far as I can tell. David> If you use SpamAssassin, you probably like Perl, so I would David> recommend Email::Filter instead. It's far more flexible than David> procmail and lets you write readable filters. David> Since procmail is still the default LDA on Debian, this is my .procmailrc: David> :0 David> | /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1 David> And excerpts from my filter look something like this: Or you could run dovecot and its sieve plugin. Sieve is a real standard (RFC 5228) which procmail never was. -- Please *no* private copies of mailing list or newsgroup messages. Local Variables: mode:claws-external End:
Re: Spam messages bypassing SA
In the first email:
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 40
| spamc -x
Kevin A. McGrail wrote:
> geoff.spamassassin140903 wrote:
> > Kevin A. McGrail wrote:
> > > Using procmail without MTA glue is OK for many uses. I am wondering how
> > > many spamd connections you allow and if you have checked your logs?
> > >
> > > I also cannot remember but the uses of a lock file seem odd for
> > > something that can thread. Any one know if that is a good idea to
> > > remove?
> >
> > I wonder if you could explain in simple terms what the lockfile achieves
> > in this situation? Is it even possible that it could cause messages to
> > bypass SA?
>
> I don't think a lockfile achieves anything because it's a call to a program.
> Procmail has some weird syntax so hopefully someone with some procmail-fu
> can tell us if a lock on a procmail system call does anything.
Well... The comment in the example explains what the lock is
attempting to do. I think that comment got missed in the follow-ups.
The lock will restrict spamassassin invocations to one at a time to
prevent a high system load average running too many spamassassin
processes all at once. It will serialize spamassassin invocations to
one at a time instead of many in parallel.
Normally the MTA will receive incoming messages and will fork a
process for each incoming connection. If the outside world connects
and sends 100 messages all at once then there will be 100 MTA
processes running in parallel. If 10,000 all at once then probably
some MTA process limit will prevent forking that many depending upon
your configuration. Each of those will try to send the message
through procmail and spamassassin in parallel too. Running 10,000
procmail processes in parallel probably won't be a problem since it is
light weight. However running perl spamassassin 100 or 1,000 times in
parallel all at once can be quite a resource hit to a moderate system!
By putting the lock in the procmail rule it prevents more than one
perl spamassassin process from running at a time. This keeps the
system from being overloaded due to a spike from the outside world. I
want to emphasize that the outside world impacts the system and can
have an effect of a DDoS just by overwhelming the system with external
connections. The MTA has limits to prevent this but while those are
tuned for normal delivery the MTA maintainers won't know if you are
running each message through spamasassin and causing a higher load
because of it. The default MTA limits are probably too high when
considering running the message through spamassassin too.
The procmail example comes from the wiki page example:
http://wiki.apache.org/spamassassin/UsedViaProcmail
The wiki page example is launching "spamassassin" not "spamc". That
is an important difference to this case. Someone has changed that to
spamc in the above and preserved all else including the serialization
lock. The spamc talks to a spamd and so the number of parallel
processes spamd can handle depends upon the spamd configuration. In
the spamc use I would be inclined to remove the serialization lock.
Let it be throttled at the spamd side of things instead. That would
make the most sense to me. Then tune spamd's limits as needed.
In summary I suggest removing the serialization lock from the spamc
recipe. Give it a try and monitor system resource utilization. Start
tuning at spamd. Tune other things as needed afterward.
:0fw
| spamc -x
:0e
{
EXITCODE=$?
}
Bob
Re: procmail (was Re: Spam messages bypassing SA)
Am 27.10.2014 um 21:04 schrieb Daniel Staal: > --As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged > to have said: > >> by the way >> >> http://www.exploit-db.com/exploits/34896/ >> >> always have a shellshock patched system these days with postfix/procmail > > --As for the rest, it is mine. > > Interesting. I dug a bit further out of curiosity. > > Postfix is irrelevant in this jep - Procmail is what needs to be looked at. > More specifically, the rules that are being used; running procmail in > and of itself doesn't allow this to be exploited, it's only if you have > a procmail rule that sticks info into the environment (not uncommon) > that it happens. > > The default shell is the recipient's login shell - though that can be > overridden in procmailrc. > > I wouldn't rule out other LDA's from having similar problems without > proof - but it's something to be aware of. where ever bash scripting may involved i think, perhaps pre/post login/last scripts etc seen a lot of ideas.., i.e some bash command found in log interpreted by home grown log analyser and invoked at loogrotate time etc but thats total off topic , and deeply related to bash security > > Daniel T. Staal > > --- > This email copyright the author. Unless otherwise noted, you > are expressly allowed to retransmit, quote, or otherwise use > the contents for non-commercial purposes. This copyright will > expire 5 years after the author's death, or in 30 years, > whichever is longer, unless such a period is in excess of > local copyright law. > --- Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: procmail (was Re: Spam messages bypassing SA)
--As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged to have said: by the way http://www.exploit-db.com/exploits/34896/ always have a shellshock patched system these days with postfix/procmail --As for the rest, it is mine. Interesting. I dug a bit further out of curiosity. Postfix is irrelevant in this - Procmail is what needs to be looked at. More specifically, the rules that are being used; running procmail in and of itself doesn't allow this to be exploited, it's only if you have a procmail rule that sticks info into the environment (not uncommon) that it happens. The default shell is the recipient's login shell - though that can be overridden in procmailrc. I wouldn't rule out other LDA's from having similar problems without proof - but it's something to be aware of. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: procmail (was Re: Spam messages bypassing SA)
Am 27.10.2014 um 19:55 schrieb Bob Proulx:
> David F. Skoll wrote:
>> "Kevin A. McGrail" wrote:
>>> Procmail has some weird syntax
>>
>> Procmail is also unmaintained abandonware, as far as I can tell.
>
> That isn't really a fair assessment of procmail. It is like saying
> that 'cp' is unmaintained abandonware. The original authors no longer
> maintain it. (It would be difficult since they have passed on.) The
> call syntax hasn't changed in forty years. All true. But if it does
> what it does reliably then there is no need to change it. Procmail is
> like that too. Procmail does what it does very reliably. It is
> mostly maintained downstream in software distributions but that makes
> it no less useful and no less reliable.
>
> I get it that the syntax is very old-school and many people don't like
> it. That is fine. As you mentioned there are several alternatives
> available. There is no problem with people liking alternatives
> better. That is great. No two people will have identical tastes. If
> people have choice and choose a different alternative that is one of
> the beautiful things about free(dom) software.
>
>> Since procmail is still the default LDA on Debian, this is my .procmailrc:
>
> If you don't like procmail then I would use ~/.forward to select a
> different mail delivery agent. Otherwise that is an extra process and
> a waste of resources. For Postfix the default forward_path allows
> ~/.forward. At a guess this would do it for you and then there would
> be no extra procmail process. Same for Sendmail. I believe Exim
> respects the .forward too.
>
> "|IFS=' ';exec /usr/bin/perl /home/dfs/.mail-filter.pl >>
> /home/dfs/.mail-filter.log 2>&1 || exit 75 #dfs"
>
>> And excerpts from my filter look something like this:
>>
>> # ...
>> my $REC = strftime('%Y-%m', localtime(time));
>> my $p = '/var/imap/dfs';
>>
>> my $h = $m->header('RT-Ticket');
>> if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
>> my $r_to = $m->header('Reply-To');
>> if (defined($r_to) && ($r_to =~
>> /invoices(-comment)?\@roaringpenguin\.com/)) {
>> accept_mail("InvoiceTickets");
>> } else {
>> accept_mail("Tickets");
>> }
>> }
>>
>> accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license
>> key generated for/ && mail_for(qr/provision_request/);
>> accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
>> accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
>>
>> $m->accept("$p/Received-Archive/$REC");
>>
>> which I find far more readable than .procmailrc recipes.
>
> I think this proves that beauty is in the eye of the beholder.
> :-)
>
> Bob
>
by the way
http://www.exploit-db.com/exploits/34896/
always have a shellshock patched system these days with postfix/procmail
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: procmail (was Re: Spam messages bypassing SA)
David F. Skoll wrote:
> "Kevin A. McGrail" wrote:
> > Procmail has some weird syntax
>
> Procmail is also unmaintained abandonware, as far as I can tell.
That isn't really a fair assessment of procmail. It is like saying
that 'cp' is unmaintained abandonware. The original authors no longer
maintain it. (It would be difficult since they have passed on.) The
call syntax hasn't changed in forty years. All true. But if it does
what it does reliably then there is no need to change it. Procmail is
like that too. Procmail does what it does very reliably. It is
mostly maintained downstream in software distributions but that makes
it no less useful and no less reliable.
I get it that the syntax is very old-school and many people don't like
it. That is fine. As you mentioned there are several alternatives
available. There is no problem with people liking alternatives
better. That is great. No two people will have identical tastes. If
people have choice and choose a different alternative that is one of
the beautiful things about free(dom) software.
> Since procmail is still the default LDA on Debian, this is my .procmailrc:
If you don't like procmail then I would use ~/.forward to select a
different mail delivery agent. Otherwise that is an extra process and
a waste of resources. For Postfix the default forward_path allows
~/.forward. At a guess this would do it for you and then there would
be no extra procmail process. Same for Sendmail. I believe Exim
respects the .forward too.
"|IFS=' ';exec /usr/bin/perl /home/dfs/.mail-filter.pl >>
/home/dfs/.mail-filter.log 2>&1 || exit 75 #dfs"
> And excerpts from my filter look something like this:
>
> # ...
> my $REC = strftime('%Y-%m', localtime(time));
> my $p = '/var/imap/dfs';
>
> my $h = $m->header('RT-Ticket');
> if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
> my $r_to = $m->header('Reply-To');
> if (defined($r_to) && ($r_to =~
> /invoices(-comment)?\@roaringpenguin\.com/)) {
> accept_mail("InvoiceTickets");
> } else {
> accept_mail("Tickets");
> }
> }
>
> accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license key
> generated for/ && mail_for(qr/provision_request/);
> accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
> accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
>
> $m->accept("$p/Received-Archive/$REC");
>
> which I find far more readable than .procmailrc recipes.
I think this proves that beauty is in the eye of the beholder.
:-)
Bob
Re: procmail (was Re: Spam messages bypassing SA)
On 10/24/2014 8:43 AM, David F. Skoll wrote: ...I would recommend Email::Filter instead. Definitely will try it out! Thanks.
procmail (was Re: Spam messages bypassing SA)
On Thu, 23 Oct 2014 18:00:29 -0400
"Kevin A. McGrail" wrote:
> Procmail has some weird syntax
Procmail is also unmaintained abandonware, as far as I can tell.
If you use SpamAssassin, you probably like Perl, so I would recommend
Email::Filter instead. It's far more flexible than procmail and lets
you write readable filters.
Since procmail is still the default LDA on Debian, this is my .procmailrc:
:0
| /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1
And excerpts from my filter look something like this:
# ...
my $REC = strftime('%Y-%m', localtime(time));
my $p = '/var/imap/dfs';
my $h = $m->header('RT-Ticket');
if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
my $r_to = $m->header('Reply-To');
if (defined($r_to) && ($r_to =~
/invoices(-comment)?\@roaringpenguin\.com/)) {
accept_mail("InvoiceTickets");
} else {
accept_mail("Tickets");
}
}
accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license key
generated for/ && mail_for(qr/provision_request/);
accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
$m->accept("$p/Received-Archive/$REC");
which I find far more readable than .procmailrc recipes.
Regards,
David.
Re: Spam messages bypassing SA
On Thu, 23 Oct 2014, geoff.spamassassin140...@alphaworks.co.uk wrote: On 04/09/2014 15:56, John Hardin wrote: On Thu, 4 Sep 2014, Geoff Soper wrote: > I've got an issue whereby spam messages seem to be somehow bypassing SA > and getting into my inbox. > > : 0fw: spamassassin.lock > * < 40 > | spamc -x Are the messages that bypass SA always rather large? No, unfortunately not... I understand why the large messages bypass SA but not the small ones. As a slightly related aside, what do people typically do about larger messages containing virus laden zip files? Personally, my site security policy is no zipped executables absent prior arrangement. http://www.impsec.org/email-tools/procmail-security.html -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- If Microsoft made hammers, everyone would whine about how poorly screws were designed and about how they are hard to hammer in, and wonder why it takes so long to paint a wall using the hammer. --- 875 days since the first successful private support mission to ISS (SpaceX)
Re: Spam messages bypassing SA
On 23/10/2014 23:00, Kevin A. McGrail wrote: On 10/23/2014 5:47 PM, geoff.spamassassin140...@alphaworks.co.uk wrote: On 04/09/2014 11:29, Kevin A. McGrail wrote: Using procmail without MTA glue is OK for many uses. I am wondering how many spamd connections you allow and if you have checked your logs? I also cannot remember but the uses of a lock file seem odd for something that can thread. Any one know if that is a good idea to remove? Regards, KAM Hi, apologies for the delay in my response... I wonder if you could explain in simple terms what the lockfile achieves in this situation? Is it even possible that it could cause messages to bypass SA? I don't think a lockfile achieves anything because it's a call to a program. Procmail has some weird syntax so hopefully someone with some procmail-fu can tell us if a lock on a procmail system call does anything. In the meantime, here's a good resource about procmail and lockfiles: http://www.techrepublic.com/article/all-the-wonders-of-procmail-part-2-lockfiles-and-nondelivering-recipes/ BTW, I followed the example detailed at http://wiki.apache.org/spamassassin/UsedViaProcmail (see "How do I use SpamAssassin with procmail?") for my implementation...
Re: Spam messages bypassing SA
On 10/23/2014 5:47 PM, geoff.spamassassin140...@alphaworks.co.uk wrote: On 04/09/2014 11:29, Kevin A. McGrail wrote: Using procmail without MTA glue is OK for many uses. I am wondering how many spamd connections you allow and if you have checked your logs? I also cannot remember but the uses of a lock file seem odd for something that can thread. Any one know if that is a good idea to remove? Regards, KAM Hi, apologies for the delay in my response... I wonder if you could explain in simple terms what the lockfile achieves in this situation? Is it even possible that it could cause messages to bypass SA? I don't think a lockfile achieves anything because it's a call to a program. Procmail has some weird syntax so hopefully someone with some procmail-fu can tell us if a lock on a procmail system call does anything. In the meantime, here's a good resource about procmail and lockfiles: http://www.techrepublic.com/article/all-the-wonders-of-procmail-part-2-lockfiles-and-nondelivering-recipes/ regards, KAM
Re: Spam messages bypassing SA
On 10/23/2014 11:51 PM, geoff.spamassassin140...@alphaworks.co.uk wrote:
On 04/09/2014 15:56, John Hardin wrote:
On Thu, 4 Sep 2014, Geoff Soper wrote:
I've got an issue whereby spam messages seem to be somehow bypassing
SA and getting into my inbox.
:0fw: spamassassin.lock
* < 40
| spamc -x
Are the messages that bypass SA always rather large?
No, unfortunately not... I understand why the large messages bypass SA
but not the small ones.
As a slightly related aside, what do people typically do about larger
messages containing virus laden zip files?
I do
### ClamAV
CLAMSCAN=/usr/local/bin/clamdscan
:0
{
VIRUS=`$CLAMSCAN --stdout -`
:0 Di
* VIRUS ?? FOUND
/dev/null
}
###
you can also store them fo review instead of sending to /dev/null
Re: Spam messages bypassing SA
On 04/09/2014 15:56, John Hardin wrote: On Thu, 4 Sep 2014, Geoff Soper wrote: I've got an issue whereby spam messages seem to be somehow bypassing SA and getting into my inbox. :0fw: spamassassin.lock * < 40 | spamc -x Are the messages that bypass SA always rather large? No, unfortunately not... I understand why the large messages bypass SA but not the small ones. As a slightly related aside, what do people typically do about larger messages containing virus laden zip files? Many thanks, Geoff
Re: Spam messages bypassing SA
On 04/09/2014 11:29, Kevin A. McGrail wrote: Using procmail without MTA glue is OK for many uses. I am wondering how many spamd connections you allow and if you have checked your logs? I also cannot remember but the uses of a lock file seem odd for something that can thread. Any one know if that is a good idea to remove? Regards, KAM Hi, apologies for the delay in my response... I wonder if you could explain in simple terms what the lockfile achieves in this situation? Is it even possible that it could cause messages to bypass SA? I have access to SA through a VPS, it's not a server I administer but support are very helpful... Many thanks, Geoff
Re: Spam messages bypassing SA
On Thu, 4 Sep 2014, Geoff Soper wrote: I've got an issue whereby spam messages seem to be somehow bypassing SA and getting into my inbox. :0fw: spamassassin.lock * < 40 | spamc -x Are the messages that bypass SA always rather large? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The tree of freedom must be freshened from time to time with the blood of tyrants and tyrannosaurs. -- DW, commenting on the GM6 Lynx .50BMG bullpup --- 13 days until the 227th anniversary of the signing of the U.S. Constitution
Re: Spam messages bypassing SA
On 09/04/2014 12:29 PM, Kevin A. McGrail wrote: Using procmail without MTA glue is OK for many uses. I am wondering how many spamd connections you allow and if you have checked your logs? I also cannot remember but the uses of a lock file seem odd for something that can thread. Any one know if that is a good idea to remove? on a little trap box I use :0fw | spamc no lock - works fine :0fw: spamassassin.lock * < 40 | spamc -x at first, this causes messages over 400k not to be sent into spamc. at second, spamc itself will ignore messages over 256K. at third, when you alreway use 'w' flag, you should check for failures and exit with tempfail.. at fourth, can't you plug SA directly in your MTA?
Re: Spam messages bypassing SA
Using procmail without MTA glue is OK for many uses. I am wondering how many spamd connections you allow and if you have checked your logs? I also cannot remember but the uses of a lock file seem odd for something that can thread. Any one know if that is a good idea to remove? Regards, KAM >>:0fw: spamassassin.lock >>* < 40 >>| spamc -x > >at first, this causes messages over 400k not to be sent into spamc. >at second, spamc itself will ignore messages over 256K. > >at third, when you alreway use 'w' flag, you should check for failures >and >exit with tempfail.. > >at fourth, can't you plug SA directly in your MTA?
Re: Spam messages bypassing SA
On 04.09.14 07:51, Geoff Soper wrote: References: <1014212314.119.1394801251166.JavaMail.TPIWEB$@virus.tw.shuttle.com>,<6d30dd2234165a4fb52082d093514b87132b0...@tpiex04.shuttle.corp> <16437ca7e285c5498f501fae7eeb7d131323f...@tpiex04.shuttle.corp>,<53282f7c.9010...@alphaworks.co.uk> <16437ca7e285c5498f501fae7eeb7d131323f...@tpiex04.shuttle.corp> In-Reply-To: <16437ca7e285c5498f501fae7eeb7d131323f...@tpiex04.shuttle.corp> Hello, please, if you are writing a new post, send it as new mail and not as reply/followup on old mail. It makes people with threading clients angry and they can also in such case miss your e-mail. Thank you. I've got an issue whereby spam messages seem to be somehow bypassing SA and getting into my inbox. I call SA via procmail as per https://wiki.apache.org/spamassassin/UsedViaProcmail The exact procmail file that calls SA is as follows: # The condition line ensures that only messages smaller than 250 kB # (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam # isn't bigger than a few k and working with big messages can bring # SpamAssassin to its knees. # # The lock file ensures that only 1 spamassassin invocation happens # at 1 time, to keep the load down. # :0fw: spamassassin.lock * < 40 | spamc -x at first, this causes messages over 400k not to be sent into spamc. at second, spamc itself will ignore messages over 256K. at third, when you alreway use 'w' flag, you should check for failures and exit with tempfail.. at fourth, can't you plug SA directly in your MTA? -- 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. I wonder how much deeper the ocean would be without sponges.
