fetchmail-users — User questions and discussion

Re: [fetchmail-users] Simple fetch and forward

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

On 7/24/06, fet...@je... <fet...@je...> wrote:
> I don't want it to check messages, to try routing them, to change the
> headers, nothing. I just want it to get the mail from POP and send it to
> SMTP.
>
> I have stuff on Postfix, Procmail and Cyrus-IMAP that will handle
> validating a message so Fetchmail should not be trying to do this.
>
> Can I do this or am I missing something.

You can (that's what I'm doing).  What you're missing is providing us
with any information to help you.

So,

1) Fetchmail version

2) Contents of .fetchmailrc

-- 
                 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] Simple fetch and forward

[<fet...@je...>]

Hello,

I have a mailserver running Postfix, Procmail, Cyrus-IMAP and a bunch of
other stuff. It handles mail for users various domains obtained over SMTP.

I need to pull some additional mail off some POP mail servers and I have
tried to use Fetchmail to do this. I have got it working to an extent but
am falling foul of the multidrop mode.

I think my problems are because Fetchmail is trying to be too clever. I
would like it to get ALL mail from a pop3 mailbox and forward ALL mail,
unaltered, to my Postfix server listening on port 25.

I don't want it to check messages, to try routing them, to change the
headers, nothing. I just want it to get the mail from POP and send it to
SMTP.

I have stuff on Postfix, Procmail and Cyrus-IMAP that will handle
validating a message so Fetchmail should not be trying to do this.

Can I do this or am I missing something.

