FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 06-12-2010, 01:55 AM
 
Default Anything better than procmail?

Hi,

while still setting up my new system I wonder, whether there
somethning better than 'procmail' to process mails (maildir-format).
I am getting my mails via fetchmail/POP3.

Any better program for that task?

Thanks a lot for any help in advance!
Have a nice weekend!
Best regards,
mcc



--
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.
 
Old 06-12-2010, 06:52 AM
Neil Bothwick
 
Default Anything better than procmail?

On Sat, 12 Jun 2010 03:55:40 +0200, meino.cramer@gmx.de wrote:

> while still setting up my new system I wonder, whether there
> somethning better than 'procmail' to process mails (maildir-format).
> I am getting my mails via fetchmail/POP3.

Define better!

Easier to set up, probably.
More flexible, I doubt it.


--
Neil Bothwick

After all is said and done let there not be more said than done.
 
Old 06-12-2010, 10:15 AM
Peter Schuller
 
Default Anything better than procmail?

> while still setting up my new system I wonder, whether there
> somethning better than 'procmail' to process mails (maildir-format).
> I am getting my mails via fetchmail/POP3.
>
> Any better program for that task?

I prefer 'maildrop' for syntax reasons, but I don't claim it's better or worse.

--
/ Peter Schuller
 
Old 06-12-2010, 11:35 AM
David W Noon
 
Default Anything better than procmail?

On Sat, 12 Jun 2010 04:00:01 +0200, meino.cramer@gmx.de wrote about
[gentoo-user] Anything better than procmail?:

>while still setting up my new system I wonder, whether there
>somethning better than 'procmail' to process mails (maildir-format).
>I am getting my mails via fetchmail/POP3.
>
>Any better program for that task?

I bit the bullet a few years ago and installed an IMAP4 server --
initially Dovecot, but quickly replaced by dbmail. This allows you to
use a sieve script, instead of procmail "recipes". Moreover, each user
maintains his/her own sieve script.

So, my mail path is now:
1) fetchmail, from my ISP's POP3 server;
2) postfix, including spam and virus scanning with amavisd-new;
3) dbmail, for local IMAP4 delivery.

I am proud to say it is the best "home brew" mail system I have ever
seen.
--
Regards,

Dave [RLU #314465]
================================================== ====================
dwnoon@ntlworld.com (David W Noon)
================================================== ====================
 
Old 06-12-2010, 12:18 PM
Volker Armin Hemmann
 
Default Anything better than procmail?

On Samstag 12 Juni 2010, meino.cramer@gmx.de wrote:
> Hi,
>
> while still setting up my new system I wonder, whether there
> somethning better than 'procmail' to process mails (maildir-format).
> I am getting my mails via fetchmail/POP3.
>
> Any better program for that task?


not using all that at all and just use a mail client to get the mail from pop3
servers?
 
Old 06-12-2010, 01:37 PM
Enrico Weigelt
 
Default Anything better than procmail?

* meino.cramer@gmx.de <meino.cramer@gmx.de> wrote:
>
> Hi,
>
> while still setting up my new system I wonder, whether there
> somethning better than 'procmail' to process mails (maildir-format).
> I am getting my mails via fetchmail/POP3.

Is there anything you dont like in procmail ?


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
 
Old 06-12-2010, 07:32 PM
Stroller
 
Default Anything better than procmail?

Hi David,

Your setup looks fairly similar to my own, but I am intrigued by the
differences.



On 12 Jun 2010, at 12:35, David W Noon wrote:

... Dovecot, but quickly replaced by dbmail.


Can I ask you why?

I have found the author of Dovecot to be wonderfully responsive,
pushing out a fix for a deal-breaker issue for my site within hours of
me reporting it.



This allows you to use a sieve script, instead of procmail "recipes".


Can I ask you what the advantage of this is, please?

Looking at the example at <http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)
>, the language looks basically very similar to maildrop, and it
seems to do pretty much the same thing.


