You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Geoff Soper <ge...@alphaworks.co.uk> on 2014/09/04 08:51:54 UTC
Spam messages bypassing SA
Hi,
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:
#
#Standard SA call to be included from .procmailrc files
#
:0 f
| formail -A"X-Procmail-SpamAssassinInclude: 23/03/2010"
#
# Pipe the mail through spamassassin (replace 'spamassassin' with 'spamc'
# if you use the spamc/spamd combination)
#
# 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
* < 400000
| spamc -x
# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "
:0 fhw
| sed -e '1s/^/F/'
}
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*
/dev/null
#${DIR}.Spam.Bad/
:0
* ^X-Spam-Status: Yes
${DIR}.Spam/
When I see these spam messages in my inbox, they have the X-Procmail-SpamAssassinInclude header but no evidence (i.e. headers) of SA having processed the message. According to Thunderbird, these messages are well below the size threshold specified. Can it be todo with the locking mechanism specified by the file above? If it's locked, what happens? Does it wait for SA to be available or simply skip SA? Historically I've been getting these messages occasionally but over the past week I've had bursts of dozens of messages over a few minutes all apparently bypassing SA. I'm running version 3.3.2.
Thanks in anticipation
Re: Dumping email with blank To: header ?
Posted by LuKreme <kr...@kreme.com>.
> On 04 Sep 2014, at 13:56 , Timothy Murphy <ga...@alice.it> wrote:
>
> On Thursday, September 04, 2014 11:26:01 AM LuKreme wrote:
>
>>> Is there a simple check to make sure salearn is working?
>>> (I get the message that "192 messages have been examined",
>>> and ~/.spamassassin/bayes_seen and bayes_tok are pretty large,
>>> 300kB and 5MB.)
>
>> For the record, using sql for babes is considerably faster.
>
> Do you mean using SQL in some way would speed up salearn?
More importantly, it speeds up the bayes checks on incoming spam.
--
"you'd think you could trust a horde of hungarian barbarians"
Re: Dumping email with blank To: header ?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 4 Sep 2014, Timothy Murphy wrote:
> I'm not certain that SA is taking account of the result of sa-learn.
> I'm surprised that the spam score does not seem to change significantly
> after many instances of almost identical messages are put through sa-learn.
(1) Do you see any BAYES_* rules hitting at all?
(2) What does /usr/bin/sa-learn --dump magic report?
(3) Did you review the spamd user vs. sa-learn user as I suggested?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The most glaring example of the cognitive dissonance on the left
is the concept that human beings are inherently good, yet at the
same time cannot be trusted with any kind of weapon, unless the
magic fairy dust of government authority gets sprinkled upon them.
-- Moshe Ben-David
-----------------------------------------------------------------------
13 days until the 227th anniversary of the signing of the U.S. Constitution
Re: Dumping email with blank To: header ?
Posted by Timothy Murphy <ga...@alice.it>.
On Thursday, September 04, 2014 11:26:01 AM LuKreme wrote:
> > Is there a simple check to make sure salearn is working?
> > (I get the message that "192 messages have been examined",
> > and ~/.spamassassin/bayes_seen and bayes_tok are pretty large,
> > 300kB and 5MB.)
> For the record, using sql for babes is considerably faster.
Do you mean using SQL in some way would speed up salearn?
Do you have a reference for that?
Actually, I run salearn as a cron job in the middle of the night,
so it doesn't matter too much to me if it takes 1 minute or 5 minutes.
> > 4) I haven't found a short and simple SA tutorial,
> > explaining how SA works,
> > with a few tests that one might add to the default,
> > and a couple of checks one could try to make sure it is working.
> If you see X-Spam headers, it’s working. If in the X-Spam-Report you see
> BAYES_ then that is working.
I'm not certain that SA is taking account of the result of sa-learn.
I'm surprised that the spam score does not seem to change significantly
after many instances of almost identical messages are put through sa-learn.
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
Re: Dumping email with blank To: header ?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/4/2014 2:18 PM, John Hardin wrote:
> On Thu, 4 Sep 2014, jdow wrote:
>
>> On 2014-09-04 10:51, John Hardin wrote:
>>> On Thu, 4 Sep 2014, LuKreme wrote:
>>>
>>> > For the record, using sql for babes is considerably faster.
>>>
>>> Is that anything like "SQL for Dummies"?
>>
>> John, I was wondering if there was an SQL for boys, too.
>
> SQL for Jocks, maybe?
>
> I gotta wonder how LuKreme developed *that* particular finger-macro... :)
His new website development work to replace facebook?
Select * from babes where interested in me = 'true';
0 rows in set (0.00 sec)
Just to continue the silliness...
Regards,
KAM
Re: Dumping email with blank To: header ?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 4 Sep 2014, jdow wrote:
> On 2014-09-04 10:51, John Hardin wrote:
>> On Thu, 4 Sep 2014, LuKreme wrote:
>>
>> > For the record, using sql for babes is considerably faster.
>>
>> Is that anything like "SQL for Dummies"?
>
> John, I was wondering if there was an SQL for boys, too.
SQL for Jocks, maybe?
I gotta wonder how LuKreme developed *that* particular finger-macro... :)
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Users mistake widespread adoption of Microsoft Office for the
development of a document format standard.
-----------------------------------------------------------------------
13 days until the 227th anniversary of the signing of the U.S. Constitution
Re: Dumping email with blank To: header ?
Posted by Chris <cp...@embarqmail.com>.
On Thu, 2014-09-04 at 10:59 -0700, jdow wrote:
> On 2014-09-04 10:51, John Hardin wrote:
> > On Thu, 4 Sep 2014, LuKreme wrote:
> >
> >> For the record, using sql for babes is considerably faster.
> >
> > Is that anything like "SQL for Dummies"?
>
> John, I was wondering if there was an SQL for boys, too.
>
> {O,o}
Haven't seen you on a list in, well, years. You're still as witty as
ever I see :)
--
Chris
31.11°N 97.89°W (Elev. 1092 ft)
15:12:48 up 1 day, 6:43, 1 user, load average: 0.11, 0.18, 0.18
Ubuntu 14.04 LTS, kernel 3.13.0-35-generic
Re: Dumping email with blank To: header ?
Posted by jdow <jd...@earthlink.net>.
On 2014-09-04 10:51, John Hardin wrote:
> On Thu, 4 Sep 2014, LuKreme wrote:
>
>> For the record, using sql for babes is considerably faster.
>
> Is that anything like "SQL for Dummies"?
John, I was wondering if there was an SQL for boys, too.
{O,o}
Re: Dumping email with blank To: header ?
Posted by LuKreme <kr...@kreme.com>.
> On 04 Sep 2014, at 12:36 , Joe Quinn <jq...@pccc.com> wrote:
>
> On 9/4/2014 1:51 PM, John Hardin wrote:
>> On Thu, 4 Sep 2014, LuKreme wrote:
>>
>>> For the record, using sql for babes is considerably faster.
>>
>> Is that anything like "SQL for Dummies"?
>>
> I've heard good things about the Derek Zoolander Center for Kids who can't SQL Good and who Wanna Learn to do Other Stuff Good too.
I think I've gotten more comments on that not-typo, both onlist and off, than any email in recent memory.
OS X autocorrect doesn't like the word "bayes" much. Heh.
--
'I don't see why everyone depends on me. I'm not dependable. Even I
don't depend on me, and I'm me.'
Re: Dumping email with blank To: header ?
Posted by Joe Quinn <jq...@pccc.com>.
On 9/4/2014 1:51 PM, John Hardin wrote:
> On Thu, 4 Sep 2014, LuKreme wrote:
>
>> For the record, using sql for babes is considerably faster.
>
> Is that anything like "SQL for Dummies"?
>
I've heard good things about the Derek Zoolander Center for Kids who
can't SQL Good and who Wanna Learn to do Other Stuff Good too.
Re: Dumping email with blank To: header ?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 4 Sep 2014, LuKreme wrote:
> For the record, using sql for babes is considerably faster.
Is that anything like "SQL for Dummies"?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Trusting in anti-gun laws to keep you from being shot is like
refusing to wear your seatbelt because you trust traffic laws to
keep you from being in a car accident. -- Erin Palette
-----------------------------------------------------------------------
13 days until the 227th anniversary of the signing of the U.S. Constitution
Re: Dumping email with blank To: header ?
Posted by LuKreme <kr...@kreme.com>.
> On 04 Sep 2014, at 05:32 , Timothy Murphy <ga...@alice.it> wrote:
>
> 1) Is there a simple way of dumping email with an empty To: header?
> This seems invariably to be spam, and I'm surprised SA doesn't seem
> to score it highly.
You may be surprised if you actually check spam and ham.
> 2) Does "autolearn" actually remove spam with a very high score?
> Or does it still get marked as spam by SA and passed on?
SA never removes mail under any circumstances.
> Is there a simple check to make sure salearn is working?
> (I get the message that "192 messages have been examined",
> and ~/.spamassassin/bayes_seen and bayes_tok are pretty large,
> 300kB and 5MB.)
For the record, using sql for babes is considerably faster.
> 4) I haven't found a short and simple SA tutorial,
> explaining how SA works,
> with a few tests that one might add to the default,
> and a couple of checks one could try to make sure it is working.
If you see X-Spam headers, it’s working. If in the X-Spam-Report you see BAYES_ then that is working.
--
she [Esk] was already learning that if you ignore the rules people will,
half the time, quietly rewrite them so they don't apply to you. --Equal
Rites
Re: Dumping email with blank To: header ?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 4 Sep 2014, Timothy Murphy wrote:
> 1) Is there a simple way of dumping email with an empty To: header?
If by "dump" you mean "discard", this simple test might be better done in
your MTA. However, "poison pill" rules (absent certain DNSBLs) are
generally discouraged.
> This seems invariably to be spam, and I'm surprised SA doesn't seem
> to score it highly.
Probably because even if it's a good spam sign, it isn't very common or it
appears together with enough other spam signs that it's not scored very
highly by itself.
If you post some spamples of such to pastebin we'll take a look.
> Maybe it doesn't consider this to be a header?
Yes, it does. There are rules that check for no TO or CC. For example:
http://ruleqa.spamassassin.org/20140902-r1621946-n/REPLYTO_WITHOUT_TO_CC/detail
If you want to score for "no TO or CC header", you could do this:
meta NO_TO_CC !__TOCC_EXISTS
> 2) Does "autolearn" actually remove spam with a very high score?
> Or does it still get marked as spam by SA and passed on?
"autolearn" is submission of the message to the Bayes backend for
training. This can affect the scoring of subsequently-scanned messages,
but it does not affect the score of that message.
Also: SA does not directly have anything to do with the delivery process.
All it does is generate a spamminess score. *Something else* has to
interpret that score to decide the ultimate destination of the message:
inbox, quarantine or bit bucket.
> 3) As will be obvious, I am not a student of SA;
> I just use the default setting, which seems to work well enough for me.
> But I'm a little surprised that more or less identical email
> that I have marked as spam many times and passed through salearn
> still seems to get through.
That would seem to indicate a problem with Bayes.
> Is there a simple check to make sure salearn is working?
You will see BAYES_* rule hits on messages if Bayes is working. You have
to learn a minimum number of spam *and* ham messages before it will start
working.
This will report statistics about the Bayes database.
/usr/bin/sa-learn --dump magic
The most common mistake is to train Bayes as a user that is not the same
user that SA is running under to scan messages - i.e., you're training the
wrong Bayes database. Check which user spamd is running under, and which
user you're running sa-learn as. They should be the same user.
> 4) I haven't found a short and simple SA tutorial,
> explaining how SA works,
> with a few tests that one might add to the default,
> and a couple of checks one could try to make sure it is working.
The definitive test to check whether SA is scanning messages is to send a
message containing the GTUBE string, it should always be detected and
score 1000 points. Google "spam GTUBE" for more details.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Reply versus new thread [Was: Dumping email with blank To: header
?]
Posted by Ian Zimmerman <it...@buug.org>.
Others have gracefully answered as to the substance of your message.
I'll have to be a pest and ask that you please do not use "Reply" or
"Followup" when you're starting a new topic. For list readers with user
agents that thread the standard (RFC standard) way, that breaks
threading.
The way to start a new topic is to copy the list address, do a "New
Message" or similar, and paste the address into the destination field.
You can also save the address in your contact list / address book to
avoid the copy and paste in the future.
Thanks for your cooperation.
--
Please *no* private copies of mailing list or newsgroup messages.
Local Variables:
mode:claws-external
End:
Dumping email with blank To: header ?
Posted by Timothy Murphy <ga...@alice.it>.
1) Is there a simple way of dumping email with an empty To: header?
This seems invariably to be spam, and I'm surprised SA doesn't seem
to score it highly.
Maybe it doesn't consider this to be a header?
2) Does "autolearn" actually remove spam with a very high score?
Or does it still get marked as spam by SA and passed on?
3) As will be obvious, I am not a student of SA;
I just use the default setting, which seems to work well enough for me.
But I'm a little surprised that more or less identical email
that I have marked as spam many times and passed through salearn
still seems to get through.
Is there a simple check to make sure salearn is working?
(I get the message that "192 messages have been examined",
and ~/.spamassassin/bayes_seen and bayes_tok are pretty large,
300kB and 5MB.)
4) I haven't found a short and simple SA tutorial,
explaining how SA works,
with a few tests that one might add to the default,
and a couple of checks one could try to make sure it is working.
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
Re: Spam messages bypassing SA
Posted by Axb <ax...@gmail.com>.
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
>>> * < 400000
>>> | 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: procmail (was Re: Spam messages bypassing SA)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 10/24/2014 8:43 AM, David F. Skoll wrote:
> ...I would recommend Email::Filter instead.
Definitely will try it out! Thanks.
Re: procmail (was Re: Spam messages bypassing SA)
Posted by Robert Schetterer <rs...@sys4.de>.
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)
Posted by Daniel Staal <DS...@usa.net>.
--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)
Posted by Robert Schetterer <rs...@sys4.de>.
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)
Posted by Bob Proulx <bo...@proulx.com>.
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)
Posted by Derek Diget <de...@wmich.edu>.
On Oct 28, 2014 at 07:40 -0400, David F. Skoll wrote:
=>On Mon, 27 Oct 2014 23:50:20 -0700
=>Ian Zimmerman <it...@buug.org> 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 Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
Re: procmail
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.10.2014 um 01:39 schrieb Ted Mittelstaedt:
>
>
> On 10/28/2014 5:31 PM, Reindl Harald wrote:
>>
>>
>> Am 29.10.2014 um 01:23 schrieb Ted Mittelstaedt:
>>> I think that one of the things that up and coming Linux admins are
>>> supposed to do is write a "Procmail is dead" article and post it
>>> somewhere. It sure seems like it there's enough of them out there.
>>>
>>> Procmail isn't dead. However, the Procmail website is simply in
>>> an awful and atrocious state. It has been at least a half a decade
>>> since the server the website is on stopped hosting the distro, which
>>> is frankly ridiculous. OK I get that the domain owner doesn't want
>>> to spring the money for the bandwidth but there are better ways to
>>> handle it than an HTTP error. I also get that the domain owner isn't
>>> interested in fixing his HTML. OK whatever.
>>>
>>> There's a lot of distributions that include Procmail and lots and
>>> lots of people using it. There's still people writing patches for
>>> it for their distros. Yes it lacks a maintainer which is a shame.
>>>
>>> But it is even more shameful that RedHat and the other pay distributions
>>> aren't stepping up and picking up maintenance of it
>>
>> frankly in times of LMTP and Sieve there is hardly a need to use
>> procmail - it is used because "i know it and it just works" - so why
>> should somebody step in and maintain it while nobody is forced to use it
>>
>
> From my understanding (as I don't use Dovecot and Sieve) you cannot pipe
> mail from the Sieve implementation into other programs, once Sieve is
> done with it, that's it. Right there that's a non-starter for me, I'm
> afraid.
true - on the other hand i don't use dovecot except as roxy and SASL
provider and did not have any need for procmail over 6 years now
sieve is a standard an dnot dovecot specific
> I'm a Unixy brat. Procmail is unixy, some of these more recent
> Linux bits of software are more Windows than Unix. Ignoring pipes
> is very bad, if I wanted greasy kid stuff software I'd run Windows
> on my servers.
me too - but i don't use pipes in context of untrusted input while
incomign mail is taht sort of traffic and at least recent issues proves
to be right
> As for why should someone maintain it, people already maintain it -
> the distros maintain their "versions" You want a single maintainer
> to coordinate patches so people aren't re-inventing the wheel
wrong answer or question
convince someone to take over upstream or accept it is dead
until that happens be happy it is still shipped from distributions
instead get dropped as abandonware at all
Re: procmail
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 10/28/2014 5:31 PM, Reindl Harald wrote:
>
>
> Am 29.10.2014 um 01:23 schrieb Ted Mittelstaedt:
>> I think that one of the things that up and coming Linux admins are
>> supposed to do is write a "Procmail is dead" article and post it
>> somewhere. It sure seems like it there's enough of them out there.
>>
>> Procmail isn't dead. However, the Procmail website is simply in
>> an awful and atrocious state. It has been at least a half a decade
>> since the server the website is on stopped hosting the distro, which
>> is frankly ridiculous. OK I get that the domain owner doesn't want
>> to spring the money for the bandwidth but there are better ways to
>> handle it than an HTTP error. I also get that the domain owner isn't
>> interested in fixing his HTML. OK whatever.
>>
>> There's a lot of distributions that include Procmail and lots and
>> lots of people using it. There's still people writing patches for
>> it for their distros. Yes it lacks a maintainer which is a shame.
>>
>> But it is even more shameful that RedHat and the other pay distributions
>> aren't stepping up and picking up maintenance of it
>
> frankly in times of LMTP and Sieve there is hardly a need to use
> procmail - it is used because "i know it and it just works" - so why
> should somebody step in and maintain it while nobody is forced to use it
>
From my understanding (as I don't use Dovecot and Sieve) you cannot pipe
mail from the Sieve implementation into other programs, once Sieve is
done with it, that's it. Right there that's a non-starter for me, I'm
afraid.
I'm a Unixy brat. Procmail is unixy, some of these more recent
Linux bits of software are more Windows than Unix. Ignoring pipes
is very bad, if I wanted greasy kid stuff software I'd run Windows
on my servers.
As for why should someone maintain it, people already maintain it -
the distros maintain their "versions" You want a single maintainer
to coordinate patches so people aren't re-inventing the wheel.
Ted
Re: procmail
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2014-10-28 at 22:10 -0400, David F. Skoll wrote:
> > frankly in times of LMTP and Sieve there is hardly a need to use
> > procmail - it is used because "i know it and it just works" - so why
> > should somebody step in and maintain it while nobody is forced to use
> > it
>
> I use Email::Filter, not procmail, but tell me: Can LMTP and Sieve do
> the following?
Dammit, this is just too teasing... Sorry. ;)
procmail can do all of those. (Yeah, not your question, but still...)
> 1) Cc: mail containing a specific header to a certain address, but only
> between 08:00-09:00 or 17:00-21:00.
Sure. Limiting to specific days or hours can be achieved without
external process by recipe conditions based on our own SMTP server's
Received header, which we can trust to be correct.
> 2) Archive mail in a folder called Received-Archive/YYYY-MM.
Trivial. See man procmailex.
> 3) Take mail to a specific address, shorten it by replacing things
> like "four" with "4", "this" with "dis", etc. and send as much of the
> result as possible as a 140-character SMS message? Oh, and only do
> this if the support calendar says that I am on the support pager that
> week.
Yep. Completely internal, given there's an email to SMS gateway
(flashback 15 years ago), calling an external process for SMS delivery
otherwise.
> 4) Take the voicemail notifications produced by our Asterisk
> software and replace the giant .WAV attachment with a much
> smaller .MP3 equivalent.
Check. Calling an external process, but I doubt procmail and ffmpeg /
avconv is worse than Perl and the modules required for that audio
conversion.
Granted, in this case I'd need some rather skillful sed-fu in the pipe,
or a little help of an external Perl script using MIME-tools... ;)
> These are all real-world requirements that my filter fulfills. And it
> does most of them without forking external processes. (Item 3 actually consults
> a calendar program to see who's on support, but the rest are all handled
> in-process.)
That said, and all joking apart:
Do you guys even remember when this got completely off topic?
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: procmail
Posted by Ted Mittelstaedt <te...@ipinc.net>.
On 10/28/2014 7:10 PM, David F. Skoll wrote:
> On Wed, 29 Oct 2014 01:31:51 +0100
> Reindl Harald<h....@thelounge.net> wrote:
>
>> frankly in times of LMTP and Sieve there is hardly a need to use
>> procmail - it is used because "i know it and it just works" - so why
>> should somebody step in and maintain it while nobody is forced to use
>> it
>
> I use Email::Filter, not procmail, but tell me: Can LMTP and Sieve do
> the following?
>
> 1) Cc: mail containing a specific header to a certain address, but only
> between 08:00-09:00 or 17:00-21:00.
>
Yes - it would be ugly but you could do this from cron. Just make up 2
procmail recipes and have the cron job copy over the one on tap.
> 2) Archive mail in a folder called Received-Archive/YYYY-MM.
>
There's a milter for that. (I use Sendmail myself)
> 3) Take mail to a specific address, shorten it by replacing things
> like "four" with "4", "this" with "dis", etc. and send as much of the
> result as possible as a 140-character SMS message? Oh, and only do
> this if the support calendar says that I am on the support pager that
> week.
>
Probably - but I wouldn't want to write it either in Perl or
Procmail, nor would I want to read the result! So what happens if
the mailserver that your running the SMS text email through bites
the dust?
> 4) Take the voicemail notifications produced by our Asterisk
> software and replace the giant .WAV attachment with a much
> smaller .MP3 equivalent.
>
This is what I use for that (no Procmail in this)
tedm-voicemail: "| /usr/local/bin/wavmail-to-mp3mail.pl |
/usr/sbin/sendmail -i -f vm@example.com tedm@example.com"
#!/usr/bin/perl
#
use MIME::Parser;
use IO::File;
$p = new MIME::Parser;
$p->output_to_core(1);
$e = $p->parse(\*STDIN);
$f = "/tmp/$$";
#
# If running on FBSD then this might be simpler
# open(PIPE, "|/usr/local/bin/ffmpeg -i - -f mp3 $f");
#
# SOX can read the compressed ADPCM since it uses different sound
libraries but it cannot change
# the bitrate, and the bitrate that the Panasonic puts out is unusual -
while it can be put into
# an .mp3 by sox, nothing can read it. Instead we convert the wav to
regular PCM which lame
# can understand
#
open(PIPE, "|/usr/local/bin/sox -t wav - -s -t wav - |
/usr/local/bin/lame --preset phone -v -q 0 -V 9 --quiet - $f");
print PIPE $e->parts(1)->bodyhandle->as_string;
close PIPE;
if( open(PIPE,"< :bytes",$f) ) {
if( $fh = $e->parts(1)->bodyhandle->open(w) ) {
my $buffer;
while( read(PIPE, $buffer, 10240) > 0 ) ### read chunks of 10KB at a time
{
$fh->print($buffer);
}
$fh->close;
}
close PIPE;
}
$e->parts(1)->head->replace("Content-type","audio/mp3");
$e->parts(1)->head->mime_attr("content-type.name"=>"voice-mail.mp3");
$e->parts(1)->head->replace("Content-Disposition","attachment");
$e->parts(1)->head->mime_attr("content-disposition.filename"=>"voice-mail.mp3");
$e->parts(0)->bodyhandle->as_string =~ m/\((\d+)\)/m;
$e->sync_headers(Length=>"COMPUTE");
$e->print;
unlink($f);
smtp#
I'd be interested in seeing how you do it with your filter.
Ted
> These are all real-world requirements that my filter fulfills. And it
> does most of them without forking external processes. (Item 3 actually consults
> a calendar program to see who's on support, but the rest are all handled
> in-process.)
>
> Regards,
>
> David.
Re: procmail
Posted by Derek Diget <de...@wmich.edu>.
On Oct 28, 2014 at 22:10 -0400, David F. Skoll wrote:
=>On Wed, 29 Oct 2014 01:31:51 +0100
=>Reindl Harald <h....@thelounge.net> wrote:
=>
=>> frankly in times of LMTP and Sieve there is hardly a need to use
=>> procmail - it is used because "i know it and it just works" - so why
=>> should somebody step in and maintain it while nobody is forced to use
=>> it
=>
=>I use Email::Filter, not procmail, but tell me: Can LMTP and Sieve do
=>the following?
Disclaimer: I have not created/tested/working sieve rules for the
following, so YMMV. :)
=>1) Cc: mail containing a specific header to a certain address, but only
=>between 08:00-09:00 or 17:00-21:00.
Sieve: Yes, see first example in section 5.1 of RFC 5260 - Sieve Email
Filtering: Date and Index Extensions
<http://www.ietf.org/rfc/rfc5260.txt>
=>2) Archive mail in a folder called Received-Archive/YYYY-MM.
Sieve: Yes, see second to last example in section 5.1 of RFC 5260 -
Sieve Email Filtering: Date and Index Extensions
<http://www.ietf.org/rfc/rfc5260.txt>
=>3) Take mail to a specific address, shorten it by replacing things
=>like "four" with "4", "this" with "dis", etc. and send as much of the
=>result as possible as a 140-character SMS message? Oh, and only do
=>this if the support calendar says that I am on the support pager that
=>week.
Sieve: Substring substitution - Yes, See RFC 5229 - Sieve: Variables
Extension <http://www.ietf.org/rfc/rfc5229.txt> along with RFC 5703 -
Sieve Email Filtering: MIME Part Tests, Iteration, Extraction,
Replacement, and Enclosure <http://www.ietf.org/rfc/rfc5703.txt>
Looking up who is on call, see RFC 6134 - Sieve Extension: Externally
Stored Lists <http://www.ietf.org/rfc/rfc6134.txt>. I don't see an
example doing a call out to a CalDAV server, but see section 2.9.2 -
Example 2 where it references a holiday calendar list.
=>4) Take the voicemail notifications produced by our Asterisk
=>software and replace the giant .WAV attachment with a much
=>smaller .MP3 equivalent.
Sieve: RFC 6558 - Sieve Extension for Converting Messages before Delivery
<http://www.ietf.org/rfc/rfc6558.txt>.
=>These are all real-world requirements that my filter fulfills. And it
=>does most of them without forking external processes. (Item 3
=>actually consults a calendar program to see who's on support, but the
=>rest are all handled in-process.)
Now, the part left open is finding a sieve implementation that supports
these extensions. :)
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
Re: procmail
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Wed, 29 Oct 2014 01:31:51 +0100
Reindl Harald <h....@thelounge.net> wrote:
> frankly in times of LMTP and Sieve there is hardly a need to use
> procmail - it is used because "i know it and it just works" - so why
> should somebody step in and maintain it while nobody is forced to use
> it
I use Email::Filter, not procmail, but tell me: Can LMTP and Sieve do
the following?
1) Cc: mail containing a specific header to a certain address, but only
between 08:00-09:00 or 17:00-21:00.
2) Archive mail in a folder called Received-Archive/YYYY-MM.
3) Take mail to a specific address, shorten it by replacing things
like "four" with "4", "this" with "dis", etc. and send as much of the
result as possible as a 140-character SMS message? Oh, and only do
this if the support calendar says that I am on the support pager that
week.
4) Take the voicemail notifications produced by our Asterisk
software and replace the giant .WAV attachment with a much
smaller .MP3 equivalent.
These are all real-world requirements that my filter fulfills. And it
does most of them without forking external processes. (Item 3 actually consults
a calendar program to see who's on support, but the rest are all handled
in-process.)
Regards,
David.
Re: procmail
Posted by Reindl Harald <h....@thelounge.net>.
Am 29.10.2014 um 01:23 schrieb Ted Mittelstaedt:
> I think that one of the things that up and coming Linux admins are
> supposed to do is write a "Procmail is dead" article and post it
> somewhere. It sure seems like it there's enough of them out there.
>
> Procmail isn't dead. However, the Procmail website is simply in
> an awful and atrocious state. It has been at least a half a decade
> since the server the website is on stopped hosting the distro, which
> is frankly ridiculous. OK I get that the domain owner doesn't want
> to spring the money for the bandwidth but there are better ways to
> handle it than an HTTP error. I also get that the domain owner isn't
> interested in fixing his HTML. OK whatever.
>
> There's a lot of distributions that include Procmail and lots and
> lots of people using it. There's still people writing patches for
> it for their distros. Yes it lacks a maintainer which is a shame.
>
> But it is even more shameful that RedHat and the other pay distributions
> aren't stepping up and picking up maintenance of it
frankly in times of LMTP and Sieve there is hardly a need to use
procmail - it is used because "i know it and it just works" - so why
should somebody step in and maintain it while nobody is forced to use it
Re: procmail
Posted by Ted Mittelstaedt <te...@ipinc.net>.
I think that one of the things that up and coming Linux admins are
supposed to do is write a "Procmail is dead" article and post it
somewhere. It sure seems like it there's enough of them out there.
Procmail isn't dead. However, the Procmail website is simply in
an awful and atrocious state. It has been at least a half a decade
since the server the website is on stopped hosting the distro, which
is frankly ridiculous. OK I get that the domain owner doesn't want
to spring the money for the bandwidth but there are better ways to
handle it than an HTTP error. I also get that the domain owner isn't
interested in fixing his HTML. OK whatever.
There's a lot of distributions that include Procmail and lots and
lots of people using it. There's still people writing patches for
it for their distros. Yes it lacks a maintainer which is a shame.
But it is even more shameful that RedHat and the other pay distributions
aren't stepping up and picking up maintenance of it.
I use procmail, but I don't use it to call SpamAssassin. Nor do I
use it with any extensive recipes.
Ted
On 10/28/2014 11:43 AM, jdow wrote:
> On 2014-10-28 11:24, David F. Skoll wrote:
>> On Tue, 28 Oct 2014 10:24:37 -0700
>> jdow <jd...@earthlink.net> wrote:
>>
>>>> Sure, but that doesn't mean a consummate chef need fear them!
>>
>>> Nonetheless one should keep bare knife switches away from said chef
>>> lest he forget that being an consummate expert in one field does not
>>> make him even barely competent in other fields.
>>
>> Yes, well. I've spent the last 13 years of my life creating a company
>> whose products are all in the email security space with most of the
>> critical
>> logic written in Perl. I may be barely competent in some fields, but
>> I do claim a certain competence in using Perl to mess with email. :)
>>
>> I also suspect that most SpamAssassin admins probably have some
>> competence with perl.
>>
>> Anyway, we are drifting OT here I guess...
>>
>> Regards,
>>
>> David.
>
> That is hardly a compelling reason to change from procmail to perl, for
> me or others with working procmail systems. You seem to be advocating
> handing me perl and turning me loose after ripping procmail out of my
> hands. That does not endear you to me. It isn't broken. So why fix it?
> There is a tremendous amount of experience out there setting it up and
> using it. Is that a reason to discard it for something new? We're seeing
> the fruits of that sort of divisiveness with the systemd controversy. If
> fix means better and still 100% compatible it is an easy sell. If fix
> means 0% compatible being better is not good for people with better
> things upon which to spend their time than learning a new way shoved
> down their throats. In the abstract you are right. In the practical,
> that "rightness" appears to tarnish.
>
> In the case in point early on in this discussion it is quite easy to
> tell procmail to add a new header X-been-through-my-spamfilter. Then
> look for that header before feeding to spamassassin in the procmail
> script. If it appears merely deliver the mail. If it doesn't exist
> filter it and feed it to the next step. That is NOT a huge effort in
> procmail if somebody has already embraced learning the damnfool thing.
> Why condemn the poor sod to learning something new rather than fixing
> other aspects of his system?
>
> Not all of us here are email adminstrators. Many are working with
> smaller systems and manage the entire system more or less single handed
> or with limited help because their employer is cheap.
>
> {^_^} Joanne
> {o.o}
Re: procmail
Posted by Ian Zimmerman <it...@buug.org>.
On Tue, 28 Oct 2014 11:43:04 -0700
jdow <jd...@earthlink.net> wrote:
jdow> That is hardly a compelling reason to change from procmail to
jdow> perl, for me or others with working procmail systems. You seem to
jdow> be advocating handing me perl and turning me loose after ripping
jdow> procmail out of my hands. That does not endear you to me. It isn't
jdow> broken. So why fix it? There is a tremendous amount of experience
jdow> out there setting it up and using it. Is that a reason to discard
jdow> it for something new? We're seeing the fruits of that sort of
jdow> divisiveness with the systemd controversy. If fix means better and
jdow> still 100% compatible it is an easy sell. If fix means 0%
jdow> compatible being better is not good for people with better things
jdow> upon which to spend their time than learning a new way shoved down
jdow> their throats. In the abstract you are right. In the practical,
jdow> that "rightness" appears to tarnish.
You sound like you're replying more to me than to David.
How do you match non-ASCII From: in procmail? Note that the encoding
may differ, even for the same sender, depending on which MUA he's using
ATM.
_Some_ old stuff deserves to be replaced.
--
Please *no* private copies of mailing list or newsgroup messages.
Local Variables:
mode:claws-external
End:
Re: procmail
Posted by jdow <jd...@earthlink.net>.
On 2014-10-28 11:24, David F. Skoll wrote:
> On Tue, 28 Oct 2014 10:24:37 -0700
> jdow <jd...@earthlink.net> wrote:
>
>>> Sure, but that doesn't mean a consummate chef need fear them!
>
>> Nonetheless one should keep bare knife switches away from said chef
>> lest he forget that being an consummate expert in one field does not
>> make him even barely competent in other fields.
>
> Yes, well. I've spent the last 13 years of my life creating a company
> whose products are all in the email security space with most of the critical
> logic written in Perl. I may be barely competent in some fields, but
> I do claim a certain competence in using Perl to mess with email. :)
>
> I also suspect that most SpamAssassin admins probably have some
> competence with perl.
>
> Anyway, we are drifting OT here I guess...
>
> Regards,
>
> David.
That is hardly a compelling reason to change from procmail to perl, for me or
others with working procmail systems. You seem to be advocating handing me perl
and turning me loose after ripping procmail out of my hands. That does not
endear you to me. It isn't broken. So why fix it? There is a tremendous amount
of experience out there setting it up and using it. Is that a reason to discard
it for something new? We're seeing the fruits of that sort of divisiveness with
the systemd controversy. If fix means better and still 100% compatible it is an
easy sell. If fix means 0% compatible being better is not good for people with
better things upon which to spend their time than learning a new way shoved down
their throats. In the abstract you are right. In the practical, that "rightness"
appears to tarnish.
In the case in point early on in this discussion it is quite easy to tell
procmail to add a new header X-been-through-my-spamfilter. Then look for that
header before feeding to spamassassin in the procmail script. If it appears
merely deliver the mail. If it doesn't exist filter it and feed it to the next
step. That is NOT a huge effort in procmail if somebody has already embraced
learning the damnfool thing. Why condemn the poor sod to learning something new
rather than fixing other aspects of his system?
Not all of us here are email adminstrators. Many are working with smaller
systems and manage the entire system more or less single handed or with limited
help because their employer is cheap.
{^_^} Joanne
{o.o}
Re: procmail
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Tue, 28 Oct 2014 10:24:37 -0700
jdow <jd...@earthlink.net> wrote:
> > Sure, but that doesn't mean a consummate chef need fear them!
> Nonetheless one should keep bare knife switches away from said chef
> lest he forget that being an consummate expert in one field does not
> make him even barely competent in other fields.
Yes, well. I've spent the last 13 years of my life creating a company
whose products are all in the email security space with most of the critical
logic written in Perl. I may be barely competent in some fields, but
I do claim a certain competence in using Perl to mess with email. :)
I also suspect that most SpamAssassin admins probably have some
competence with perl.
Anyway, we are drifting OT here I guess...
Regards,
David.
Re: procmail
Posted by jdow <jd...@earthlink.net>.
On 2014-10-28 06:09, David F. Skoll wrote:
> On Tue, 28 Oct 2014 13:28:19 +0100
> "Andrzej A. Filip" <an...@gmail.com> wrote:
>
>>> 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.
>
>> Do you keep sharp knives away from children? :-)
>
> Sure, but that doesn't mean a consummate chef need fear them!
>
> Regards,
>
> David.
Nonetheless one should keep bare knife switches away from said chef lest he
forget that being an consummate expert in one field does not make him even
barely competent in other fields.
1) If it ain't broke, don't fix it. 2) Clumsy is not broken.
Think about it a little.
{^_^}
Re: procmail
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Tue, 28 Oct 2014 13:28:19 +0100
"Andrzej A. Filip" <an...@gmail.com> wrote:
> > 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.
> Do you keep sharp knives away from children? :-)
Sure, but that doesn't mean a consummate chef need fear them!
Regards,
David.
Re: procmail
Posted by "Andrzej A. Filip" <an...@gmail.com>.
"David F. Skoll" <df...@roaringpenguin.com> wrote:
> On Mon, 27 Oct 2014 23:50:20 -0700
> Ian Zimmerman <it...@buug.org> 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.
Do you keep sharp knives away from children? :-)
--
A. Filip
Re: procmail (was Re: Spam messages bypassing SA)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Mon, 27 Oct 2014 23:50:20 -0700
Ian Zimmerman <it...@buug.org> 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)
Posted by Ian Zimmerman <it...@buug.org>.
On Fri, 24 Oct 2014 08:43:41 -0400,
"David F. Skoll" <df...@roaringpenguin.com> 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:
procmail (was Re: Spam messages bypassing SA)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Thu, 23 Oct 2014 18:00:29 -0400
"Kevin A. McGrail" <KM...@PCCC.com> 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
Posted by ge...@alphaworks.co.uk.
On 23/10/2014 23:00, Kevin A. McGrail wrote:
> On 10/23/2014 5:47 PM, geoff.spamassassin140903@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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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
Posted by Bob Proulx <bo...@proulx.com>.
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: Spam messages bypassing SA
Posted by John Hardin <jh...@impsec.org>.
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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by Jeff Mincy <je...@delphioutpost.com>.
From: Bob Proulx <bo...@proulx.com>
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
* < 400000
| 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: Spam messages bypassing SA
Posted by Bob Proulx <bo...@proulx.com>.
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
* < 400000
| 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: Spam messages bypassing SA
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 10/23/2014 5:47 PM, geoff.spamassassin140903@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
Posted by ge...@alphaworks.co.uk.
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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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
>>* < 400000
>>| 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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 04.09.14 07:51, Geoff Soper wrote:
>References: <10...@tpiex04.shuttle.corp>
> <16...@alphaworks.co.uk>
> <16...@tpiex04.shuttle.corp>
>In-Reply-To: <16...@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
>* < 400000
>| 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, uhlar@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.
Re: Spam messages bypassing SA
Posted by Axb <ax...@gmail.com>.
On 10/23/2014 11:51 PM, geoff.spamassassin140903@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
>>> * < 400000
>>> | 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
Posted by John Hardin <jh...@impsec.org>.
On Thu, 23 Oct 2014, geoff.spamassassin140903@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
>> > * < 400000
>> > | 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.
<plug type="shameless">http://www.impsec.org/email-tools/procmail-security.html</plug>
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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
Posted by ge...@alphaworks.co.uk.
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
>> * < 400000
>> | 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
Posted by John Hardin <jh...@impsec.org>.
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
> * < 400000
> | spamc -x
Are the messages that bypass SA always rather large?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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