Menu
▾
▴
fetchmail-users
|
From: James M. <ji...@so...> - 2006-07-10 20:51:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, There seems to be no built in mechanism for limiting the size of the log file. It grows without bound. I have tried renaming it but fetchmail does not create a new one and all further logging is lost. Logrotate looks like a useful tool for managing the log files. Does fetchmail act the same way, stop logging, when logrotate changes the file names? Or must I stop fetchmail, rename the log file, restart fetchmail? fetchmail v6.3.4 - -- jimoe (at) sohnen-moe (dot) com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (OS/2) iD8DBQFEsqGdzTcr8Prq0ZMRAsAxAKCh5VmdtzD6UkRbi3NanxkqCABHaACePS0Z Wv8S5NBFMoCWl7Rbhpkti7U= =/F95 -----END PGP SIGNATURE----- |
|
From: Rob M. <rob...@gm...> - 2006-07-10 21:32:51
|
On 7/10/06, James Moe <ji...@so...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
> There seems to be no built in mechanism for limiting the size of the log
> file. It grows without bound. I have tried renaming it but fetchmail does
> not create a new one and all further logging is lost.
> Logrotate looks like a useful tool for managing the log files. Does
> fetchmail act the same way, stop logging, when logrotate changes the file
> names?
> Or must I stop fetchmail, rename the log file, restart fetchmail?
Have you considered using syslog instead of logfile?
Fetchmail currently only opens the logfile at startup. To get it to
close the logfile you'd have to restart (or supply a patch).
(Oh, and technically the further logging isn't lost - under *nix it's
legal to open a file and then delete it. The file isn't removed from
disk until it's closed. This is useful for temporary files.)
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Stephen A. <fet...@ro...> - 2006-07-10 21:49:16
|
Rob MacGregor wrote: > Have you considered using syslog instead of logfile? That would be a good idea if you could control more of what gets logged there. At the moment, my fetchmail daemon runs every 180 seconds and checks email from half-a-dozen POP3 servers. Most of it's log is filled with: fetchmail: sleeping at Mon 10 Jul 2006 20:25:26 BST fetchmail: awakened at Mon 10 Jul 2006 20:28:26 BST fetchmail: sleeping at Mon 10 Jul 2006 20:28:51 BST fetchmail: awakened at Mon 10 Jul 2006 20:31:51 BST fetchmail: sleeping at Mon 10 Jul 2006 20:32:16 BST fetchmail: awakened at Mon 10 Jul 2006 20:35:16 BST fetchmail: sleeping at Mon 10 Jul 2006 20:35:43 BST fetchmail: awakened at Mon 10 Jul 2006 20:38:43 BST fetchmail: sleeping at Mon 10 Jul 2006 20:39:09 BST fetchmail: awakened at Mon 10 Jul 2006 20:42:09 BST fetchmail: sleeping at Mon 10 Jul 2006 20:42:40 BST However, I *do* want to see messages like: fetchmail: 1 message for us...@do... at POP3-1 (2353 octets). fetchmail: reading message us...@do...@pop.isp.com:1 of 1 (2353 octets) fetchmail: flushed As far as I know at the moment, it's all or nothing. Steve :) |
|
From: Rob M. <rob...@gm...> - 2006-07-10 23:25:43
|
[ Please don't CC me on list traffic ]
On 7/10/06, Stephen Allen <fet...@ro...> wrote:
> Rob MacGregor wrote:
> > Have you considered using syslog instead of logfile?
>
> That would be a good idea if you could control more of what gets logged
> there. At the moment, my fetchmail daemon runs every 180 seconds and
> checks email from half-a-dozen POP3 servers. Most of it's log is filled
> with:
>
> fetchmail: sleeping at Mon 10 Jul 2006 20:25:26 BST
> fetchmail: awakened at Mon 10 Jul 2006 20:28:26 BST
<---SNIP--->
> However, I *do* want to see messages like:
>
> fetchmail: 1 message for us...@do... at POP3-1 (2353 octets).
> fetchmail: reading message us...@do...@pop.isp.com:1 of 1 (2353
> octets) fetchmail: flushed
>
> As far as I know at the moment, it's all or nothing.
For what you're after, yes. I'll admit that I only see log entries
from fetchmail when things go wrong. Everything else would only be
duplicating what my MTA logs anyway...
However, if you run syslog-ng you could easily weed out the messages
you don't want. I've done that on a number of systems, using the
pattern matching to avoid logging pointless stuff. Probably easier
than patching fetchmail, and arguing over what messages should go at
what verbosity level :)
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2006-07-11 14:22:53
|
"Rob MacGregor" <rob...@gm...> writes: >> fetchmail: sleeping at Mon 10 Jul 2006 20:25:26 BST >> fetchmail: awakened at Mon 10 Jul 2006 20:28:26 BST > > However, if you run syslog-ng you could easily weed out the messages > you don't want. I've done that on a number of systems, using the > pattern matching to avoid logging pointless stuff. Probably easier > than patching fetchmail, and arguing over what messages should go at > what verbosity level :) There's a bug report/patching "war" in the Debian system going on for many a month... Some users want these sleeping/awakened messages logged, others don't, so whenever one fix is made to close a bug report, the other group files a bug report... Looks like a switch is needed for these particular messages in the long run. Since I tend to think that uninteresting messages can be filtered out easily with egrep -v or syslog-ng or whatever and checking new mail every 3 minutes abusive (if you need real-time delivery, either use IMAP with IDLE or SMTP or UUCP over TCP/IP, I'll say we keep these for the nonce. These particular messages for the 6.3.X series will stay in so that 6.3.X releases are compatible with each other. -- Matthias Andree |
|
From: Michelle K. <lin...@fr...> - 2006-08-11 18:30:19
|
Am 2006-07-10 20:46:36, schrieb Stephen Allen:
> Rob MacGregor wrote:
> >Have you considered using syslog instead of logfile?
>
> That would be a good idea if you could control more of what gets logged
> there. At the moment, my fetchmail daemon runs every 180 seconds and
> checks email from half-a-dozen POP3 servers. Most of it's log is filled
> with:
Do not run it ad daemont but from your crontab with
*/3 * * * * <user> fetchmail --logfile /path/`date +%Y-%m-%d`.log
which will write dayly named logs
Greetings
Michelle Konzack
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Matthias A. <mat...@gm...> - 2006-07-11 14:22:41
|
James Moe <ji...@so...> writes: > Hello, > There seems to be no built in mechanism for limiting the size of the log > file. It grows without bound. I have tried renaming it but fetchmail does > not create a new one and all further logging is lost. > Logrotate looks like a useful tool for managing the log files. Does > fetchmail act the same way, stop logging, when logrotate changes the file > names? > Or must I stop fetchmail, rename the log file, restart fetchmail? > > fetchmail v6.3.4 For the time being, you will need to restart fetchmail unfortunately. I've put on my TODO list the suggestion to handle closing/reopening log files for the next fetchmail version. -- Matthias Andree |
|
From: James M. <ji...@so...> - 2006-07-11 19:39:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Andree wrote: >> There seems to be no built in mechanism for limiting the size of the log >> file. It grows without bound. I have tried renaming it but fetchmail does >> not create a new one and all further logging is lost. >> Logrotate looks like a useful tool for managing the log files. Does >> fetchmail act the same way, stop logging, when logrotate changes the file >> names? >> Or must I stop fetchmail, rename the log file, restart fetchmail? >> > For the time being, you will need to restart fetchmail > unfortunately. > > I've put on my TODO list the suggestion to handle closing/reopening log > files for the next fetchmail version. > Okay. Thanks! - -- jimoe (at) sohnen-moe (dot) com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (OS/2) iD8DBQFEs+JkzTcr8Prq0ZMRAoQnAKCU2jqkqCMuBhh7jwzlfU3uNthyngCfTl6A llTl4pe2aBgrV6ro6//F25A= =fCx/ -----END PGP SIGNATURE----- |
|
From: Uli Z. <ul...@ri...> - 2006-07-12 00:38:02
|
Am 11.07.2006 um 11:37 schrieb Matthias Andree:
> checking new mail every 3 minutes [is] abusive
Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most
of the people I know that use fetchmail use something between 60 and
120 seconds, but personally I don't know anyone who would use an
interval longer than 120 seconds.
> (if you need real-time delivery, either use IMAP with IDLE or SMTP
> or UUCP over TCP/IP
As far as I can see, none of these protocols is a functionally
identical replacement for fetchmail. I don't know IMAP more closely,
but to update the local mail client with regard to new emails, I
figure some constant polling must go on, too. Besides, few ISPs
support IMAP. Hardly any ISP supports SMTP or UUCP, and they don't
work well with connections that are not always on.
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Ed W. <ew...@ew...> - 2006-07-12 13:39:50
|
On Wed, Jul 12, 2006 at 12:37:51AM +0200, Uli Zappe wrote:
> Am 11.07.2006 um 11:37 schrieb Matthias Andree:
>
> >checking new mail every 3 minutes [is] abusive
>
> Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most
> of the people I know that use fetchmail use something between 60 and
> 120 seconds, but personally I don't know anyone who would use an
> interval longer than 120 seconds.
I schedule fetchmail from cron and run it every 5 minutes during the day
and every 20 minutes overnight. On average, I have to wait 2.5 minutes
for an email to arrive. That's plenty fast enough. If I'm on the
phone with somebody and know they've sent the email and I need to look
at it during the conversation, I just kick off a manual fetchmail run.
> >(if you need real-time delivery, either use IMAP with IDLE or SMTP
> >or UUCP over TCP/IP
If you need real-time delivery, use a telephone. I my brother emails me
a picture of his flower garden, do I really, really care if it arrives
in 30 seconds or in 5 minutes?
.../Ed
--
Ed Wilts, Mounds View, MN, USA
mailto:ew...@ew...
|
|
From: Michelle K. <lin...@fr...> - 2006-08-11 18:30:32
|
Am 2006-07-12 00:37:51, schrieb Uli Zappe: > Am 11.07.2006 um 11:37 schrieb Matthias Andree: > > >checking new mail every 3 minutes [is] abusive > > Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most > of the people I know that use fetchmail use something between 60 and > 120 seconds, but personally I don't know anyone who would use an > interval longer than 120 seconds. Even if my ISP allow me to do it, <frrenet.de> is hosting arround 5 million mailboxes on around 90 Servers, which mean, 55.000 mailboxes per <mboxXX.freenet.de>. If all peoples would use such intervall, no server will handle this load... Since I have over 600 Mailboxes to poll, located on around 40 mbox- server I poll it only serial and then only all 10 minutes which is enough. Many of those mailboxes must be processed independatly from a MUA, so changing a MUA to use IMAP over the internet does not work. (I have my own local Courier running and ALL mails need preprocessing) Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ ##################### Debian GNU/Linux Consultant ##################### Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Matthias A. <mat...@gm...> - 2006-07-12 08:05:46
|
On Wed, 12 Jul 2006, Uli Zappe wrote: > Am 11.07.2006 um 11:37 schrieb Matthias Andree: > > >checking new mail every 3 minutes [is] abusive > > Oooops!?! How so? I use 30 seconds as poll interval. Admittedly, most > of the people I know that use fetchmail use something between 60 and > 120 seconds, but personally I don't know anyone who would use an > interval longer than 120 seconds. And I even considered warning of deamon intervals shorter than 5 minutes. In fact, with many sites, polling in shorter intervals just earns you a lockout. And it's not like a polling interval of 5, 10 or 15 minutes made a real difference. Trying short poll intervals with "keep" doesn't work too well either. > >(if you need real-time delivery, either use IMAP with IDLE or SMTP > >or UUCP over TCP/IP > > As far as I can see, none of these protocols is a functionally > identical replacement for fetchmail. I don't claim they are. In fact, SMTP and UUCP don't require fetchmail at all. > I don't know IMAP more closely, > but to update the local mail client with regard to new emails, I > figure some constant polling must go on, too. That's what IMAP's IDLE extension is for, with that, the client will be notified of new messages without having to reconnect often. Unfortunately, this works only well in 6.3.4 and only if fetchmail is polling one account only. -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-07-12 15:01:22
|
Am 12.07.2006 um 08:05 schrieb Matthias Andree:
> And I even considered warning of deamon intervals shorter than 5
> minutes. In fact, with many sites, polling in shorter intervals
> just earns you a lockout.
I know this behavior from the pop mail server of my university.
However, the critical interval that triggers a lockout after a few
trials is 10 seconds (which sounds reasonable to me).
> And it's not like a polling interval of 5, 10 or 15 minutes made a
> real difference.
I've never heard of that. Just as a comparison, Mac OS X's Mail
application lets you choose polling intervals just in fixed steps via
a pop-up. The available intervals are 1, 5, 15, 30 and 60 minutes,
with 5 minute the default value. Judging from the respective
discussion groups and personal experience, however, many Mac users
switch the pop-up to 1 minute. Again, I never heard anyone complain
that his wouldn't work.
> Trying short poll intervals with "keep" doesn't work too well either.
What could possibly go wrong?
> In fact, SMTP and UUCP don't require fetchmail at all.
Of course - but they require a specific server setup. I suppose most
if not all ISPs would rather take care that their mail servers can
handle short polling intervals of their customers, than offer an
alternative SMTP solution which adds a lot of complexity for them.
Complexity is more expensive than faster hardware.
Also, this would only be reasonably easy to configure if the client
machine had a fixed IP address. Not even one common fixed IP for a
local network (via NAT) would work as soon as more than one machine
in the local networks wanted to receive its specific mails. Yes, you
could differentiate the machines by private SMTP ports and respective
NAT translation, but this gets all too complex for a general purpose
setup. And note that even if IPv6 was already standard, and you could
easily get as many IPs of your own as you wanted, many people would
still prefer an NAT solution for their local network because of
security reasons.
Besides, an SMTP solution has its disadvantages if you want to switch
between receiving your mail at home/work and with a laptop on the
road (where POP/IMAP are the only sensible solutions if you still
want all your mails on your desktop machine in the end).
I have my own mail server that I can set up any way I want, and I
considered using SMTP, but found POP with short polling intervals
much more practical in the end.
Of course, the ideal solution technically would be a mail server that
delivers mail directly via SMTP as long as this works, and
immediately switches to POP when the recipient's computer isn't
connected to the network anymore. If the recipient connects its
machine to the network again, it should fetch all mails from the POP
account that arrived while she/he was disconnected, and then send a
special command to the server that tells it to switch to direct SMTP
delivery again. (This last step would be necessary because it could
be that the mails where fetched from a laptop on the road, in which
case you wouldn't want to resume SMTP delivery to your desktop
machine afterwards.) But as long as there aren't any pre-configured
software solutions for the server and the client side, I doubt that
such a complex solution will ever happen.
"Brute-force fetchmailing" ;-)) is just so much easier ...
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Matthias A. <mat...@gm...> - 2006-07-12 18:15:18
|
On Wed, 12 Jul 2006, Uli Zappe wrote: > Am 12.07.2006 um 08:05 schrieb Matthias Andree: > > >And I even considered warning of deamon intervals shorter than 5 > >minutes. In fact, with many sites, polling in shorter intervals > >just earns you a lockout. > > I know this behavior from the pop mail server of my university. > However, the critical interval that triggers a lockout after a few > trials is 10 seconds (which sounds reasonable to me). GMX are counting connection attempts per unit of time, without stating clearly how much is too much. Every 5 minutes works. web.de limit poll intervals for non-paying users for 15 minutes and 1 minute for paying users (but given their abysmal performance and contact ways, I'd rather not subscribe to their premium service). > >Trying short poll intervals with "keep" doesn't work too well either. > > What could possibly go wrong? The traffic ramps up if considerably you download the possibly long UID list every 30 seconds, and ISTR that the UID comparison code is still O(n^2). > Of course - but they require a specific server setup. I suppose most > if not all ISPs would rather take care that their mail servers can > handle short polling intervals of their customers, than offer an > alternative SMTP solution which adds a lot of complexity for them. > Complexity is more expensive than faster hardware. Probably. > Also, this would only be reasonably easy to configure if the client > machine had a fixed IP address. If it doesn't, ODMR might be an alternative, but again that boils down to polling intervals... > Of course, the ideal solution technically would be a mail server that > delivers mail directly via SMTP as long as this works, and > immediately switches to POP when the recipient's computer isn't > connected to the network anymore. That requires a notion of "being logged in" with authentication that neither SMTP nor POP3 offer. IMAP offers this as long as the server knows the IDLE extension, it's fetchmail's end that falls a bit short here. -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-07-12 19:12:27
|
Am 12.07.2006 um 18:15 schrieb Matthias Andree:
>> Of course, the ideal solution technically would be a mail server
>> that delivers mail directly via SMTP as long as this works, and
>> immediately switches to POP when the recipient's computer isn't
>> connected to the network anymore.
>
> That requires a notion of "being logged in" with authentication
> that neither SMTP nor POP3 offer.
Not necessarily. You could make SMTP switch to forwarding mail to the
server's POP spool as soon as the recipient's own machine cannot be
reached via SMTP. Only an explicit command from the recipient's
machine (that is sent when the recipient's machine goes online) would
switch the SMTP server back to forwarding mails directly to
recipient's machine. That should work as long as the network is OK.
If it is down for a short amount of time that goes unnoticed by the
recipient, the recipient will see no reason to send another "switch
back to direct delivery" command to the server, and not receive any
mails, while they are accumulated at the POP server. Of course, the
recipient's machine could routinely send such a command (and make
fetchmail connect to the POP account, just in case) every 15 minutes
or so.
But as I said, there's a lot of complexity involved in this solution.
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Matthias A. <mat...@gm...> - 2006-07-14 11:25:36
|
On Wed, 12 Jul 2006, Uli Zappe wrote: > Not necessarily. You could make SMTP switch to forwarding mail to the > server's POP spool as soon as the recipient's own machine cannot be > reached via SMTP. Only with fixed IP, else you risk hijacked messages. And for that purpose (fixed IP), ETRN (which is already supported) can do the job without using POP3 or similar. -- Matthias Andree |
|
From: Uli Z. <ul...@ri...> - 2006-07-14 22:55:26
|
Am 13.07.2006 um 13:38 schrieb Matthias Andree:
> On Wed, 12 Jul 2006, Uli Zappe wrote:
>> Not necessarily. You could make SMTP switch to forwarding mail to
>> the server's POP spool as soon as the recipient's own machine
>> cannot be reached via SMTP.
> Only with fixed IP, else you risk hijacked messages.
Agreed, a fixed IP is required.
> And for that purpose (fixed IP), ETRN (which is already supported)
> can do the job without using POP3 or similar.
Not really. At least for me, a typical situation is that I want
access to my new mails on my laptop (via POP3, leaving the mails on
the sever) while I'm away from home and my desktop machine is down.
When I return home, all the mails should be transferred to my desktop
machine and deleted from the sever.
I think this is a typical situation for many users, and it can't be
solved by ETRN.
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
|
|
From: Michelle K. <lin...@fr...> - 2006-08-11 18:30:40
|
Am 2006-07-12 08:05:43, schrieb Matthias Andree:
> That's what IMAP's IDLE extension is for, with that, the client will be
> notified of new messages without having to reconnect often.
> Unfortunately, this works only well in 6.3.4 and only if fetchmail is
> polling one account only.
Oops... A new feature? This would mean, that I have 180
fetchmails running in the background, one for each user...
Or do I mis something?
And I have more then 600 Mailboxes to poll...
Oh yes, since my ISP support IMAP (courier) I use expunge 1 to prevent
downloading of messages twice, if I have a line-drop on my 3.5 MBit SDSL.
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Matthias A. <mat...@gm...> - 2006-08-12 12:40:58
|
Michelle Konzack <lin...@fr...> writes: > Am 2006-07-12 08:05:43, schrieb Matthias Andree: > >> That's what IMAP's IDLE extension is for, with that, the client will be >> notified of new messages without having to reconnect often. >> Unfortunately, this works only well in 6.3.4 and only if fetchmail is >> polling one account only. > > Oops... A new feature? Not new, but older IDLE implementations in fetchmail were somewhat buggy. -- Matthias Andree |
×
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