Summary: I'm doing a lot of backtracking in my simple little quest, because the task keeps getting interrupted for weeks at a stretch. Anyway, I'm still trying to set up a simple mail server in my tiny home network. I have the following picture in my head: - fetchmail grabs mail from my ISP's POP3 server and hands it off to... - some interim mail handling service/app and - magic happens, before - an imap server catches and holds that mail and serves it out to my clients on a couple of other computers at my house. I have not gotten past stage 1 yet. Yesterday, I ran one pass of fetchmail (with --keep) just to see what would happen. What happened is that 1545 messages came in, over a period of several minutes and went.... somewhere... I figure that they are on my hard disk somewhere in either MBOX format or maildir format (or maybe even mailboxes.db, but I doubt it) and: a) I don't know where they went. b) I don't know what format. QUESTION: What's the most straightforward way to find all that mail (before it gets mysteriously flushed or something), so I can begin to piece together how it's being handled now and what to do to have it handled the way I need? QUESTION 2: With only a few users on a few machines, and maybe a couple of hundred thousand messages stored for IMAP serving, is my best server option: - plain, vanilla imap - courier-imap - Cyrus-imap I understand that each of these also has preferred mailbox formats, so where in the mail trail does the incoming mail get mushed into one or another format? It seems to come from the ISP as single files, so I ASSume that the "conversion" to MBOX or maildir or [other option?] takes place either in fetchmail in the next app that handles the mail (procmail? sendmail? postfix?) before it reaches the resting place that imap will use. As for choosing a flavor of IMAP, I just don't know. I don't really want to get into setting up additional authentication databases (sasl? LDAP? other?), but if that would be simpler than the PAM or shadow requirements... well maybe... Last night, I had 22 browser windows open with a variety of Howtos and FAQs (many contradicting each other) for fetchmail, imap, Cyrus-imap, courier-imap, procmail, postfix, sendmail, qmail (no, I don't think I have qmail installed, but...). Basically I have an overload of info and an underload of knowledge or direction. I gave up and went to bed a 2:30 ... and got up at 5:30... oi! Kevin The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
mlist@safenet-inc.com wrote:
Summary: I'm doing a lot of backtracking in my simple little quest, because the task keeps getting interrupted for weeks at a stretch. Anyway, I'm still trying to set up a simple mail server in my tiny home network. I have the following picture in my head:
- fetchmail grabs mail from my ISP's POP3 server and hands it off to...
- some interim mail handling service/app and
- magic happens, before
- an imap server catches and holds that mail and serves it out to my clients on a couple of other computers at my house.
I have not gotten past stage 1 yet.
Yesterday, I ran one pass of fetchmail (with --keep) just to see what would happen. What happened is that 1545 messages came in, over a period of several minutes and went.... somewhere...
I figure that they are on my hard disk somewhere in either MBOX format or maildir format (or maybe even mailboxes.db, but I doubt it) and:
a) I don't know where they went.
man fetchmail: As each message is retrieved fetchmail normally delivers it via SMTP to port 25 on the machine it is running on (localhost), just as though it were being passed in over a normal TCP/IP link. The mail will then be delivered locally via your system's MDA (Mail Delivery Agent, usually sendâ mail(8) but your system may use a different one such as smail, mmdf, exim, or qmail). All the delivery-control mechanisms (such as .forward files) normally available through your system MDA and local delivery agents will therefore work automatically. If no port 25 listener is available, but your fetchmail configuration was told about a reliable local MDA, it will use that MDA for local delivery instead. At build time, fetchmail normally looks for executable procmail(1) and sendmail(1) binaries. Is postfix running? Output of "rcpostfix status" If so, output of "mailq"? If no mails are in the queue, look in /var/spoo/mail/username If you can't find it, send output of "postconf -n". Is cyrus running? Output of "rccyrus status" have you set up mailboxes with cyradm?
b) I don't know what format.
QUESTION: What's the most straightforward way to find all that mail (before it gets mysteriously flushed or something), so I can begin to piece together how it's being handled now and what to do to have it handled the way I need?
See above.
QUESTION 2: With only a few users on a few machines, and maybe a couple of hundred thousand messages stored for IMAP serving, is my best server option:
- plain, vanilla imap - courier-imap - Cyrus-imap
Both cyrus and courier are robust and don't use too much resources. I have Cyrus running on an old Dual-PIII-500 server, and it handles users with more than 100.000 mails without problems.
I understand that each of these also has preferred mailbox formats, so where in the mail trail does the incoming mail get mushed into one or another format? It seems to come from the ISP as single files, so I ASSume that the "conversion" to MBOX or maildir or [other option?] takes place either in fetchmail in the next app that handles the mail (procmail? sendmail? postfix?) before it reaches the resting place that imap will use.
Fetchmail -> Postfix ( -> contentfilter SA/Antivirus -> Postfix) -> Imapserver That is the usual way to process Mails with fetchmail.
As for choosing a flavor of IMAP, I just don't know. I don't really want to get into setting up additional authentication databases (sasl? LDAP? other?), but if that would be simpler than the PAM or shadow requirements... well maybe...
PAM is the most simple setup.
Last night, I had 22 browser windows open with a variety of Howtos and FAQs (many contradicting each other) for fetchmail, imap, Cyrus-imap, courier-imap, procmail, postfix, sendmail, qmail (no, I don't think I have qmail installed, but...). Basically I have an overload of info and an underload of knowledge or direction. I gave up and went to bed a 2:30 ... and got up at 5:30... oi!
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
I hate to inform you that the mails you send to this list are being archived in a searchable database, that is also regurlarly queried for addresses by spammers. If that disclaimer is necessary for you then you should probably not post to the list anymore... Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-01-24 at 11:51 -0500, mlist@safenet-inc.com wrote:
- fetchmail grabs mail from my ISP's POP3 server and hands it off to...
The local MTA, probably postfix.
Yesterday, I ran one pass of fetchmail (with --keep) just to see what would happen. What happened is that 1545 messages came in, over a period of several minutes and went.... somewhere...
I figure that they are on my hard disk somewhere in either MBOX format or maildir format (or maybe even mailboxes.db, but I doubt it) and:
My guess is that they will be at /var/spool/mail/{USERNAME}, unless you configured for something else (for instance, using procmail or even kmail). You could read them using "Pine", without configuring anything - probably.
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
¡HA! Don't make me laugh! Forget it. Once sent, the email belongs to the recipient, who is named in the "To" field. If it goes to somebody else, your problem: check more carefully next time. Disclaimers do not apply. If the information is privileged, etc, etc, encrypt it, and do not ever send it to a mail list. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD1oAhtTMYHG2NR9URAmxLAJ9SWXd6yCr7QwTNOAAtTcw6V0QpQQCfcMsP XaZi4b2evv6gGOcb88nECdY= =+iSl -----END PGP SIGNATURE-----
On Wednesday 25 January 2006 02:29, Carlos E. R. wrote:
The Tuesday 2006-01-24 at 11:51 -0500, mlist@safenet-inc.com wrote:
- fetchmail grabs mail from my ISP's POP3 server and hands it off to...
The local MTA, probably postfix.
Yesterday, I ran one pass of fetchmail (with --keep) just to see what would happen. What happened is that 1545 messages came in, over a period of several minutes and went.... somewhere...
I figure that they are on my hard disk somewhere in either MBOX format or maildir format (or maybe even mailboxes.db, but I doubt it) and:
My guess is that they will be at /var/spool/mail/{USERNAME}, unless you configured for something else (for instance, using procmail or even kmail).
You could read them using "Pine", without configuring anything - probably.
Read the thread and have a question. Could somebody put together what the different mail-delivery system do and don't. E.g. if I use Kmail, does this use other agents too? When I use fetchmail which is offered at instalation time in 9.3 to get the mail, does that conflict with Kmail? Are other agents like sendmail and procmail necessary and where do they play a role? What does Pine do that others don't? I find the whole complex of mail delivery complex. Which mail-delivery agent is best for dialup (e.g. every hour) and what would be best for ADSL or cable? Could somebody give some pointers?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-01-25 at 16:40 +0700, C. Brouerius van Nidek wrote:
Read the thread and have a question. Could somebody put together what the different mail-delivery system do and don't. E.g. if I use Kmail, does this use other agents too? When I use fetchmail which is offered at instalation time in 9.3 to get the mail, does that conflict with Kmail?
Kmail, the same as mozilla or evolution, are designed in the "windows" or "outlook" style of doing everything. They are "users" programs. They download the email from remote (or local) servers, from one or several accounts, filter, store, display it, handle answering, and finally, delivery to the outgoing remote smtp server (or local). They don't require postfix, procmail, fetchmail, whatever: they are stand alone programs. Traditionally, though, things in *nix were handled diferently. An MTA server (sendmail, postfix, qmail, whatever) handled talking with other machines "out there". MUAs (mail user agents) simply handled display and composing email, delivery was handled to the MTA. The MTA was configured by the administrator, and you had only one email address. Users really did not need to configure email.
Are other agents like sendmail and procmail necessary and where do they play a role?
Sendmail does the same as postfix, it is an MTA. Choose one you like. Default in SuSE nowdays is postfix. Procmail is an "add on" to the MTA to handle local delivery, providing extra features like filtering or distributing email in different folders, if the user wants. It is very usefull, but not necesary.
What does Pine do that others don't?
It is a "traditional" style of user mail agent - thus, it can read _system_ email without configuration. Kmail, on the other hand, has to be told to also read system email. I mentioned Pine as an easy method of seeing those seemingly lost emails you had - not that I recomend you use Pine for al your email. I like it, but it is not for everybody.
I find the whole complex of mail delivery complex.
It is not. Go one step at a time. :-) There is a good chapter about all this in the SuSE (paper) book.
Which mail-delivery agent is best for dialup (e.g. every hour) and what would be best for ADSL or cable?
Doesn't matter, any. If you tell kmail to send email to the local Mail Transfer Agent (MTA), ie, the local SMTP server, this will send email outside when it has a chance. There are tricks to remind them to send, when using dial up, but I don't configure postfix nor sendmail diferently. Instead, you can tell kmail (or mozillla, or whatever you use) to send to your provider SMTP server. This method usually sends when you tell them to send, or asap, or later - same as outlook. I would recomed you use this method. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD15iytTMYHG2NR9URAjRHAJ4+IHA3etUgYkkZVfayGmtWChOBbACfZ9uw 3OscA8CLdO6YsR9ZT3YoIEI= =Mcyn -----END PGP SIGNATURE-----
On Wednesday 25 January 2006 4:40 am, C. Brouerius van Nidek wrote:
if I use Kmail, does this use other agents too? When I use fetchmail which is offered at instalation time in 9.3 to get the mail, does that conflict with Kmail? I use fetchmail to obtain email from my work imap server or my home ISP's POP server. I also use Postfix as my MTA and most of my email comes through it. At fork, I have KMail configured to use localhost for both inbound (/var/spool/mail/<userid>) and outbound SMTP. At home I have Sylpheed-claws configured to do the same except that some identities specifically use my ISP's server rather than localhost. The real advantage here is that the mail transfers are all done in the background by postfix and fetchmail. At home I use procmail to filter my email, but that can be dangerous in some cases.
One additional advantage I found with KMail is that it would somehow get into a loop trying to read from the imap server. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
* Jerry Feldman <gaf@blu.org> [01-25-06 11:07]:
At home I use procmail to filter my email, but that can be dangerous in some cases.
??? Dangerous ??? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Wednesday 25 January 2006 11:43 pm, Patrick Shanahan wrote:
* Jerry Feldman <gaf@blu.org> [01-25-06 11:07]:
At home I use procmail to filter my email, but that can be dangerous in some cases.
??? Dangerous ??? Yes. In some cases when you use procmail for mail filtering, it is accessing your mail hierarchy in the background at the same time your email client may also be manipulating it, and this can result in lost files. For the most part, procmail does its job properly if the .procmailrc is set up correctly. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
* Jerry Feldman <gaf@blu.org> [01-26-06 08:37]:
In some cases when you use procmail for mail filtering, it is accessing your mail hierarchy in the background at the same time your email client may also be manipulating it, and this can result in lost files.
Then THE mail setup is broken. Procmail is a mail delivery agent and as such should handle mail before the client sees it. If not your client is performing functions that it *should* not. You can do it one way or the other, mixing *will* cause problems and is not as was intended. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Thursday 26 January 2006 9:38 am, Patrick Shanahan wrote:
Then THE mail setup is broken. Procmail is a mail delivery agent and as such should handle mail before the client sees it. If not your client is performing functions that it *should* not. You can do it one way or the other, mixing *will* cause problems and is not as was intended. The reason I use the word, dangerous, is that it is easy to make a mistake. The .procmailrc format is not trivial. You need to make sure that the mail client and procmail are using the same locking strategy.
Take the following situation: 1. The main client uses an MH directory structure. It must scan each directory preiodically to detect new mail. It is configured NOT to "inc" - incorporate imae from /var/spool/man/<user>. 2. Procmail as the delivery agent takes mail from /var/spool/man/<user> and inserts the email into $HOME/Mail/<target mh subdirectory). The problem exists when the mail client may move or delete email. If both procmail and the mail client are using the same locking strategy, then no problem exists. It is a configuration issue, not generally a mail client issue. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
* Jerry Feldman <gaf@blu.org> [01-26-06 09:58]:
2. Procmail as the delivery agent takes mail from /var/spool/man/<user> and inserts the email into $HOME/Mail/<target mh subdirectory).
I don't know why you do this. I take mail from fetchmail and hand it to procmail for delivery. No interference from the client. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
i seem to have fallen and cant get up! looks to me as if some progs want suidperl set to 4755 and others want it at 755. what is the correct setting and is there a way to satisfy all needs for suiderl so everyone is happy both the calls for 4755 and 755?
On Thursday 26 January 2006 18:30, teck wrote:
i seem to have fallen and cant get up! looks to me as if some progs want suidperl set to 4755 and others want it at 755. what is the correct setting and is there a way to satisfy all needs for suiderl so everyone is happy both the calls for 4755 and 755?
Not sure this will answer your question but see the notes on suidperl in /etc/permissions
On Friday 27 January 2006 12:13, Bruce Marshall wrote:
On Thursday 26 January 2006 18:30, teck wrote:
i seem to have fallen and cant get up! looks to me as if some progs want suidperl set to 4755 and others want it at 755. what is the correct setting and is there a way to satisfy all needs for suiderl so everyone is happy both the calls for 4755 and 755?
Not sure this will answer your question but see the notes on suidperl in /etc/permissions
im not really sure if it does answer.. i did read that before. My problem is... ie: Openwebmail wants suidperl set to 4755 When it is set to 4755 it works fine. However it breaks other things ie awstats wont work unless its set to 755. Is /etc/permissions telling me I can set sperl to 4755 and edit the scripts to sperl instead of suidperl ?
On Friday 27 January 2006 11:25, teck wrote:
im not really sure if it does answer.. i did read that before. My problem is...
ie: Openwebmail wants suidperl set to 4755 When it is set to 4755 it works fine. However it breaks other things ie awstats wont work unless its set to 755. Is /etc/permissions telling me I can set sperl to 4755 and edit the scripts to sperl instead of suidperl ?
I gave up perl for python quite awhile ago so I couldn't answer that. But why not make a copy of things that you change (before changing) and see how it goes?
try this: chmod 555 /usr/bin/suidperl chmod 4555 /usr/bin/sperl5.8.7 And try to run your openwebmail Hope this helps! _________________________________________________________ Lawrence Ferreira AIX, HP-UX and SuSE Linux Enterprise Server Administrator LINUX User (openSUSE-10.0 & SLES9) #271016 LPIC-1 - Linux Certified Professional teck wrote:
On Friday 27 January 2006 12:13, Bruce Marshall wrote:
On Thursday 26 January 2006 18:30, teck wrote:
i seem to have fallen and cant get up! looks to me as if some progs want suidperl set to 4755 and others want it at 755. what is the correct setting and is there a way to satisfy all needs for suiderl so everyone is happy both the calls for 4755 and 755? Not sure this will answer your question but see the notes on suidperl in /etc/permissions
im not really sure if it does answer.. i did read that before. My problem is...
ie: Openwebmail wants suidperl set to 4755 When it is set to 4755 it works fine. However it breaks other things ie awstats wont work unless its set to 755. Is /etc/permissions telling me I can set sperl to 4755 and edit the scripts to sperl instead of suidperl ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-01-26 at 18:23 -0500, Patrick Shanahan wrote:
* Jerry Feldman <gaf@blu.org> [01-26-06 09:58]:
2. Procmail as the delivery agent takes mail from /var/spool/man/<user> and inserts the email into $HOME/Mail/<target mh subdirectory).
I don't know why you do this. I take mail from fetchmail and hand it to procmail for delivery. No interference from the client.
Because what he does is the normal method, I also use it. fetchmail -> postfix -> procmail -> user choosen directory and folder - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD2V95tTMYHG2NR9URAnJoAJ9x+VDlmnoEqEmHn6VYIKlnBt/JfgCfYE+j rzBDQsjdQIUJagTXqNd/uag= =fX+Z -----END PGP SIGNATURE-----
* Carlos E. R. <robin1.listas@tiscali.es> [01-26-06 18:49]:
Because what he does is the normal method, I also use it.
fetchmail -> postfix -> procmail -> user choosen directory and folder
Yes, I left out a step, postfix. But the mail is still handled by procmail *before* the client has access. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-01-26 at 20:42 -0500, Patrick Shanahan wrote:
fetchmail -> postfix -> procmail -> user choosen directory and folder
Yes, I left out a step, postfix. But the mail is still handled by procmail *before* the client has access.
Ah. It is possible for the MUA to be accessing the same folder where procmail is about to store a new email. And it is possible that the user is also about to compose an email - it should be on a diferent folder, though. A situation that happens if the folder is of type "mbox", is that procmail is adding a new email at the end, while the MUA is removing another one from the middle. Even worse, the MUA could be compacting the folder. The way to avoid this is using a locking mechanism, but each program uses a diferent method, and procmail can be told about it - except that diferent MUAs use diferent locks :-( Of course, using maildir folders the problem is not so bad. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD2YmTtTMYHG2NR9URAkxlAJ41/AezNlvaeEMBgR8GfpCUMXNfuACfX+lq gtZZLPTRbIRBPKSjCAeZcv4= =J3YA -----END PGP SIGNATURE-----
* Carlos E. R. <robin1.listas@tiscali.es> [01-26-06 21:50]:
A situation that happens if the folder is of type "mbox", is that procmail is adding a new email at the end, while the MUA is removing another one from the middle. Even worse, the MUA could be compacting the folder. The way to avoid this is using a locking mechanism, but each program uses a diferent method, and procmail can be told about it - except that diferent MUAs use diferent locks :-(
Of course, using maildir folders the problem is not so bad.
pat@wahoo:~> mutt -v +USE_DOTLOCK man procmail /var/spool/mail/$LOGNAME.lock lockfile for the system mailbox (not automatically used by procmail, unless $DEFAULT equals /var/spool/mail/$LOGNAME and procmail is delivering to $DEFAULT) -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-01-26 at 23:06 -0500, Patrick Shanahan wrote:
pat@wahoo:~> mutt -v +USE_DOTLOCK
man procmail /var/spool/mail/$LOGNAME.lock lockfile for the system mailbox (not automatically used by procmail, unless $DEFAULT equals /var/spool/mail/$LOGNAME and procmail is delivering to $DEFAULT)
Not only that one. I have perhaps a dozen input mboxes under /home/user/Mail/in_whatever, where procmail distributes email, and Pine reads (and deletes) from there. Lockfiles are needed. I think I have it right, but not 100% sure. Then, other times I use kmail, with the same folders. Do kmail uses the same lockfiles, or do I have to tell it? I think the later. Other times I use mozilla: this one never notices when procmail delivers email. I have to close and restart mozilla :-( Till now, it hasn't been a problem, because I don't have a permanent network connection. If that changes, I'll have to think it over. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD2gUitTMYHG2NR9URApCSAJ91Z2uYW84whrgf9BlnLTPpmjrfZQCfePwD 8gmntP82X9LsW7V+XQtbSpU= =hCu6 -----END PGP SIGNATURE-----
* Carlos E. R. <robin1.listas@tiscali.es> [01-27-06 06:54]:
Not only that one. I have perhaps a dozen input mboxes under /home/user/Mail/in_whatever, where procmail distributes email, and Pine reads (and deletes) from there. Lockfiles are needed. I think I have it right, but not 100% sure.
Then, other times I use kmail, with the same folders. Do kmail uses the same lockfiles, or do I have to tell it? I think the later.
No, you must tell kmail to use locks and the method. See: http://wahoo.no-ip.org/~pat/kmail.lock.jpg -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Thursday 26 January 2006 20:42, Patrick Shanahan wrote:
* Carlos E. R. <robin1.listas@tiscali.es> [01-26-06 18:49]:
Because what he does is the normal method, I also use it.
fetchmail -> postfix -> procmail -> user choosen directory and folder
Yes, I left out a step, postfix. But the mail is still handled by procmail *before* the client has access.
I think you had it right the first time... :-) I go directly to procmail using the following in my fetchmailrc: mda "/usr/bin/procmail -f %F -d %T " Would seem to be more efficient.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-01-27 at 10:36 -0500, Bruce Marshall wrote:
I think you had it right the first time... :-)
I go directly to procmail using the following in my fetchmailrc:
mda "/usr/bin/procmail -f %F -d %T "
Would seem to be more efficient.
In cpu usage, yes. But it bypasses the filtering controls the MDA offers, not forgetting amavis-new. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD2mW0tTMYHG2NR9URApTIAKCClFJmfK52tJZer3McnNpo1N6jIgCfRbKM 3PTEv5E/qf2JLlWqyWmY8A8= =1QOG -----END PGP SIGNATURE-----
* Bruce Marshall <bmarsh@bmarsh.com> [01-27-06 10:36]:
I think you had it right the first time... :-)
I go directly to procmail using the following in my fetchmailrc:
mda "/usr/bin/procmail -f %F -d %T "
Would seem to be more efficient.
I did but changed it some time ago, but do not now remember why. Oldtimers is catching up, I guess.... -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
One thing I forgot to mention is that both fetchmail and postfix (and sendmail) log every transaction so that if you are trying to track down a mail issue you have the fetchmail or postfix (/var/log/mail) logs. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
participants (9)
-
Bruce Marshall -
C. Brouerius van Nidek -
Carlos E. R. -
Jerry Feldman -
Lawrence Ferreira -
mlist＠safenet-inc.com -
Patrick Shanahan -
Sandy Drobic -
teck