The reject syntax seems nice and clear, but if the MX server (for your
email's domain name) has already accepted the message then it's not
really much good rejecting it. In fact, doing so is surely frowned
upon, isn't it?



Moreover, each user maintains his/her own sieve script.


As certainly would be the case with maildrop, and surely too with
procmail?


Stroller.
 
Old 06-12-2010, 09:17 PM
David W Noon
 
Default Anything better than procmail?

On Sat, 12 Jun 2010 21:40:01 +0200, Stroller wrote about [gentoo-user]
Anything better than procmail?:

>Hi David,
>
>Your setup looks fairly similar to my own, but I am intrigued by the
>differences.

Okay. I have been using all kinds of software for handling email,
dating back to my OS/2 days in the early 1990's. I regard my current
set-up as sweet.

>On 12 Jun 2010, at 12:35, David W Noon wrote:
>> ... Dovecot, but quickly replaced by dbmail.
>
>Can I ask you why?

Certainly.

I wanted the messages to be stored in a single, dedicated logical volume
in my DASD farm. Dovecot always stored them in each user's ~/Mail/
directory, so they were all over the /home L.V. In contrast, dbmail
uses a database, in my case PostgreSQL, so it is up to the database
administrator to decide where they go; but it is always in the one
place. This makes for easy backup and restore: a cron jobs runs
pg_dump every night on the dbmail database..

>I have found the author of Dovecot to be wonderfully responsive,
>pushing out a fix for a deal-breaker issue for my site within hours
>of me reporting it.
>
>> This allows you to use a sieve script, instead of procmail "recipes".
>
>Can I ask you what the advantage of this is, please?

The recipe syntax for procmail is seriously ugly. Sieve looks like
most other non-procedural languages from the early 1980's, although it
arose in the 1990's. Since I am an old geezer who has been programming
since the early 1970's, this syntax felt more comfortable. Sieve is
also integrated into dbmail.

>Looking at the example at
><http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)
> >, the language looks basically very similar to maildrop, and it
>seems to do pretty much the same thing.

I have never used maildrop.

