Menu
▾
▴
fetchmail-users
|
From: <arr...@ra...> - 2014-10-16 00:41:02
|
I am running Mageia 4.0 which includes fetchmail 6.3.26. The following is my
entire /etc/fetchmailrc:
set postmaster "arromdee"
set bouncemail
set no spambounce
set softbounce
set properties ""
poll mail.xxxxxx.net with proto POP3
user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d arromdee"
I want to run fetchmail as a service, for which Mageia supplies a script in
/etc/rc.d. I want it to retrieve the mail from user arromdee on the remote
system and deliver it to user arromdee on my local machine.
This /etc/fetchmailrc does work. However, I want to be able to put the
appropriate lines in my user-specific $HOME/.fetchmailrc, not in the global
/etc/fetchmailrc. How can I do this? It doesn't seem like my user-specific
.fetchmailrc is read at all (unless I run fetchmail as myself instead of as
root).
|
|
From: Matthias A. <mat...@gm...> - 2014-10-17 07:55:41
|
Am 16.10.2014 um 02:40 schrieb Ken Arromdee: > I am running Mageia 4.0 which includes fetchmail 6.3.26. The following is my > entire /etc/fetchmailrc: > > set postmaster "arromdee" > set bouncemail > set no spambounce > set softbounce > set properties "" > poll mail.xxxxxx.net with proto POP3 > user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d arromdee" > > I want to run fetchmail as a service, for which Mageia supplies a script in > /etc/rc.d. I want it to retrieve the mail from user arromdee on the remote > system and deliver it to user arromdee on my local machine. > > This /etc/fetchmailrc does work. However, I want to be able to put the > appropriate lines in my user-specific $HOME/.fetchmailrc, not in the global > /etc/fetchmailrc. How can I do this? It doesn't seem like my user-specific > .fetchmailrc is read at all (unless I run fetchmail as myself instead of as > root). True on many systems. You absolutely need to make sure that fetchmail is being started as "aromdee", not root. Check if your boot scripts support this -- on many systems, they do not. You can however configure fetchmail for daemon mode and launch it from cron - if it's already running, the second attempt to start it will instead wake up the first instance. Note that I advise against using procmail. It has been unmaintained for more than a decade and has design flaws that cause apparent mail "loss" (which are not loss but in fact a fallback behaviour that causes procmail to _misfile_ mail in error situations, and - albeit possible - are hard to overcome by procmail recipes). |
|
From: Gene H. <ghe...@wd...> - 2014-10-17 08:30:20
|
On Friday 17 October 2014 03:55:32 Matthias Andree did opine And Gene did reply: > Am 16.10.2014 um 02:40 schrieb Ken Arromdee: > > I am running Mageia 4.0 which includes fetchmail 6.3.26. The > > following is my > > > > entire /etc/fetchmailrc: > > set postmaster "arromdee" > > set bouncemail > > set no spambounce > > set softbounce > > set properties "" > > poll mail.xxxxxx.net with proto POP3 > > > > user 'arromdee' password 'xxxxxxxx' mda "/bin/procmail -d > > arromdee" > > > > I want to run fetchmail as a service, for which Mageia supplies a > > script in /etc/rc.d. I want it to retrieve the mail from user > > arromdee on the remote system and deliver it to user arromdee on my > > local machine. > > > > This /etc/fetchmailrc does work. However, I want to be able to put > > the appropriate lines in my user-specific $HOME/.fetchmailrc, not in > > the global /etc/fetchmailrc. How can I do this? It doesn't seem > > like my user-specific .fetchmailrc is read at all (unless I run > > fetchmail as myself instead of as root). > > True on many systems. You absolutely need to make sure that fetchmail > is being started as "aromdee", not root. Check if your boot scripts > support this -- on many systems, they do not. > > You can however configure fetchmail for daemon mode and launch it from > cron - if it's already running, the second attempt to start it will > instead wake up the first instance. > > > Note that I advise against using procmail. It has been unmaintained > for more than a decade and has design flaws that cause apparent mail > "loss" (which are not loss but in fact a fallback behaviour that > causes procmail to _misfile_ mail in error situations, and - albeit > possible - are hard to overcome by procmail recipes). > Humm, since I have been using procmail for about a decade now, and am aware of its unsupported status simply because there have been no updates in several years, and it hasn't made any mistakes that I have become aware of, what do you suggest as its most painfree replacement? Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS |
|
From: Matthias A. <mat...@gm...> - 2014-10-17 16:13:56
|
Am 17.10.2014 um 10:30 schrieb Gene Heskett: > Humm, since I have been using procmail for about a decade now, and am > aware of its unsupported status simply because there have been no updates > in several years, and it hasn't made any mistakes that I have become aware > of, what do you suggest as its most painfree replacement? Would you notice if single messages ended up in the wrong folder - especially if you do not know that messages have been file in some other place where you do not expect it to be? Personally I prefer maildrop, http://www.courier-mta.org/maildrop.html |
|
From: Gene H. <ghe...@wd...> - 2014-10-17 20:08:24
|
On Friday 17 October 2014 12:13:45 Matthias Andree did opine And Gene did reply: > Am 17.10.2014 um 10:30 schrieb Gene Heskett: > > Humm, since I have been using procmail for about a decade now, and am > > aware of its unsupported status simply because there have been no > > updates in several years, and it hasn't made any mistakes that I > > have become aware of, what do you suggest as its most painfree > > replacement? > > Would you notice if single messages ended up in the wrong folder - > especially if you do not know that messages have been file in some > other place where you do not expect it to be? > With my current config, there are only 3 places it puts an incoming mail. If SA goes off, it goes on thru to my /var/spool/mail/gene mailfile. If its from a niece, that goes to a separate mailfile. If its a clamav detected viri it gets put in a third viri file. All other sorting is done by kmail itself as it gets a dbus signal to go and get any newly arrived mail in my mailfile or in the nieces mailfile. Thats also owned by me, and kmail sorts that to a maildir holding her messages. Some specific recipes also send crap to /dev/null. Might be 100 of those. > Personally I prefer maildrop, http://www.courier-mta.org/maildrop.html And this is a currently well supported filtering MTA that can do what procmail is doing now? I'll go look at it, thanks. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS |
|
From: Matthias A. <mat...@gm...> - 2014-10-20 07:20:24
|
Am 17.10.2014 um 22:08 schrieb Gene Heskett: > With my current config, there are only 3 places it puts an incoming mail. Yes. But unless you code error handling yourself with one :0e recipe that adds error handling after *each* delivering recipe, procmail will happily try a later file if it cannot write to one listed earlier. As though your original recipe hadn't been there. http://www.dovecot.org/list/dovecot/2007-August/024910.html https://docs.kde.org/stable/en/kdepim/kmail/faq.html#idp13808496 >> Personally I prefer maildrop, http://www.courier-mta.org/maildrop.html > > And this is a currently well supported filtering MTA that can do what > procmail is doing now? I'll go look at it, thanks. It's got a syntax I find easier to read and can do more or less what procmail can do, and it is being maintained. |
|
From: Carlos E. R. <car...@op...> - 2014-10-25 14:44:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-10-17 at 16:08 -0400, Gene Heskett wrote: > On Friday 17 October 2014 12:13:45 Matthias Andree did opine >> Personally I prefer maildrop, http://www.courier-mta.org/maildrop.html > > And this is a currently well supported filtering MTA that can do what > procmail is doing now? I'll go look at it, thanks. In my system, installing "standalone" maildrop (which is not available in the standard repositories, but in server:mail) requires installing something more that I do not want: Telcontar:~ # zypper --no-refresh in maildrop Loading repository data... Reading installed packages... Resolving package dependencies... The following 3 NEW packages are going to be installed: courier-authlib courier-imap maildrop And I'm not prepared to install courier-imap as I'm afraid would cause problems with the already running dovecot (imap). I had a look at maildrop.html and maildropfilter.html. It appears a powerful but complex tool. The language is described (it's a man page, so it's man's style), but there are no examples that I could find. Translating my 1500 lines of procmail would be daunting, so I prefer not to even try. If I had to, I would look at a specific tool for dovecot instead. One of the things about procmail is that it does not matter if I use dovecot or plain folders. Yes, it has some caveats. If a recipe is broken, email can be dropped in the next, unrelated, folder. But I know how to cope with that... I have not yet lost a single email. Yet :-) But yes, I would like a _generic_, fully mantained, procmail thing or replacement. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRLtyoACgkQtTMYHG2NR9XWRgCgmDT0O6r9U9Meoy/yzFrY34vu eLYAn3ce1kc2b8KaS5WvgGWkQXsQTYEn =dzkQ -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2014-10-25 16:18:20
|
Am 25.10.2014 um 16:43 schrieb Carlos E. R.: > In my system, installing "standalone" maildrop (which is not available in > the standard repositories, but in server:mail) requires installing > something more that I do not want: > > Telcontar:~ # zypper --no-refresh in maildrop > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > The following 3 NEW packages are going to be installed: > courier-authlib courier-imap maildrop If maildrop requires courier-imap then the packaging is broken. Contact the packager or file a bug report and, since it's SUSE, hope someone reads it and deals with it. courier-authlib should suffice as requisite package. Also check if courier-imap is only "recommended" or required. > And I'm not prepared to install courier-imap as I'm afraid would cause > problems with the already running dovecot (imap). Only if you actually launch it at boot-time. There is a way to defeat that, but I'm not familiar with the systemd bloat. > I had a look at maildrop.html and maildropfilter.html. It appears a > powerful but complex tool. The language is described (it's a man page, so > it's man's style), but there are no examples that I could find. Check the maildropex manual page or HTML file, there are examples in the other manuals, too. > But yes, I would like a _generic_, fully mantained, procmail thing or > replacement. I have not found the need to try and convert procmail weighted scoring stuff, but everything else I ever used (and I had multi-hundred line procmailrc files once upon a time) could be transferred to maildrop. |
|
From: Carlos E. R. <car...@op...> - 2014-10-25 19:19:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-25 18:18, Matthias Andree wrote: > Am 25.10.2014 um 16:43 schrieb Carlos E. R.: > package. Also check if courier-imap is only "recommended" or > required. You are right, it is a recommendation. >> And I'm not prepared to install courier-imap as I'm afraid would >> cause problems with the already running dovecot (imap). > > Only if you actually launch it at boot-time. There is a way to > defeat that, but I'm not familiar with the systemd bloat. I am, but it is one thing more to do ;-) >> I had a look at maildrop.html and maildropfilter.html. It appears >> a powerful but complex tool. The language is described (it's a >> man page, so it's man's style), but there are no examples that I >> could find. > > Check the maildropex manual page or HTML file, there are examples > in the other manuals, too. Ah, that one I had not seen, thanks. (not may examples, though). >> But yes, I would like a _generic_, fully mantained, procmail >> thing or replacement. > > I have not found the need to try and convert procmail weighted > scoring stuff, but everything else I ever used (and I had > multi-hundred line procmailrc files once upon a time) could be > transferred to maildrop. Not weighted scoring, but "simple" filtering. Many folders and formail calls. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRL96AACgkQtTMYHG2NR9WrVACfXpbhBY5AS2e/c3qZlDrOQuJT L1gAn1Fzt8Q8z3KYN+hjif3Mn8iCLukE =4KQe -----END PGP SIGNATURE----- |
|
From: Carlos E. R. <car...@op...> - 2014-10-17 20:41:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-17 10:30, Gene Heskett wrote: > On Friday 17 October 2014 03:55:32 Matthias Andree did opine And > Gene did reply: >> Note that I advise against using procmail. It has been >> unmaintained for more than a decade and has design flaws that >> cause apparent mail "loss" (which are not loss but in fact a >> fallback behaviour that causes procmail to _misfile_ mail in >> error situations, and - albeit possible - are hard to overcome by >> procmail recipes). >> > Humm, since I have been using procmail for about a decade now, and > am aware of its unsupported status simply because there have been > no updates in several years, and it hasn't made any mistakes that I > have become aware of, what do you suggest as its most painfree > replacement? It simply has not needed updates. I would not call it "unmaintained", but "mature". Millions of systems use it. In the changelog of my distribution, I see its recent maintenance updates, some coming from other distributions. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlRBfwkACgkQtTMYHG2NR9WyFgCfQvnvFRJC4f/E/fbzuShxRS6q aIQAnikt/tH1hiJwbGKCwMmquOThg6/0 =C7Rt -----END PGP SIGNATURE----- |
|
From: Matthias A. <mat...@gm...> - 2014-10-20 07:30:57
|
Am 17.10.2014 um 22:41 schrieb Carlos E. R.: > It simply has not needed updates. I would not call it "unmaintained", > but "mature". Millions of systems use it. Eat more dung, millions of flies cannot all be wrong. It is not as if the majority of these "millions" of systems made a deliberate decision, it just shipped with many of those by default (some even as a required component of the base install), before we had better alternatives. > In the changelog of my distribution, I see its recent maintenance > updates, some coming from other distributions. Meaning upstream is dead, no-one bothers to fork/revive it, and the distro version bug sets fall asunder. The list archive no longer exists, several links on procmail.org go to domains that are no longer, and procmail never added clear comments on error handling to its manual pages, you'd have to grab those from someone else. If you just go by procmailex you'll find that you missed error handling once the disk fills up or goes read-only or similar. If that's a temporary condition, you'll see mail delivery gets erratic. Fixing that is possible, but it at least doubles the number of your .procmailrc recipes and clutters the file. |
|
From: Matthias A. <mat...@gm...> - 2014-10-25 19:20:50
|
Am 25.10.2014 um 20:27 schrieb Peter Pentchev: > On Sat, Oct 25, 2014 at 06:18:11PM +0200, Matthias Andree wrote: >> Am 25.10.2014 um 16:43 schrieb Carlos E. R.: >> >>> In my system, installing "standalone" maildrop (which is not available in >>> the standard repositories, but in server:mail) requires installing >>> something more that I do not want: >>> >>> Telcontar:~ # zypper --no-refresh in maildrop >>> Loading repository data... >>> Reading installed packages... >>> Resolving package dependencies... >>> >>> The following 3 NEW packages are going to be installed: >>> courier-authlib courier-imap maildrop >> >> If maildrop requires courier-imap then the packaging is broken. Contact >> the packager or file a bug report and, since it's SUSE, hope someone >> reads it and deals with it. courier-authlib should suffice as requisite >> package. Also check if courier-imap is only "recommended" or required. > > It's possible that the situation is similar, although maybe reversed, to > the one in Debian. There are actually two maildrop packages in Debian - > the one named "maildrop" is the standalone MDA, and the one named > "courier-maildrop" is the version that is much more closely integrated > with the rest of the Courier MTA suite. I'm not very familiar with the > SuSE packaging system, so I cannot really check right now, but Carlos, > is it possible that there are two packages there, too? I check the openSUSE repos once again. The trick to avoid courier-imap is installing maildrop-maildirutils before installing maildrop. Alternatively, enabling the entire server:mail repository might work, too, but will also exchange postfix, amavis, bogofilter, getmail and related other packages... # zypper ar http://download.opensuse.org/repositories/server:/mail/openSUSE_13.1/server:mail.repo # zypper in maildrop-maildirutils maildrop should do the trick. This is more intrusive, however. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X