fetchmail-users — User questions and discussion

Re: [fetchmail-users] fetchmail does not mark messages "seen" on remote server running qmail

[Matthias A. <mat...@gm...>]

"Rob MacGregor" <rob...@gm...> writes:

> On 7/15/06, mario kammerer <ma...@ot...> wrote:
>>
>>  hello dear member!
>>
>>  i'm running on my server (DMZ) qmail. the mails are received by ISP (qmail
>> too) from where i fetch them with fetchmail
>
> QMail is for SMTP.  The POP/IMAP server will be something different.

qmail ships with a somewhat broken POP3 server, which many sites appear
to use since they're lured into believing it were a particularly good
one by the misleading qmail advertising.

-- 
Matthias Andree

Re: [fetchmail-users] fetchmail does not mark messages "seen" on remote server running qmail

[Matthias A. <mat...@gm...>]

mario kammerer <ma...@ot...> writes:

> hello dear member!
>
> i'm running on my server (DMZ) qmail. the mails are received by ISP (qmail
> too) from where i fetch them with fetchmail
> into local qmail. the mails should stay on remote ISPs and only NEW mails
> should be fetched.
>
> everything works perfekt - even to input them into qmail-scanner-queue.
>
> what DOES NOT WORK is to mark the fetched messages "seen"

POP3 has no idea of "seen" messages and no method to mark fetched
messages seen. Many POP3 servers can however report unique identifiers
through which the client (here: fetchmail) can identify seen messages
and avoid fetching them again. To that extent...

> every run fetchmail fetches EVERY mail from remote ISP....

...add the "uidl" keyword to your fetchmailrc BEFORE the "user" keyword.

-- 
Matthias Andree

Re: [fetchmail-users] fetchmail does not mark messages "seen" on remote server running qmail

[Rob M. <rob...@gm...>]

On 7/15/06, mario kammerer <ma...@ot...> wrote:
>
>  hello dear member!
>
>  i'm running on my server (DMZ) qmail. the mails are received by ISP (qmail
> too) from where i fetch them with fetchmail

QMail is for SMTP.  The POP/IMAP server will be something different.

>  into local qmail. the mails should stay on remote ISPs and only NEW mails
> should be fetched.
<---SNIP--->
>  what DOES NOT WORK is to mark the fetched messages "seen"

Well, that's actually down to the POP server, not fetchmail.  If you
want fetchmail to track what messages it's seen you need to use UIDL.
From the man page on the UIDL option:

Force POP3 to use client-side UIDLs (recommended)

-- 
                 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

[fetchmail-users] fetchmail does not mark messages "seen" on remote server running qmail

[mario k. <ma...@ot...>]

hello dear member!

i'm running on my server (DMZ) qmail. the mails are received by ISP
(qmail too) from where i fetch them with fetchmail
into local qmail. the mails should stay on remote ISPs and only NEW
mails should be fetched.

everything works perfekt - even to input them into qmail-scanner-queue.

what DOES NOT WORK is to mark the fetched messages "seen"

every run fetchmail fetches EVERY mail from remote ISP....

my config:

.fetchmailrc: 
poll mail.foo.at proto pop3 nodns user "fo...@fo..." pass "secret" is *
forcecr keep to fo...@fo...

and the fetchprocess is made with

# fetchmail -v


an example output of fetchmail -v is
.
.
.
fetchmail: SMTP< 250 ok 1152955079 qp 20977
 not flushed
fetchmail: POP3> LIST 33
fetchmail: POP3< +OK 33 7722
fetchmail: POP3> RETR 33
fetchmail: POP3< +OK 7722 octets
reading message fo...@fo...@mail.foo.at:33 of 306 (7722 octets)
fetchmail: SMTP> MAIL FROM:<Ge...@ex...> SIZE=7722
fetchmail: SMTP< 250 ok
fetchmail: SMTP> RCPT TO:<fo...@fo...>
fetchmail: SMTP< 250 ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 go ahead
#**************************.****************.**********.*****.*****.****.*********.***fetchmail: SMTP>. (EOM)
.
.
.

thank you very much for help.
mario

Re: [fetchmail-users] reasonable poll intervals

[Uli Z. <ul...@ri...>]

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
________________________________________________________

Re: [fetchmail-users] reasonable poll intervals

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] reasonable poll intervals

[Uli Z. <ul...@ri...>]

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
________________________________________________________

Re: [fetchmail-users] reasonable poll intervals

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Matthias A. <mat...@gm...>]

On Wed, 12 Jul 2006, Uli Zappe wrote:

> Am 28.06.2006 um 02:46 schrieb Matthias Andree:
> 
> >I don't think I'll be able to handle this before Saturday, perhaps  
> >Sunday; but providing patches for you to test should be feasible.
> 
> Has anything happened yet?

I've looked at the stuff in the scarce time I've had, but it's rather
entangled code (as always with setjmp/longjmp), so the fix will be more
complex than we thought initially and there's nothing to test yet.
Still working on it. Sorry. :-/