>The reject syntax seems nice and clear, but if the MX server (for
>your email's domain name) has already accepted the message then it's
>not really much good rejecting it. In fact, doing so is surely
>frowned upon, isn't it?

I use a quarantine folder in my IMAP4 account, and my sieve script
places spam and infected messages there. Since the physical location
is on a logical volume that holds a PostgreSQL tablespace, any malware
is not executable, as that L.V. is mounted with "noexec". This is
another advantage over placing mail in the /home L.V., in each user's
home directory.

>> Moreover, each user maintains his/her own sieve script.
>
>As certainly would be the case with maildrop, and surely too with
>procmail?

I don't know about maildrop, but procmail is usually managed centrally
and hangs off the tail end of Postfix, Exim, Courier or whatever MTA you
have. I always switched to root to maintain my delivery recipes, back
when I ran procmail.
--
Regards,

Dave [RLU #314465]
================================================== ====================
dwnoon@ntlworld.com (David W Noon)
================================================== ====================
 
Old 06-13-2010, 05:53 PM
Tanstaafl
 
Default Anything better than procmail?

On 2010-06-12 5:17 PM, David W Noon wrote:
>> On 12 Jun 2010, at 12:35, David W Noon wrote:
>>> ... Dovecot, but quickly replaced by dbmail.

>> Can I ask you why?

> Certainly.
>
> I wanted the messages to be stored in a single, dedicated logical
> volume in my DASD farm. Dovecot always stored them in each user's
> ~/Mail/ directory, so they were all over the /home L.V.

Dovecot will store them where you tell it to. You could have easily
stored them all in a single directory like /var/virtual/mail/user, or
even used a hashed directory scheme (which might be desirable for very
large installations like ISPs)...

> In contrast, dbmail uses a database, in my case PostgreSQL, so it is
> up to the database administrator to decide where they go; but it is
> always in the one place. This makes for easy backup and restore: a
> cron jobs runs pg_dump every night on the dbmail database..

Storing mail in a database sounds interesting, but it *will* introduce a
very noticeable performance hit, there is simply no way around it...

>> I have found the author of Dovecot to be wonderfully responsive,
>> pushing out a fix for a deal-breaker issue for my site within hours
>> of me reporting it.

+5 Timo is coding madman...

> Sieve is also integrated into dbmail.

And dovecot... and 2.0 will have even better integration.

>> The reject syntax [for sieve] seems nice and clear, but if the MX
>> server (for your email's domain name) has already accepted the
>> message then it's not really much good rejecting it. In fact, doing
>> so is surely frowned upon, isn't it?

> I use a quarantine folder in my IMAP4 account, and my sieve script
> places spam and infected messages there. Since the physical location
> is on a logical volume that holds a PostgreSQL tablespace, any malware
> is not executable, as that L.V. is mounted with "noexec". This is
> another advantage over placing mail in the /home L.V., in each user's
> home directory.

While dovecot+sieve does require a 'home' directory for sieve to work,
it doesn't have to be the users real home directory, and with
dovecot-LDA+sieve, you can safely reject at smtp time, and its vacation
message system is very sane (doesn't send vacation messages when it
shouldn't, like to mail lists, etc)...
 
Old 06-13-2010, 10:37 PM
David W Noon
 
Default Anything better than procmail?

On Sun, 13 Jun 2010 20:20:02 +0200, Tanstaafl wrote about Re:
[gentoo-user] Anything better than procmail?:

>On 2010-06-12 5:17 PM, David W Noon wrote:
>> I wanted the messages to be stored in a single, dedicated logical
>> volume in my DASD farm. Dovecot always stored them in each user's
>> ~/Mail/ directory, so they were all over the /home L.V.
>
>Dovecot will store them where you tell it to. You could have easily
>stored them all in a single directory like /var/virtual/mail/user, or
>even used a hashed directory scheme (which might be desirable for very
>large installations like ISPs)...

IIRC, that means that I have to give universal write access, perhaps
with a "sticky" bit, on that directory. The database approach makes
much more sense from a security point of view, as nobody accesses the
filesystem directly, except the database manager.

>> In contrast, dbmail uses a database, in my case PostgreSQL, so it is
>> up to the database administrator to decide where they go; but it is
>> always in the one place. This makes for easy backup and restore: a
>> cron jobs runs pg_dump every night on the dbmail database..
>
>Storing mail in a database sounds interesting, but it *will* introduce
>a very noticeable performance hit, there is simply no way around it...

Actually, it doesn't. The caching of PostgreSQL is very good, and it
performs better than ext3 or ReiserFS or JFS or ..., particularly for
random access patterns such as reading email messages. The only
additional overhead is the cross-memory transfer through a UNIX socket
from PostgreSQL to dbmail, which is much less than the caching benefits
of PostgreSQL.

>>> I have found the author of Dovecot to be wonderfully responsive,
>>> pushing out a fix for a deal-breaker issue for my site within hours
>>> of me reporting it.
>
>+5 Timo is coding madman...

But this is Gentoo. We get new releases when the Gentoo dev's allow
the new package through.

>> Sieve is also integrated into dbmail.
>
>And dovecot... and 2.0 will have even better integration.

But I have that now. ... :-)

You sound like a Microsoft zealot from the 1990's, where the next
release of your favourite product will have every feature imaginable --
and totally debugged too!

>>> The reject syntax [for sieve] seems nice and clear, but if the MX
>>> server (for your email's domain name) has already accepted the
>>> message then it's not really much good rejecting it. In fact, doing
>>> so is surely frowned upon, isn't it?
>
>> I use a quarantine folder in my IMAP4 account, and my sieve script
>> places spam and infected messages there. Since the physical location
>> is on a logical volume that holds a PostgreSQL tablespace, any
>> malware is not executable, as that L.V. is mounted with "noexec".
>> This is another advantage over placing mail in the /home L.V., in
>> each user's home directory.
>
>While dovecot+sieve does require a 'home' directory for sieve to work,
>it doesn't have to be the users real home directory, and with
>dovecot-LDA+sieve, you can safely reject at smtp time, and its vacation
>message system is very sane (doesn't send vacation messages when it
>shouldn't, like to mail lists, etc)...

What's a "vacation"? ... :-))
--
Regards,

Dave [RLU #314465]
================================================== ====================
dwnoon@ntlworld.com (David W Noon)
================================================== ====================
 

Thread Tools




All times are GMT. The time now is 09:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org