You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@spamassassin.apache.org by ge...@alphaworks.co.uk on 2014/10/23 23:47:53 UTC

Re: Spam messages bypassing SA

On 04/09/2014 11:29, Kevin A. McGrail wrote:
> Using procmail without MTA glue is OK for many uses.  I am wondering how many spamd connections you allow and if you have checked your logs?
>
> I also cannot remember but the uses of a lock file seem odd for something that can thread.  Any one know if that is a good idea to remove?
> Regards,
> KAM

Hi,
apologies for the delay in my response...

I wonder if you could explain in simple terms what the lockfile achieves 
in this situation? Is it even possible that it could cause messages to 
bypass SA?

I have access to SA through a VPS, it's not a server I administer but 
support are very helpful...

Many thanks,
Geoff

Re: 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.