-- 
Matthias Andree

Re: [fetchmail-users] reasonable poll intervals

[Uli Z. <ul...@ri...>]

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
________________________________________________________

Re: [fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Ed W. <ew...@ew...>]

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...

[fetchmail-users] Re: reasonable poll intervals (was: Re: Rotating the log file)

[Matthias A. <mat...@gm...>]

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

[fetchmail-users] reasonable poll intervals (was: Re: Rotating the log file)

[Uli Z. <ul...@ri...>]

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
________________________________________________________

Re: [fetchmail-users] [BUG] fetchmail daemon does not resume fetching after a network outage

[Uli Z. <ul...@ri...>]

Am 28.06.2006 um 02:46 schrieb Matthias Andree:

> I don't think I'll be able to handle this before Saturday, perhaps  
> Sunday; but providing patches for you to test should be feasible.

Has anything happened yet?

             Bye
                     Uli
________________________________________________________

   Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
   http://www.ritual.org
   Fon: +49-700-ULIZAPPE
   Fax: +49-700-ZAPPEFAX
________________________________________________________

Re: [fetchmail-users] Rotating the log file

[James M. <ji...@so...>]

-----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-----

Re: [fetchmail-users] Rotating the log file

[Matthias A. <mat...@gm...>]

"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

Re: [fetchmail-users] Rotating the log file

[Matthias A. <mat...@gm...>]

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

Re: [fetchmail-users] Rotating the log file

[Rob M. <rob...@gm...>]

[ 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

Re: [fetchmail-users] Rotating the log file

[Stephen A. <fet...@ro...>]

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 :)

Re: [fetchmail-users] Rotating the log file

[Rob M. <rob...@gm...>]

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

[fetchmail-users] Rotating the log file

[James M. <ji...@so...>]

-----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-----

Re: [fetchmail-users] Running fetchmail as root for all users

[Matthias A. <mat...@gm...>]

Stephen Allen <fet...@ro...> writes:

> Thanks Rob, I take note about not running it as root and will fix that
> ASAP.  My questions was mainly aimed at, should I run one instance of
> fetchmail to poll all POP3 accounts for all 8 users, or should I set up
> a seperate instance per-user?  And I thought it might be significant to
> say that the users cannot log in via a shell.

If fetchmail is forwarding via SMTP (the default) or LMTP (note that
file permissions apply when forwarding into a unix-domain LMTP socket),
there is:

- no need to run fetchmail as root, and

- no need that the recipients can log into a shell.

-- 
Matthias Andree

Re: [fetchmail-users] Running fetchmail as root for all users

[Rob M. <rob...@gm...>]

On 7/6/06, Stephen Allen <fet...@ro...> wrote:
>
> Thanks Rob, I take note about not running it as root and will fix that
> ASAP.  My questions was mainly aimed at, should I run one instance of
> fetchmail to poll all POP3 accounts for all 8 users, or should I set up
> a seperate instance per-user?  And I thought it might be significant to
> say that the users cannot log in via a shell.

Up to you.  I tend to split things by ISP, rather than user.  That way
problems with one ISP don't impact all the others.

-- 
                 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

Re: [fetchmail-users] Running fetchmail as root for all users

[Stephen A. <fet...@ro...>]

Rob MacGregor wrote:
> There is no need, unless you're passing email directly to a non-SUID
> MDA, to run fetchmail as root.  Indeed, future versions of fetchmail
> will refuse to run as root.  I haven't run fetchmail as root since
> before 6.0 was released and have not had any problems.
> 
> Simply run it as a standard user (say "fetchmail") and have it pass
> email to your MTA.
> 
> In general, running any program with higher privileges than it
> requires is a security risk.

Thanks Rob, I take note about not running it as root and will fix that 
ASAP.  My questions was mainly aimed at, should I run one instance of 
fetchmail to poll all POP3 accounts for all 8 users, or should I set up 
a seperate instance per-user?  And I thought it might be significant to 
say that the users cannot log in via a shell.

Thanks,
Steve :)

Re: [fetchmail-users] Running fetchmail as root for all users

[Rob M. <rob...@gm...>]

On 7/6/06, Stephen Allen <fet...@ro...> wrote:
> The subject may be a little misleading... in my scenario we have 10 ISP
> POP3 accounts that map to 8 local users.  The way I set it up a few
> years ago was fetchmail running as root and collecting mail for all POP3
> accounts.  I've since discovered that fetchmail is normally run on a
> per-user basis.
>
> Given that the users never log in to a shell, what is the best
> configuration in my case?  Are there pros/cons of doing it either way?

There is no need, unless you're passing email directly to a non-SUID
MDA, to run fetchmail as root.  Indeed, future versions of fetchmail
will refuse to run as root.  I haven't run fetchmail as root since
before 6.0 was released and have not had any problems.

Simply run it as a standard user (say "fetchmail") and have it pass
email to your MTA.

In general, running any program with higher privileges than it
requires is a security risk.

-- 
                 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