Many thanks,
John


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Re: [fetchmail-users] [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/18/06, Rob MacGregor <rob...@gm...> wrote:
> Give it another couple of days.  I'm reasonably sure somebody with
> knowledge of the source will be by before the weekend.  The
> development team is pretty small (not sure of the exact number, but I
> suspect only 2 or 3).

Ok. I've found a workaround by changing the postmaster setting to an
empty string. However, I suspect that's not a particularly good
idea...

Andy

Re: [fetchmail-users] [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

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

On 7/18/06, Andy Hawkins <adh...@gm...> wrote:
> Hi,
>
> I guess the question I have is why my configuration works as I want
> (bounces mail to invalid addresses) when I run it interactively, but
> not when I run fetchmail as a daemon (as I'd rather do)?

Give it another couple of days.  I'm reasonably sure somebody with
knowledge of the source will be by before the weekend.  The
development team is pretty small (not sure of the exact number, but I
suspect only 2 or 3).

-- 
                 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] Bouncing invalid addresses

[Andy H. <adh...@gm...>]

Hi,

Ok, I did a bit more digging in the man page. I tried

set postmaster ""

And this appears to have cured it. However, the manual says:

"The --postmaster <name> option (keyword: set postmaster) specifies
the last-resort username to which multidrop mail is to be forwarded if
no matching local recipient can be found. It is also used as
destination of undeliverable mail if the 'bouncemail' global option is
off "

I have 'set bouncemail' in the top of my config file, so if I'm
reading that correctly it shouldn't be sending undeliverable mail to
the postmaster user.

Anyone?

Andy

Re: [fetchmail-users] [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

I guess the question I have is why my configuration works as I want
(bounces mail to invalid addresses) when I run it interactively, but
not when I run fetchmail as a daemon (as I'd rather do)?

Anyone?

Andy

Re: [fetchmail-users] [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,

On 7/17/06, Matthias Andree <mat...@gm...> wrote:
> On Mon, 17 Jul 2006, Andy Hawkins wrote:
>
> > I don't want to bounce it because it's Spam, I want to bounce it
> > because the destination address isn't valid.
>
> Then why doesn't your upstream server know it's invalid and reject the
> message right away?

I have a server on the net that handles mail for my domains. It does
this by just putting all mail for each domain into one mailbox (one
per domain). I don't want to have to set up an individual mailbox for
each account in each domain I have.

When the mail is downloaded via fetchmail, my local machine knows what
accounts are valid and will bounce any that aren't. Fetchmail appears
to be sending bounce message, but then delivering the message to the
postmaster address anyway. I just want to turn off this postmaster
delivery for mail that should be bounced.

Andy

[fetchmail-users] Fwd: Fwd: [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,


On 7/17/06, Rob MacGregor <rob...@gm...> wrote:
> It wouldn't hurt to provide the output of "fetchmail --configdump" so
> we can see what fetchmail thinks of it's config file.

Below (I've cut out the entries for the other servers I check, but
they're all very similar in terms of configuration).

TRUE=1; FALSE=0

os_type = 'linux'
feature_options = ('pop3','imap','sdps','etrn','odmr','ssl',)
# Start of configuration initializer
fetchmailrc = {
  'poll_interval':0,
  "logfile":None,
  "idfile":"/var/lib/fetchmail/.fetchids",
  "postmaster":"fetchmail",
  'bouncemail':TRUE,
  'spambounce':FALSE,
  "properties":None,
  'invisible':FALSE,
  'showdots':TRUE,
  'syslog':FALSE,
  # List of server entries begins here
  'servers': [
      # Entry for site `xxx.xxx.xxx.xxx' begins:
      {
          "pollname":"xxx.xxx.xxx.xxx",
          'active':TRUE,
          "via":None,
          "protocol":"POP3",
          "service":None,
          'timeout':300,
          'interval':0,
          "envelope":"Delivered-To",
          'envskip':1,
          "qvirtual":"45-",
          "auth":"any",
          'dns':TRUE,
          'uidl':TRUE,
          "aka":[],
          "localdomains":["xxx.xxx.xxx"],
          "interface":None,
          "monitor":None,
          "plugin":None,
          "plugout":None,
          "principal":None,
          'tracepolls':FALSE,
          'users': [
              {
                  "remote":"xx...@xx...",
                  "password":"xxxxxxx",
                  'localnames':["fetchmail", '*'],
                  'fetchall':FALSE,
                  'keep':TRUE,
                  'flush':FALSE,
                  'limitflush':FALSE,
                  'rewrite':TRUE,
                  'stripcr':FALSE,
                  'forcecr':FALSE,
                  'pass8bits':FALSE,
                  'dropstatus':FALSE,
                  'dropdelivered':FALSE,
                  'mimedecode':FALSE,
                  'idle':FALSE,
                  "mda":None,
                  "bsmtp":None,
                  'lmtp':FALSE,
                  "preconnect":None,
                  "postconnect":None,
                  'limit':0,
                  'warnings':3600,
                  'fetchlimit':0,
                  'fetchsizelimit':100,
                  'fastuidl':4,
                  'batchlimit':0,
                  'ssl':FALSE,
                  "sslkey":None,
                  "sslcert":None,
                  "sslproto":"",
                  'sslcertck':FALSE,
                  "sslcertpath":None,
                  "sslfingerprint":None,
                  'expunge':0,
                  "properties":None,
                  "smtphunt":["localhost"],
                  "fetchdomains":[],
                  "smtpaddress":"yyy.yyy.yyy",
                  "smtpname":None,
                  'antispam':'',
                  "mailboxes":[],
              }
              ,           ]
      }
  ]
}
# End of initializer

Re: [fetchmail-users] Fwd: [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

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

As it says in the .sig - please keep list traffic on the list.  Your
message has *NOT* been forwarded.

On 7/17/06, Andy Hawkins <adh...@gm...> wrote:
> Hi,

-- 
                 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] Fwd: [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

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

On 7/17/06, Andy Hawkins <adh...@gm...> wrote:
>
> Should we continue this here for now, or move to there?

Here :-)  Very few people watch the old lists.  As far as I can tell
mostly only me.

> > On 7/17/06, Andy Hawkins <adh...@gm...> wrote:
> > Upgrade to 6.3.4
>
> Ok, didn't want to do that as it involves building from source, but
> I've done that now.

Great.

> > Spam messages almost never have a legit return address.  All you'll
> > end up doing is annoying some poor innocent sod, and possibly becoming
> > a spam source yourself.  Better to drop them on the floor.
>
> True, but I want legitimate mail (but with invalid addresses) to be
> bounced so that the sender knows they've got it wrong.

As long as you're aware of the risks.  Keep an eye on the volume of
bounces.  If/when people realise what you're doing they may target you
for a spam run (basically using you to "bounce" the spam to the
recipient).

That isn't theory - that's a pretty standard spam tactic.

> Below:
>
<---SNIP--->
> fetchmail: SMTP> RCPT TO:<yy...@yy...>
> fetchmail: SMTP< 550 unknown user
> fetchmail: SMTP error: 550 unknown user
> fetchmail: SMTP listener doesn't like recipient address `yy...@yy...'
> fetchmail: SMTP< 220 zzz.zzz.zzz ESMTP Exim 4.50 Mon, 17 Jul 2006 16:15:41 +0100
> fetchmail: SMTP> HELO zzz.zzz.zzz
> fetchmail: SMTP< 250 zzz.zzz.zzz Hello localhost [127.0.0.1]
> fetchmail: SMTP> MAIL FROM:<>
> fetchmail: SMTP< 250 OK
> fetchmail: SMTP> RCPT TO:<xx...@xx...>
> fetchmail: SMTP< 250 Accepted
> fetchmail: SMTP> DATA
> fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
> fetchmail: SMTP: (bounce-message body)
> fetchmail: SMTP>. (EOM)
> fetchmail: SMTP< 250 OK id=1G2Uov-0005GD-HY
> fetchmail: SMTP> QUIT
> fetchmail: SMTP< 221 zzz.zzz.zzz closing connection
> fetchmail: SMTP> RCPT TO:<pos...@zz...>
> fetchmail: SMTP< 250 Accepted
> fetchmail: no address matches; forwarding to postmaster.
<---SNIP--->
>
> It looks like it has sent a bounce, but still forwarded the mail to
> the postmaster.

Not sure why it did that - hopefully one of the maintainers will come
by and have an idea what's going on.

It wouldn't hurt to provide the output of "fetchmail --configdump" so
we can see what fetchmail thinks of it's config file.

-- 
                 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] Fwd: [fetchmail]Multidrop fetchmail bouncing non-existing local addresses

[Andy H. <adh...@gm...>]

Hi,


On 7/17/06, Rob MacGregor <rob...@gm...> wrote:
> These lists are depreciated - please use the lists found at www.fetchmail.info

Should we continue this here for now, or move to there?

> On 7/17/06, Andy Hawkins <adh...@gm...> wrote:
> Upgrade to 6.3.4

Ok, didn't want to do that as it involves building from source, but
I've done that now.

> Spam messages almost never have a legit return address.  All you'll
> end up doing is annoying some poor innocent sod, and possibly becoming
> a spam source yourself.  Better to drop them on the floor.

True, but I want legitimate mail (but with invalid addresses) to be
bounced so that the sender knows they've got it wrong.

> Otherwise, once you've upgraded to 6.3.4 please submit the output of
> "fetchmail -v -v -v" showing the problem.

This is the config:

set bouncemail
poll xxx.xxx.xxx.xxx
       protocol pop3
       envelope 1 "Delivered-To"
       qvirtual "45-"
       localdomains xxx.xxx.xxx
       username xx...@xx... password "xxxxxx" is * here
       nokeep smtpaddress zzz.zzz.zzz
Below:

fetchmail: POP3> RETR 7
fetchmail: POP3< +OK 475 octets follow.
reading message xx...@xx...@yyy.yyy:7 of 7 (475 octets)
About to rewrite Return-Path: <yy...@yy...>
Rewritten version is Return-Path: <yy...@yy...>

About to rewrite From: yy...@yy...
Rewritten version is From: yy...@yy...

About to rewrite To: xx...@xx...
Rewritten version is To: xx...@xx...

fetchmail: passed through xx...@xx... matching xxx.xxx.xxx
fetchmail: SMTP< 220 zzz.zzz.zzz ESMTP Exim 4.50 Mon, 17 Jul 2006 16:15:41 +0100
fetchmail: SMTP> EHLO zzz.zzz.zzz
fetchmail: SMTP< 250-zzz.zzz.zzz Hello localhost [127.0.0.1]
fetchmail: SMTP< 250-SIZE 52428800
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250 HELP
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<xx...@xx...> SIZE=475
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:<yy...@yy...>
fetchmail: SMTP< 550 unknown user
fetchmail: SMTP error: 550 unknown user
fetchmail: SMTP listener doesn't like recipient address `yy...@yy...'
fetchmail: SMTP< 220 zzz.zzz.zzz ESMTP Exim 4.50 Mon, 17 Jul 2006 16:15:41 +0100
fetchmail: SMTP> HELO zzz.zzz.zzz
fetchmail: SMTP< 250 zzz.zzz.zzz Hello localhost [127.0.0.1]
fetchmail: SMTP> MAIL FROM:<>
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:<xx...@xx...>
fetchmail: SMTP< 250 Accepted
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
fetchmail: SMTP: (bounce-message body)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1G2Uov-0005GD-HY
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 zzz.zzz.zzz closing connection
fetchmail: SMTP> RCPT TO:<pos...@zz...>
fetchmail: SMTP< 250 Accepted
fetchmail: no address matches; forwarding to postmaster.
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
#*fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1G2Uov-0005GC-Kh
 not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Bye-bye.
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 zzz.zzz.zzz closing connection
fetchmail: 6.3.4 querying yyy.yyy.yyy (protocol POP3) at Mon Jul 17
16:15:41 2006: poll completed
fetchmail: swapping UID lists
fetchmail: Writing fetchids file.
fetchmail: normal termination, status 0
fetchmail: Writing fetchids file.

It looks like it has sent a bounce, but still forwarded the mail to
the postmaster.

Any ideas?

Andy

Re: [fetchmail-users] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

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

On 7/15/06, Matthias Andree <mat...@gm...> wrote:
> Greetings!
>
> Has anyone ever seen warning messages of his fetchmail running in daemon
> mode that were like:
>
>   Fetchmail saw more than 20 timouts while attempting to get mail from
>   foo@bar.  This could mean that your mailserver is stuck, or that your
>   SMTP listener is wedged, or that your mailbox file on the server has
>   been corrupted by a server error.  You can run `fetchmail -v -v' to
>   diagnose the problem. Fetchmail won't poll this mailbox again until
>   you restart it.

I'm not aware of having ever seen such a message, despite periods of
24 hours and more when my ISP's mail server has been offline (and
easily polled a couple of hundred times).

-- 
                 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] Has anyone ever seen "Fetchmail saw more than N timouts while attempting to get mail from ..."

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

Greetings!

Has anyone ever seen warning messages of his fetchmail running in daemon
mode that were like:

  Fetchmail saw more than 20 timouts while attempting to get mail from
  foo@bar.  This could mean that your mailserver is stuck, or that your
  SMTP listener is wedged, or that your mailbox file on the server has
  been corrupted by a server error.  You can run `fetchmail -v -v' to
  diagnose the problem. Fetchmail won't poll this mailbox again until
  you restart it.

If you've seen these, please report the fetchmail version (type this to
print it, the first line suffices: fetchmail -V | head) and your
operating system and version (type "uname -a" without quote marks to get
this).

This message is supposed to be mailed to a user since 4.6.7, but the
code I've looked at makes it rather unlikely (not to say impossible) to
ever be mailed on operating systems that I'm used to. Before removing
the relevant code for the 6.3.5 update, I'd like to know if someone is
getting these messages.

Thanks!

Kind regards,

-- 
Matthias Andree

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