Re: procmail (was Re: Spam messages bypassing SA)
On Oct 28, 2014 at 07:40 -0400, David F. Skoll wrote: =>On Mon, 27 Oct 2014 23:50:20 -0700 =>Ian Zimmerman wrote: => =>> Or you could run dovecot and its sieve plugin. Sieve is a real =>> standard (RFC 5228) which procmail never was. => =>It may be a standard, but it's nowhere near as flexible as Perl. =>I have very unusual filtering requirements (for example, rules that change =>depending on time-of-day or depending on who has the support pager that week) =>that are best expressed with a proper programming language. This is for the archives, not to change Ian or David's opinions Check out some of the sieve extensions. You (general) might be surprised that sieve can do what is described above. -- *** Derek DigetOffice of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***
Re: procmail (was Re: Spam messages bypassing SA)
On Mon, 27 Oct 2014 23:50:20 -0700 Ian Zimmerman wrote: > Or you could run dovecot and its sieve plugin. Sieve is a real > standard (RFC 5228) which procmail never was. It may be a standard, but it's nowhere near as flexible as Perl. I have very unusual filtering requirements (for example, rules that change depending on time-of-day or depending on who has the support pager that week) that are best expressed with a proper programming language. Regards, David.
Re: procmail (was Re: Spam messages bypassing SA)
On Fri, 24 Oct 2014 08:43:41 -0400, "David F. Skoll" wrote: David> Procmail is also unmaintained abandonware, as far as I can tell. David> If you use SpamAssassin, you probably like Perl, so I would David> recommend Email::Filter instead. It's far more flexible than David> procmail and lets you write readable filters. David> Since procmail is still the default LDA on Debian, this is my .procmailrc: David> :0 David> | /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1 David> And excerpts from my filter look something like this: Or you could run dovecot and its sieve plugin. Sieve is a real standard (RFC 5228) which procmail never was. -- Please *no* private copies of mailing list or newsgroup messages. Local Variables: mode:claws-external End:
Re: procmail (was Re: Spam messages bypassing SA)
Am 27.10.2014 um 21:04 schrieb Daniel Staal: > --As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged > to have said: > >> by the way >> >> http://www.exploit-db.com/exploits/34896/ >> >> always have a shellshock patched system these days with postfix/procmail > > --As for the rest, it is mine. > > Interesting. I dug a bit further out of curiosity. > > Postfix is irrelevant in this jep - Procmail is what needs to be looked at. > More specifically, the rules that are being used; running procmail in > and of itself doesn't allow this to be exploited, it's only if you have > a procmail rule that sticks info into the environment (not uncommon) > that it happens. > > The default shell is the recipient's login shell - though that can be > overridden in procmailrc. > > I wouldn't rule out other LDA's from having similar problems without > proof - but it's something to be aware of. where ever bash scripting may involved i think, perhaps pre/post login/last scripts etc seen a lot of ideas.., i.e some bash command found in log interpreted by home grown log analyser and invoked at loogrotate time etc but thats total off topic , and deeply related to bash security > > Daniel T. Staal > > --- > This email copyright the author. Unless otherwise noted, you > are expressly allowed to retransmit, quote, or otherwise use > the contents for non-commercial purposes. This copyright will > expire 5 years after the author's death, or in 30 years, > whichever is longer, unless such a period is in excess of > local copyright law. > --- Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: procmail (was Re: Spam messages bypassing SA)
--As of October 27, 2014 8:29:52 PM +0100, Robert Schetterer is alleged to have said: by the way http://www.exploit-db.com/exploits/34896/ always have a shellshock patched system these days with postfix/procmail --As for the rest, it is mine. Interesting. I dug a bit further out of curiosity. Postfix is irrelevant in this - Procmail is what needs to be looked at. More specifically, the rules that are being used; running procmail in and of itself doesn't allow this to be exploited, it's only if you have a procmail rule that sticks info into the environment (not uncommon) that it happens. The default shell is the recipient's login shell - though that can be overridden in procmailrc. I wouldn't rule out other LDA's from having similar problems without proof - but it's something to be aware of. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: procmail (was Re: Spam messages bypassing SA)
Am 27.10.2014 um 19:55 schrieb Bob Proulx:
> David F. Skoll wrote:
>> "Kevin A. McGrail" wrote:
>>> Procmail has some weird syntax
>>
>> Procmail is also unmaintained abandonware, as far as I can tell.
>
> That isn't really a fair assessment of procmail. It is like saying
> that 'cp' is unmaintained abandonware. The original authors no longer
> maintain it. (It would be difficult since they have passed on.) The
> call syntax hasn't changed in forty years. All true. But if it does
> what it does reliably then there is no need to change it. Procmail is
> like that too. Procmail does what it does very reliably. It is
> mostly maintained downstream in software distributions but that makes
> it no less useful and no less reliable.
>
> I get it that the syntax is very old-school and many people don't like
> it. That is fine. As you mentioned there are several alternatives
> available. There is no problem with people liking alternatives
> better. That is great. No two people will have identical tastes. If
> people have choice and choose a different alternative that is one of
> the beautiful things about free(dom) software.
>
>> Since procmail is still the default LDA on Debian, this is my .procmailrc:
>
> If you don't like procmail then I would use ~/.forward to select a
> different mail delivery agent. Otherwise that is an extra process and
> a waste of resources. For Postfix the default forward_path allows
> ~/.forward. At a guess this would do it for you and then there would
> be no extra procmail process. Same for Sendmail. I believe Exim
> respects the .forward too.
>
> "|IFS=' ';exec /usr/bin/perl /home/dfs/.mail-filter.pl >>
> /home/dfs/.mail-filter.log 2>&1 || exit 75 #dfs"
>
>> And excerpts from my filter look something like this:
>>
>> # ...
>> my $REC = strftime('%Y-%m', localtime(time));
>> my $p = '/var/imap/dfs';
>>
>> my $h = $m->header('RT-Ticket');
>> if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
>> my $r_to = $m->header('Reply-To');
>> if (defined($r_to) && ($r_to =~
>> /invoices(-comment)?\@roaringpenguin\.com/)) {
>> accept_mail("InvoiceTickets");
>> } else {
>> accept_mail("Tickets");
>> }
>> }
>>
>> accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license
>> key generated for/ && mail_for(qr/provision_request/);
>> accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
>> accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
>>
>> $m->accept("$p/Received-Archive/$REC");
>>
>> which I find far more readable than .procmailrc recipes.
>
> I think this proves that beauty is in the eye of the beholder.
> :-)
>
> Bob
>
by the way
http://www.exploit-db.com/exploits/34896/
always have a shellshock patched system these days with postfix/procmail
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: procmail (was Re: Spam messages bypassing SA)
David F. Skoll wrote:
> "Kevin A. McGrail" wrote:
> > Procmail has some weird syntax
>
> Procmail is also unmaintained abandonware, as far as I can tell.
That isn't really a fair assessment of procmail. It is like saying
that 'cp' is unmaintained abandonware. The original authors no longer
maintain it. (It would be difficult since they have passed on.) The
call syntax hasn't changed in forty years. All true. But if it does
what it does reliably then there is no need to change it. Procmail is
like that too. Procmail does what it does very reliably. It is
mostly maintained downstream in software distributions but that makes
it no less useful and no less reliable.
I get it that the syntax is very old-school and many people don't like
it. That is fine. As you mentioned there are several alternatives
available. There is no problem with people liking alternatives
better. That is great. No two people will have identical tastes. If
people have choice and choose a different alternative that is one of
the beautiful things about free(dom) software.
> Since procmail is still the default LDA on Debian, this is my .procmailrc:
If you don't like procmail then I would use ~/.forward to select a
different mail delivery agent. Otherwise that is an extra process and
a waste of resources. For Postfix the default forward_path allows
~/.forward. At a guess this would do it for you and then there would
be no extra procmail process. Same for Sendmail. I believe Exim
respects the .forward too.
"|IFS=' ';exec /usr/bin/perl /home/dfs/.mail-filter.pl >>
/home/dfs/.mail-filter.log 2>&1 || exit 75 #dfs"
> And excerpts from my filter look something like this:
>
> # ...
> my $REC = strftime('%Y-%m', localtime(time));
> my $p = '/var/imap/dfs';
>
> my $h = $m->header('RT-Ticket');
> if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
> my $r_to = $m->header('Reply-To');
> if (defined($r_to) && ($r_to =~
> /invoices(-comment)?\@roaringpenguin\.com/)) {
> accept_mail("InvoiceTickets");
> } else {
> accept_mail("Tickets");
> }
> }
>
> accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license key
> generated for/ && mail_for(qr/provision_request/);
> accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
> accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
>
> $m->accept("$p/Received-Archive/$REC");
>
> which I find far more readable than .procmailrc recipes.
I think this proves that beauty is in the eye of the beholder.
:-)
Bob
Re: procmail (was Re: Spam messages bypassing SA)
On 10/24/2014 8:43 AM, David F. Skoll wrote: ...I would recommend Email::Filter instead. Definitely will try it out! Thanks.
procmail (was Re: Spam messages bypassing SA)
On Thu, 23 Oct 2014 18:00:29 -0400
"Kevin A. McGrail" wrote:
> Procmail has some weird syntax
Procmail is also unmaintained abandonware, as far as I can tell.
If you use SpamAssassin, you probably like Perl, so I would recommend
Email::Filter instead. It's far more flexible than procmail and lets
you write readable filters.
Since procmail is still the default LDA on Debian, this is my .procmailrc:
:0
| /usr/bin/perl /home/dfs/.mail-filter.pl >> /home/dfs/.mail-filter.log 2>&1
And excerpts from my filter look something like this:
# ...
my $REC = strftime('%Y-%m', localtime(time));
my $p = '/var/imap/dfs';
my $h = $m->header('RT-Ticket');
if (defined($h) && ($h =~ /roaringpenguin\.com/)) {
my $r_to = $m->header('Reply-To');
if (defined($r_to) && ($r_to =~
/invoices(-comment)?\@roaringpenguin\.com/)) {
accept_mail("InvoiceTickets");
} else {
accept_mail("Tickets");
}
}
accept_mail("LicenseKeys") if $m->subject =~ /^(Annual|Perpetual) license key
generated for/ && mail_for(qr/provision_request/);
accept_mail("Buildbot") if $m->subject =~ /^buildbot success/;
accept_mail("Buildbot") if $m->subject =~ /^buildbot failure/;
$m->accept("$p/Received-Archive/$REC");
which I find far more readable than .procmailrc recipes.
Regards,
David.
