You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Andrzej A. Filip" <an...@gmail.com> on 2014/10/28 13:28:19 UTC
Re: procmail
"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
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.