fetchmail-users — User questions and discussion

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

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

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?

Many thanks,
Steve :)

Re: [fetchmail-users] fetchmail: SMTP error: 552 Message size exceeds fixed limit

[Jason W. <jas...@in...>]

On Thu, Jul 06, 2006 at 02:14:57AM +0100, Stephen Allen wrote:
> message_size_limit = 10240000
> 
> Would I be right in thinking it's the "message_size_limit" that is responsible 
> for refusing the message?  If so, how big is the message that fetchmail 
> reported (16681007 octets)?  How does that compare with bytes?
"Octet" is another word for "byte". You have a message limit of 10 million
bytes, but Fetchmail is trying to deliver a message with more than 16 million
bytes.

If you want this mail to be delivered you'll have to increase the Postfix
message size limit by adjusting the value of the message_size_limit variable
in main.cf.

[fetchmail-users] fetchmail: SMTP error: 552 Message size exceeds fixed limit

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

Hello all... (my first post to this list).  I've just noticed this error
in my fetchmail log:

fetchmail: reading message [masked]:1 of 1 (
16681007 octets) fetchmail: SMTP error: 552 Message size exceeds fixed limit
fetchmail:  flushed

I found a previous problem like this, which suggested the local SMTP
service was refusing to receive it.  I use Postfix, so I did a grep on
the output of postconf, and this is what I get:

[root@samba ~]# postconf -d | grep size
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
body_checks_size_limit = 51200
bounce_size_limit = 50000
header_size_limit = 102400
mailbox_size_limit = 51200000
message_size_limit = 10240000

Would I be right in thinking it's the "message_size_limit" that is
responsible for refusing the message?  If so, how big is the message
that fetchmail reported (16681007 octets)?  How does that compare with
bytes?

Many thanks,
Steve :)

[fetchmail-users] fetchmail: SMTP error: 552 Message size exceeds fixed limit

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

Hello all... (my first post to this list).  I've just noticed this error 
in my fetchmail log:

fetchmail: reading message [masked]:1 of 1 (
16681007 octets) fetchmail: SMTP error: 552 Message size exceeds fixed limit
fetchmail:  flushed

I found a previous problem like this, which suggested the local SMTP 
service was refusing to receive it.  I use Postfix, so I did a grep on 
the output of postconf, and this is what I get:

[root@samba ~]# postconf -d | grep size
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
body_checks_size_limit = 51200
bounce_size_limit = 50000
header_size_limit = 102400
mailbox_size_limit = 51200000
message_size_limit = 10240000

Would I be right in thinking it's the "message_size_limit" that is 
responsible for refusing the message?  If so, how big is the message 
that fetchmail reported (16681007 octets)?  How does that compare with 
bytes?

Many thanks,
Steve :)

Re: [fetchmail-users] What is a "local issuer certificate"?

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

Paul Elliott <pel...@io...> writes:

> I am not an expert on ssl so this does not really answer my
> question.

You need the root certificate that this...

>
> I got one certificate from the imap server at mail.io.com
> by doing the following:
>
> openssl s_client -connect mail.io.com:993 -showcerts

...certificate was signed with.

(few minutes later)

The necessary root certificate can be downloaded here:
<http://www.geotrust.com/resources/root_certificates/index.asp>

Under Root 4, download "Download - Equifax Secure eBusiness CA-1
(Base-64 encoded X.509)" and save it to a file. Then rename the
downloaded *.cer file so it has a .pem ending (it's in PEM format, but
it needs a .pem suffix for c_rehash to recognize it) and
move it into your .ssl/certs, then run c_rehash ~/.ssl/certs.

You already have "sslcertpath /home/pelliott/.ssl/certs", so that part
is covered. After the installation of that certificate, you can remove
the sslfingerprint option.

> and the io.pem was supposed to be signed by equifax so I should
> have the certificate for equifax that signed io.pem.

Yet you don't. Equifax issued more than one certificate.

> My .fetchmailrc looks like (with password XXXXed):
>
> # Configuration created Mon Jun 19 10:26:45 2006 by fetchmailconf 1.52 $Revision: 4636 $
> set postmaster "pelliott"
> set bouncemail
> set no spambounce
> set properties ""
> poll mail.io.com with proto IMAP
>        user 'pelliott' there with password 'XXXXXXX' is 'pelliott' here sslcertpath /home/pelliott/.ssl/certs sslfingerprint "5D:1F:EF:5B:2C:C6:72:07:D4:18:D1:D3:15:8F:4F:1B"
> #sslcertck
>
> I am still getting the error message.

Which means your fetchmail version is older than 6.3.4.
Please update.

> My question was does "local issuer certificate" refer to?

The root certificate.

> The certificate I got from the imap server at mail.io.com or does it
> refer to a self signed certificate describing my fetchmail client?

Neither.

> How do I create/get one in any case?

See above.

> The fetchmail documentation describes the --sslcert and --sslkey
> parameters and how they should point to certifications and keys.

No.

> But this stuff is going to be used by a lot of ignorant people
> like me, it does not tell how to get and/or create such keys.
> I can't seem to figure it out.

Your ISP should have provided the necessary instructions. Please ask
them to provide instructions and the necessary root certificate.

-- 
Matthias Andree

Re: [fetchmail-users] What is a "local issuer certificate"?

[Paul E. <pel...@io...>]

On Sat, Jul 01, 2006 at 11:38:46AM +0200, Matthias Andree wrote:
> Paul Elliott <pel...@io...> writes:
> 
> > When I run fetchmail to get mail from my IMAP server
> > I get the following messages:
> >
> > fetchmail: Server certificate verification error: unable to get local issuer certificate
> > fetchmail: Server certificate verification error: certificate not trusted
> > fetchmail: Server certificate verification error: unable to verify the first certificate
> >
> >
> > My question is: what is a "local issuer certificate"?
> >
> > Is it the public key associated with my IMAP server?
> > Or is it the public key associated with my local fetchmail
> > client?
> >
> > In any case how do I create and/or get one to make the error go
> > away?
> 
> That depends. Usually the fix to is make sure that fetchmail can find
> the root certificate. Some self-signed certificates are provided without
> the signing root certificate; ask the operator of the server.
> 
> Older fetchmail versions did not set the certificate authorities' path
> properly, updating to 6.3.4 should then fix that.
> 
> As a workaround, run fetchmail with -v to see the MD5 fingerprint, call
> the server's operator to verify the fingerprint, and use the
> --sslfingerprint option. This, too, needs a recent fetchmail version to
> work properly.
> 


I am not an expert on ssl so this does not really answer my
question.

I got one certificate from the imap server at mail.io.com
by doing the following:

openssl s_client -connect mail.io.com:993 -showcerts

I then grabbed everything between the
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
inclusive and put it in io.pem in the
/home/pelliott/.ssl/certs directory

this directory also contains

ls .ssl/certs
1e49180d.0  843b6c51.0         aae0b7a3.0  eng1.pem    io.pem~
2edf7016.0  878cf4c6.0         argena.pem  eng2.pem    thawteCb.pem
56e607f4.0  Equifax-root1.pem  argeng.pem  eng3.pem    thawteCp.pem
594f1775.0  ICP-Brasil.pem     c33a80d4.0  eng4.pem    vsign1.pem
6adf0799.0  RegTP-5R.pem       cdd7aee7.0  eng5.pem    vsign3.pem
6f5d9899.0  RegTP-6R.pem       d4e39186.0  expired     vsignss.pem
7651b327.0  a3c60019.0         ddc328ff.0  f73e89fd.0  wellsfgo.pem
7a9820c1.0  aad3d04d.0         demo        io.pem

I did a "c_rehash /home/pelliott/.ssl/certs"


and the io.pem was supposed to be signed by equifax so I should
have the certificate for equifax that signed io.pem.

My .fetchmailrc looks like (with password XXXXed):

# Configuration created Mon Jun 19 10:26:45 2006 by fetchmailconf 1.52 $Revision: 4636 $
set postmaster "pelliott"
set bouncemail
set no spambounce
set properties ""
poll mail.io.com with proto IMAP
       user 'pelliott' there with password 'XXXXXXX' is 'pelliott' here sslcertpath /home/pelliott/.ssl/certs sslfingerprint "5D:1F:EF:5B:2C:C6:72:07:D4:18:D1:D3:15:8F:4F:1B"
#sslcertck

I am still getting the error message.

My question was does "local issuer certificate" refer to? The
certificate I got from the imap server at mail.io.com or
does it refer to a self signed certificate describing
my fetchmail client? How do I create/get one in any case?

The fetchmail documentation describes the --sslcert and --sslkey
parameters and how they should point to certifications and keys.

But this stuff is going to be used by a lot of ignorant people
like me, it does not tell how to get and/or create such keys.
I can't seem to figure it out.

-- 
Paul Elliott                       1(512)837-1096
pel...@io...                    PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/   Austin TX 78758-3117

Re: [fetchmail-users] What is a "local issuer certificate"?

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

Paul Elliott <pel...@io...> writes:

> When I run fetchmail to get mail from my IMAP server
> I get the following messages:
>
> fetchmail: Server certificate verification error: unable to get local issuer certificate
> fetchmail: Server certificate verification error: certificate not trusted
> fetchmail: Server certificate verification error: unable to verify the first certificate
>
>
> My question is: what is a "local issuer certificate"?
>
> Is it the public key associated with my IMAP server?
> Or is it the public key associated with my local fetchmail
> client?
>
> In any case how do I create and/or get one to make the error go
> away?

That depends. Usually the fix to is make sure that fetchmail can find
the root certificate. Some self-signed certificates are provided without
the signing root certificate; ask the operator of the server.

Older fetchmail versions did not set the certificate authorities' path
properly, updating to 6.3.4 should then fix that.

As a workaround, run fetchmail with -v to see the MD5 fingerprint, call
the server's operator to verify the fingerprint, and use the
--sslfingerprint option. This, too, needs a recent fetchmail version to
work properly.

-- 
Matthias Andree

[fetchmail-users] What is a "local issuer certificate"?

[Paul E. <pel...@io...>]

When I run fetchmail to get mail from my IMAP server
I get the following messages:

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the first certificate


My question is: what is a "local issuer certificate"?

Is it the public key associated with my IMAP server?
Or is it the public key associated with my local fetchmail
client?

In any case how do I create and/or get one to make the error go
away?


Thank You.

-- 
Paul Elliott                       1(512)837-1096
pel...@io...                    PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/   Austin TX 78758-3117

Re: [fetchmail-users] Multi-drop problems

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

Andrew Longland-Meech <an...@lo...> writes:

> Thank you so much. It works! I didn't understand the bit in the manual
> about 'aka', but having now re-read it, it sort of makes sense.

BTW, any suggestion how it should be worded instead, to make it more understandable?

-- 
Matthias Andree

Re: [fetchmail-users] Multi-drop problems

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

On Thu, 29 Jun 2006, Andrew Longland-Meech wrote:

> I only used keep and fetchall together so that I'd always got some
> fetchable messages on the server whilst I was trying to get this to
> work. Do I still need 'uidl' if I don't use 'keep'?

At least it wouldn't hurt.

-- 
Matthias Andree

Re: [fetchmail-users] Multi-drop problems

[Andrew Longland-M. <an...@lo...>]

On Thu, 2006-06-29 at 11:07 +0200, Matthias Andree wrote:
> Andrew Longland-Meech <an...@lo...> writes:
> 
> > Hello list members,
> >
> > I hope someone can help me - I can't be the only person to have ever run
> > into this problem. I've read the FAQ, but that doesn't seem to describe
> > my situation and I've tried everything I can think of.
> >
> > Here's my setup:
> >
> > fetchmail version: 6.3.4
> > Kernel:	2.6.16-1.2080.13.rdt.rhfc5.ccrma
> > ISP: Freenetname.co.uk
> >
> > My ISP provides forwarding from my own domain, and each and every email
> > I receive has a proper Envelope-to; header.
> >
> > I want to have mail for (mypartner)@(mydomain).me.uk delivered to
> > localuser (mypartner) and everything else delivered to localuser (me).
> >
> > Here's my .fetchmailrc file:
> >
> > set postmaster "(me)"
> > set bouncemail
> > set no spambounce
> > set properties ""
> > #set daemon 900
> > poll mail.freenetname.co.uk with proto POP3 envelope "Envelope-to"
> >         user "(username)@freenetname.co.uk" with password "(*******)"
> >                 to      "(mypartner)@(mydomain).me.uk"="(mypartner)"
> >                         "(username)@freenetname.co.uk"="(me)"
> >                         "(myname)@(mydomain).me.uk"="(me)"
> >                 here
> >         options keep fetchall
> >
> > Now, I think this is setup correctly, following the example in the man
> > page for a multi-drop setup, and indeed fetchmail seems to be using the
> > Envelope-to address according to the output of 'fetchmail -v -v' but it
> > simply isn't doing what it's supposed to and matching the server names
> > to the local names! Everything still gets delivered to (me) and contains
> > a header of the form -
> >
> > X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
> > match any local name
> >
> > Does anyone have any suggestions?
> 
> Well, fetchmail doesn't support full addresses in user mappings yet,
> thus you'll need to rewrite your configuration a bit, hoping that
> (mypartner) is different from (username) and that
> (mypartner) is also different from (myname).
> 
> fetchmail doesn't seem to recognize the recipient addresses either since
> the MX servers for these are most likely not the same as
> mail.freenetname.co.uk.
> 
> Please add between the poll and user lines these three:
> 
> poll mail.freenetname.co.uk
>        aka "(mydomain).me.uk"
>        aka "freenetname.co.uk"
>        proto POP3
>        options UIDL
>        envelope "Envelope-To"
> user "(username)@freenetname.co.uk" 
>        password "(*******)"
>   is   "(mypartner)"="(mypartner)"
>        "(username)"="(me)"
>        "(myname)"="(me)"
>   here
> options keep
> 
> Remarks:
> 1. fetchall and keep together is usually wrong
> 2. UIDL is needed to make "keep" setups reliable
> 
Matthias,

Thank you so much. It works! I didn't understand the bit in the manual
about 'aka', but having now re-read it, it sort of makes sense.

I only used keep and fetchall together so that I'd always got some
fetchable messages on the server whilst I was trying to get this to
work. Do I still need 'uidl' if I don't use 'keep'?

Thanks again.

Andrew

Re: [fetchmail-users] Multi-drop problems

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

Andrew Longland-Meech <an...@lo...> writes:

> Hello list members,
>
> I hope someone can help me - I can't be the only person to have ever run
> into this problem. I've read the FAQ, but that doesn't seem to describe
> my situation and I've tried everything I can think of.
>
> Here's my setup:
>
> fetchmail version: 6.3.4
> Kernel:	2.6.16-1.2080.13.rdt.rhfc5.ccrma
> ISP: Freenetname.co.uk
>
> My ISP provides forwarding from my own domain, and each and every email
> I receive has a proper Envelope-to; header.
>
> I want to have mail for (mypartner)@(mydomain).me.uk delivered to
> localuser (mypartner) and everything else delivered to localuser (me).
>
> Here's my .fetchmailrc file:
>
> set postmaster "(me)"
> set bouncemail
> set no spambounce
> set properties ""
> #set daemon 900
> poll mail.freenetname.co.uk with proto POP3 envelope "Envelope-to"
>         user "(username)@freenetname.co.uk" with password "(*******)"
>                 to      "(mypartner)@(mydomain).me.uk"="(mypartner)"
>                         "(username)@freenetname.co.uk"="(me)"
>                         "(myname)@(mydomain).me.uk"="(me)"
>                 here
>         options keep fetchall
>
> Now, I think this is setup correctly, following the example in the man
> page for a multi-drop setup, and indeed fetchmail seems to be using the
> Envelope-to address according to the output of 'fetchmail -v -v' but it
> simply isn't doing what it's supposed to and matching the server names
> to the local names! Everything still gets delivered to (me) and contains
> a header of the form -
>
> X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
> match any local name
>
> Does anyone have any suggestions?

Well, fetchmail doesn't support full addresses in user mappings yet,
thus you'll need to rewrite your configuration a bit, hoping that
(mypartner) is different from (username) and that
(mypartner) is also different from (myname).

fetchmail doesn't seem to recognize the recipient addresses either since
the MX servers for these are most likely not the same as
mail.freenetname.co.uk.

Please add between the poll and user lines these three:

poll mail.freenetname.co.uk
       aka "(mydomain).me.uk"
       aka "freenetname.co.uk"
       proto POP3
       options UIDL
       envelope "Envelope-To"
user "(username)@freenetname.co.uk" 
       password "(*******)"
  is   "(mypartner)"="(mypartner)"
       "(username)"="(me)"
       "(myname)"="(me)"
  here
options keep

Remarks:
1. fetchall and keep together is usually wrong
2. UIDL is needed to make "keep" setups reliable

-- 
Matthias Andree

[fetchmail-users] Re: Fetchmail problem - Need Help

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

Dhandapani,Padmanabhan schrieb am 2006-06-29:

> Hi Team,
> I am using the fetchmail release 6.2.5  in my Solaris 5.8. 

Please update to 6.3.4.

> I have installed sucssfully in the solaris box. 
> Then i have enabled the POP3 for my mail account and i have created the
> /etc/fetchmailrc files as guided by internet as below. Please find my

Please try to understand what the configuration looks like, everything
is documented in the manual page. Alternatively, if Python and the
Python-Tk libraries are installed, you can use fetchmailconf to
configure fetchmail.

> below fetchmailrc file.
> 
> # more fetchmailrc
> set syslog
> set postmaster "app...@tu..."
> set nobouncemail
> set properties ""
> set idfile /var/run/fetchmail.ids
> poll pop3.tui.de.insite proto pop3

Add "uidl" to this line (without quote marks)

> user 'app...@tu...site'

Is the password in .netrc? If not, it is missing.

> poll pop3.tui.de.insite
> user 'app...@tu...site'

Remove the second poll and user lines.

> Now i am running the below command to fetchmail from my exchange box.
> But i am not receiving any mail. What is this "/var/run/fetchmail.ids"
> which is not created in my path.

It is handled by fetchmail.

> This is a plain text file which i have
> to create or it will create by itself.
> 
> fetchmail -v -v -f /etc/fetchmailrc

Add --nosyslog to this command line to show what goes wrong.

Please reply only to the list.

-- 
Matthias Andree

[fetchmail-users] Fetchmail problem - Need Help

[Dhandapani,Padmanabhan <Pad...@tu...>]

Hi Team,
I am using the fetchmail release 6.2.5  in my Solaris 5.8. 

I have installed sucssfully in the solaris box. 
Then i have enabled the POP3 for my mail account and i have created the
/etc/fetchmailrc files as guided by internet as below. Please find my
below fetchmailrc file.

# more fetchmailrc
set syslog
set postmaster "app...@tu..."
set nobouncemail
set properties ""
set idfile /var/run/fetchmail.ids
poll pop3.tui.de.insite proto pop3
user 'app...@tu...site'
poll pop3.tui.de.insite
user 'app...@tu...site'

Now i am running the below command to fetchmail from my exchange box.
But i am not receiving any mail. What is this "/var/run/fetchmail.ids"
which is not created in my path. This is a plain text file which i have
to create or it will create by itself.

fetchmail -v -v -f /etc/fetchmailrc

Please help us to resolve this issue to use the fetchmail is better way.

Expecting your reply assoonas possible. 

Many Thanks ....

Regards
Paddy
 
Padmanabhan Dhandapani
______________________
Unix & Middleware Team
TUI InfoTec GmbH
Direct Number: +49(0)511-567-55974
Mail to: pad...@tu...
Web Site: http://www.tui.de 

[fetchmail-users] Multi-drop problems

[Andrew Longland-M. <an...@lo...>]

Rob,

Thanks for the quick reply...

>
>> My ISP provides forwarding from my own domain, and each and every email
>> I receive has a proper Envelope-to; header.
>
>Sample header, plus contents of .fetchmailrc?
>
Sample header is 

Envelope-to: an...@lo...
Received: from lists.gnu.org ([199.232.76.165])
	by mx14.global.net.uk with esmtp (Exim 4.42)
	id 1FvZD5-0004RH-RF
	for an...@lo...; Wed, 28 Jun 2006 13:32:09 +0100
Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1FvZD2-00010J-KI
	for an...@lo...; Wed, 28 Jun 2006 08:31:56 -0400
From: lil...@gn...
Subject: lilypond-user Digest, Vol 43, Issue 73
To: lil...@gn...
Reply-To: lil...@gn...
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-BeenThere: lil...@gn...
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LilyPond user discussion <lilypond-user.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/lilypond-user>,
	<mailto:lil...@gn...?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/lilypond-user>
List-Post: <mailto:lil...@gn...>
List-Help: <mailto:lil...@gn...?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/lilypond-user>,
	<mailto:lil...@gn...?subject=subscribe>
Sender: lilypond-user-bounces+andrew=lon...@gn...
Errors-To: lilypond-user-bounces+andrew=lon...@gn...
X-BV-Spam-Score: 1.6 (+)
X-Envelope-From: lilypond-user-bounces+andrew=lon...@gn...

I did include my .fetchmailrc in my first post (with some obfuscation!)

>> X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
>> match any local name
>>
>> Does anyone have any suggestions?
>
>Output of "fetchmail --nosyslog --nodetach -v -v -v" showing this,
>along with the contents of your SMTP server's mail log for the same
>mail would be useful.
>

Here is the output of "fetchmail --nosyslog --nodetach -v -v -v".
I've edited for size, but there is nothing different for any of the other
messages.


fetchmail: 6.3.4 querying mail.freenetname.co.uk (protocol POP3) at Wed 28 Jun 2006 18:51:32 BST: poll started
fetchmail: POP3< +OK freenetname.co.uk POP3 server ready to roll [80.189.80.146]
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR non-existant command
fetchmail: POP3< +OK freenetname.co.uk POP3 server ready to roll [80.189.80.146]
fetchmail: POP3> USER mee...@fr...
fetchmail: POP3< +OK Password required for mee...@fr...
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Maildrop locked and loaded
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 13 92562
13 messages for mee...@fr... at mail.freenetname.co.uk (92562 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 875
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 875 octets
reading message mee...@fr...@mail.freenetname.co.uk:1 of 13 (875 octets)
About to rewrite From: Andrew Longland-Meech <an...@lo...>
Rewritten version is From: Andrew Longland-Meech <an...@lo...>

About to rewrite To: mee...@fr...
Rewritten version is To: mee...@fr...

fetchmail: no local matches, forwarding to schmoo
fetchmail: SMTP< 220 localhost.localdomain ESMTP Sendmail 8.13.6/8.13.6; Wed, 28 Jun 2006 18:51:33 +0100
fetchmail: SMTP> EHLO localhost.localdomain
fetchmail: SMTP< 250-localhost.localdomain Hello localhost.localdomain [127.0.0.1], pleased to meet you
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-DSN
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-DELIVERBY
fetchmail: SMTP< 250 HELP
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<an...@lo...> BODY=7BIT SIZE=875
fetchmail: SMTP< 250 2.1.0 <an...@lo...>... Sender ok
fetchmail: SMTP> RCPT TO:<schmoo@localhost>
fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
fetchmail: message mee...@fr...@mail.freenetname.co.uk:1 was not the expected length (903 actual != 875 expected)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 k5SHpX1K005829 Message accepted for delivery
 not flushed
fetchmail: POP3> LIST 2
fetchmail: POP3< +OK 2 863
fetchmail: POP3> RETR 2
fetchmail: POP3< +OK 863 octets
reading message mee...@fr...@mail.freenetname.co.uk:2 of 13 (863 octets)
About to rewrite From: Andrew Longland-Meech <an...@lo...>
Rewritten version is From: Andrew Longland-Meech <an...@lo...>

About to rewrite To: ma...@lo...
Rewritten version is To: ma...@lo...

fetchmail: no local matches, forwarding to schmoo
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<an...@lo...> BODY=7BIT SIZE=863
fetchmail: SMTP< 250 2.1.0 <an...@lo...>... Sender ok
fetchmail: SMTP> RCPT TO:<schmoo@localhost>
fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
fetchmail: message mee...@fr...@mail.freenetname.co.uk:2 was not the expected length (891 actual != 863 expected)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 k5SHpX1L005829 Message accepted for delivery
 not flushed

<SNIP>---------------------------------------------------------------

fetchmail: POP3> LIST 9
fetchmail: POP3< +OK 9 19866
fetchmail: POP3> RETR 9
fetchmail: POP3< +OK 19866 octets
reading message mee...@fr...@mail.freenetname.co.uk:9 of 13 (19866 octets)
About to rewrite From: lil...@gn...
Rewritten version is From: lil...@gn...

About to rewrite To: lil...@gn...
Rewritten version is To: lil...@gn...

About to rewrite Reply-To: lil...@gn...
Rewritten version is Reply-To: lil...@gn...

About to rewrite Sender: lilypond-user-bounces+andrew=lon...@gn...
Rewritten version is Sender: lilypond-user-bounces+andrew=lon...@gn...

fetchmail: no local matches, forwarding to schmoo
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<lilypond-user-bounces+andrew=lon...@gn...> BODY=8BITMIME SIZE=19866
fetchmail: SMTP< 250 2.1.0 <lilypond-user-bounces+andrew=lon...@gn...>... Sender ok
fetchmail: SMTP> RCPT TO:<schmoo@localhost>
fetchmail: SMTP< 250 2.1.5 <schmoo@localhost>... Recipient ok
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself
..................fetchmail: message mee...@fr...@mail.freenetname.co.uk:9 was not the expected length (20615 actual != 19866 expected)
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 2.0.0 k5SHpX1S005829 Message accepted for delivery
 not flushed

<SNIP>---------------------------------------------------------------

fetchmail: POP3> QUIT
fetchmail: POP3< +OK freenetname.co.uk POP3 server signing off
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 localhost.localdomain closing connection
fetchmail: 6.3.4 querying mail.freenetname.co.uk (protocol POP3) at Wed 28 Jun 2006 18:51:57 BST: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 0
fetchmail: Deleting fetchids file.

Also a copy of /var/spool/maillog. I don't know if this is what you wanted.

Jun 28 18:51:35 localhost sendmail[5829]: k5SHpX1K005829: from=<an...@lo...>, size=1156, class=0, nrcpts=1, msgid=<1151354705.2459.10.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:35 localhost sendmail[5830]: k5SHpX1K005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=31356, dsn=2.0.0, stat=Sent
Jun 28 18:51:37 localhost sendmail[5829]: k5SHpX1L005829: from=<an...@lo...>, size=1141, class=0, nrcpts=1, msgid=<1151354739.2459.14.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:37 localhost sendmail[5832]: k5SHpX1L005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=31341, dsn=2.0.0, stat=Sent
Jun 28 18:51:37 localhost sendmail[5829]: k5SHpX1M005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<1151354758.2459.16.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:38 localhost sendmail[5834]: k5SHpX1M005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32243, dsn=2.0.0, stat=Sent
Jun 28 18:51:39 localhost sendmail[5829]: k5SHpX1N005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<1151354767.2459.18.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:39 localhost sendmail[5836]: k5SHpX1N005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent
Jun 28 18:51:41 localhost sendmail[5829]: k5SHpX1O005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<1151354796.2459.20.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:41 localhost sendmail[5838]: k5SHpX1O005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent
Jun 28 18:51:42 localhost sendmail[5829]: k5SHpX1P005829: from=<an...@lo...>, size=1151, class=0, nrcpts=1, msgid=<1151354727.2459.12.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:42 localhost sendmail[5841]: k5SHpX1P005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=31351, dsn=2.0.0, stat=Sent
Jun 28 18:51:43 localhost sendmail[5829]: k5SHpX1Q005829: from=<an...@lo...>, size=2035, class=0, nrcpts=1, msgid=<1151354837.2459.24.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:43 localhost sendmail[5843]: k5SHpX1Q005829: to=<schmoo@localhost>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32231, dsn=2.0.0, stat=Sent
Jun 28 18:51:46 localhost sendmail[5829]: k5SHpX1R005829: from=<an...@lo...>, size=2047, class=0, nrcpts=1, msgid=<1151354854.2459.26.camel@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:46 localhost sendmail[5845]: k5SHpX1R005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=32243, dsn=2.0.0, stat=Sent
Jun 28 18:51:51 localhost sendmail[5829]: k5SHpX1S005829: from=<lilypond-user-bounces+andrew=lon...@gn...>, size=20146, class=-30, nrcpts=1, msgid=<200606281751.k5SHpX1S005829@localhost.localdomain>, bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:51 localhost sendmail[5847]: k5SHpX1S005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=104440, dsn=2.0.0, stat=Sent
Jun 28 18:51:53 localhost sendmail[5829]: k5SHpX1T005829: from=<su...@th...>, size=19276, class=0, nrcpts=1, msgid=<20060628152751.21600.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:53 localhost sendmail[5849]: k5SHpX1T005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=49476, dsn=2.0.0, stat=Sent
Jun 28 18:51:54 localhost sendmail[5829]: k5SHpX1U005829: from=<su...@th...>, size=20838, class=0, nrcpts=1, msgid=<20060628160510.12010.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:54 localhost sendmail[5851]: k5SHpX1U005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=51038, dsn=2.0.0, stat=Sent
Jun 28 18:51:55 localhost sendmail[5829]: k5SHpX1V005829: from=<lilypond-user-bounces+andrew=lon...@gn...>, size=9176, class=-30, nrcpts=1, msgid=<200606281751.k5SHpX1V005829@localhost.localdomain>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:55 localhost sendmail[5853]: k5SHpX1V005829: to=<schmoo@localhost>, delay=00:00:01, xdelay=00:00:00, mailer=local, pri=93470, dsn=2.0.0, stat=Sent
Jun 28 18:51:57 localhost sendmail[5829]: k5SHpX1W005829: from=<su...@th...>, size=13098, class=0, nrcpts=1, msgid=<20060628161055.8573.qmail@keila>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Jun 28 18:51:57 localhost sendmail[5856]: k5SHpX1W005829: to=<schmoo@localhost>, delay=00:00:02, xdelay=00:00:00, mailer=local, pri=43298, dsn=2.0.0, stat=Sent

Sorry for such a long post. I hope this helps with diagnosing the problem.
Thanks in advance for any help.

Regards,

Andrew

Re: [fetchmail-users] Multi-drop problems

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

On 6/28/06, Andrew Longland-Meech <an...@lo...> wrote:
> Hello list members,
>
> I hope someone can help me - I can't be the only person to have ever run
> into this problem. I've read the FAQ, but that doesn't seem to describe
> my situation and I've tried everything I can think of.
>
> Here's my setup:
>
> fetchmail version: 6.3.4

> My ISP provides forwarding from my own domain, and each and every email
> I receive has a proper Envelope-to; header.

Sample header, plus contents of .fetchmailrc?

> X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
> match any local name
>
> Does anyone have any suggestions?

Output of "fetchmail --nosyslog --nodetach -v -v -v" showing this,
along with the contents of your SMTP server's mail log for the same
mail would be useful.

-- 
                 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] [BUG] fetchmail daemon does not resume fetching after a network outage

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

Am 28.06.2006 um 18:18 schrieb Matthias Andree:
>> The other are actually 4 occurrences of freeaddrinfo() in  
>> checkalias.c that, via several function calls, end up being called  
>> in line 1430 in driver.c in the fetch_messages() call. Depending  
>> on the method you'll use, these could be tricky to handle, because  
>> as I said
>> there are several function calls between the fetch_messages() call  
>> and these freeaddrinfo() calls.
>
> I'm not very motivated to fix code that is not of much practical  
> value (since it assumes inbound MX and POP3/IMAP server are the  
> same) and that is scheduled for removal.

Of course that's up to you to decide. That's why I wrote that it's  
probably better you fix this instead of me because you do know the  
code much better. I have/had not the slightest idea what checkalias.c  
is for, I just parsed the complete fetchmail code for occurrences of  
freeaddrinfo() and looked if in the end they would be called from  
within do_session() in driver.c and were thus subject to a possible  
timeout interference.

Which of these occurrences are important, I leave completely up to  
you to decide.

             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

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

On Wed, 28 Jun 2006, Uli Zappe wrote:

> >I wonder if the resolver would finally recover a long time after  
> >the network connection has been restored
> 
> When I encountered this fetchmail bug for the first time in real  
> life, fetchmail had stopped fetching mails for several *days*. So  
> even if it recovered after a "long time", this would be of no  
> practical value at all.

OK, good to know. Thanks.

> The other are actually 4 occurrences of freeaddrinfo() in  
> checkalias.c that, via several function calls, end up being called in  
> line 1430 in driver.c in the fetch_messages() call. Depending on the  
> method you'll use, these could be tricky to handle, because as I said  
> there are several function calls between the fetch_messages() call  
> and these freeaddrinfo() calls.

I'm not very motivated to fix code that is not of much practical value
(since it assumes inbound MX and POP3/IMAP server are the same)
and that is scheduled for removal.

-- 
Matthias Andree

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

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

Am 28.06.2006 um 11:42 schrieb Matthias Andree:

> I wonder if the resolver would finally recover a long time after  
> the network connection has been restored

When I encountered this fetchmail bug for the first time in real  
life, fetchmail had stopped fetching mails for several *days*. So  
even if it recovered after a "long time", this would be of no  
practical value at all.

> - and perhaps if the negative TTL of cache entries can be configured.

I know of no such configuration possibilities in my case, but anyway,  
since getaddrinfo() works as it should once freeaddrinfo() is  
properly called, I don't think this is a caching issue at all.

> But OTOH, if you say that proper freeaddrinfo() use avoids the  
> problem, then we don't need to think about this part, because I  
> will add the missed freeaddrinfo() calls.

Exactly.

> I'll defend myself by calling these plain bugs, rather than not  
> taking these calls "not ... too seriously".

Just having a cursory glance at the remaining code, there are at  
least two other occurrences of freeaddrinfo() calls that could be  
prevented by a timeout in do_session() in driver.c:

One is directly in driver.c, line 1043.

The other are actually 4 occurrences of freeaddrinfo() in  
checkalias.c that, via several function calls, end up being called in  
line 1430 in driver.c in the fetch_messages() call. Depending on the  
method you'll use, these could be tricky to handle, because as I said  
there are several function calls between the fetch_messages() call  
and these freeaddrinfo() calls.

> Alright. Below is a fix to the problem you reported for servport.c  
> (it was easy to fix),

Indeed. :-)

> please try and let me know if MacOS X works with the IPPROTO_TCP  
> stuff.

Yep, it compiles just fine. Apart from that, there's not much to  
test, yet. :-)

             Bye
                     Uli
________________________________________________________

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

[fetchmail-users] Multi-drop problems

[Andrew Longland-M. <an...@lo...>]

Hello list members,

I hope someone can help me - I can't be the only person to have ever run
into this problem. I've read the FAQ, but that doesn't seem to describe
my situation and I've tried everything I can think of.

Here's my setup:

fetchmail version: 6.3.4
Kernel:	2.6.16-1.2080.13.rdt.rhfc5.ccrma
ISP: Freenetname.co.uk

My ISP provides forwarding from my own domain, and each and every email
I receive has a proper Envelope-to; header.

I want to have mail for (mypartner)@(mydomain).me.uk delivered to
localuser (mypartner) and everything else delivered to localuser (me).

Here's my .fetchmailrc file:

set postmaster "(me)"
set bouncemail
set no spambounce
set properties ""
#set daemon 900
poll mail.freenetname.co.uk with proto POP3 envelope "Envelope-to"
        user "(username)@freenetname.co.uk" with password "(*******)"
                to      "(mypartner)@(mydomain).me.uk"="(mypartner)"
                        "(username)@freenetname.co.uk"="(me)"
                        "(myname)@(mydomain).me.uk"="(me)"
                here
        options keep fetchall

Now, I think this is setup correctly, following the example in the man
page for a multi-drop setup, and indeed fetchmail seems to be using the
Envelope-to address according to the output of 'fetchmail -v -v' but it
simply isn't doing what it's supposed to and matching the server names
to the local names! Everything still gets delivered to (me) and contains
a header of the form -

X-Fetchmail-Warning: recipient address (Envelope-to address) didn't
match any local name

Does anyone have any suggestions?

Regards

Andrew

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

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

Am 28.06.2006 um 15:08 schrieb Matthias Andree:

> On Wed, 28 Jun 2006, Uli Zappe wrote:
>> I indeed see no other programming techniques to deal with that  
>> issue.)
> Well, some options not yet mentioned are (without regard to their  
> usability): [...long list...]

OK, you got me. :-)

             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

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

On Wed, 28 Jun 2006, Uli Zappe wrote:

> The only difference is the OFFSET value of the /dev/null files (these  
> OFFSET values stay the same after the network outage in several lsof  
> calls I've performed). Honestly, though, I have no idea what that  
> means. :-)

Whatever. More importantly, there are no sockets leaked, and that's
good.

-- 
Matthias Andree

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

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

On Wed, 28 Jun 2006, Uli Zappe wrote:

> >"you'll have to" or "you may have to" sounds more polite than "you  
> >must" (no offense taken, don't worry).
> 
> Well, the force of the laws of logic isn't polite ... ;-)  (This was  
> not meant to be a social "must" but rather a logical one, as I indeed  
> see no other programming techniques to deal with that issue.)

Well, some options not yet mentioned are (without regard to their
usability):

 - dedicated resource tracking with a specific list

 - store the address list in one of the per-server or per-poll
   structures, rather than globally

 - avoid the crude longjmp() (which should've been siglongjmp anyways)
   but rely on EINTR or similar.

 - give up on SIGALRM and use non-blocking I/O and select() instead.

I haven't yet checked which way I'll go though.

-- 
Matthias Andree

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:

> Can you check with "lsof" or similar tools (that can
> list open files and sockets) how many files and sockets fetchmail  
> holds
> open at the time when the problems start? It might be that the OS  
> itself
> is leaking sockets here which might appear in fetchmail's address  
> space.


Here is lsof output after a freshly restarted fetchmail that has  
fetched mails just once, and works fine:

# lsof -p 5894
COMMAND    PID USER   FD     TYPE     DEVICE SIZE/OFF     NODE NAME
fetchmail 5894 root  cwd     VDIR      14,10     1224        2 /
fetchmail 5894 root  txt     VREG      14,10   217276  4621091 /usr/ 
bin/fetchmail
fetchmail 5894 root  txt     VREG      14,10  1797788  4583305 /usr/ 
lib/dyld
fetchmail 5894 root  txt     VREG      14,10  4379472  4583478 /usr/ 
lib/libSystem.B.dylib
fetchmail 5894 root  txt     VREG      14,10  1227808  4583480 / 
System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
CoreFoundation
fetchmail 5894 root  txt     VREG      14,10   801160  4583488 /usr/ 
lib/libobjc.A.dylib
fetchmail 5894 root  txt     VREG      14,10  1789252  4583565 / 
System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
fetchmail 5894 root    0u    VCHR        3,2      0t0 53111684 /dev/null
fetchmail 5894 root    1u    VCHR        3,2      0t0 53111684 /dev/null
fetchmail 5894 root    2u    VCHR        3,2      0t0 53111684 /dev/null
fetchmail 5894 root    3r  PSXSHM 0x0511b424     4096           
obj=0x03680ee0
fetchmail 5894 root    4u    unix 0x04af53b0      0t0          - 
 >0x032f3b60



Here is the same output after a 2 hour network outage and then the  
Internet up again since 10 minutes or so, without fetchmail resuming  
fetching mails:

# lsof -p 5894
COMMAND    PID USER   FD     TYPE     DEVICE SIZE/OFF     NODE NAME
fetchmail 5894 root  cwd     VDIR      14,10     1224        2 /
fetchmail 5894 root  txt     VREG      14,10   217276  4621091 /usr/ 
bin/fetchmail
fetchmail 5894 root  txt     VREG      14,10  1797788  4583305 /usr/ 
lib/dyld
fetchmail 5894 root  txt     VREG      14,10  4379472  4583478 /usr/ 
lib/libSystem.B.dylib
fetchmail 5894 root  txt     VREG      14,10  1227808  4583480 / 
System/Library/Frameworks/CoreFoundation.framework/Versions/A/ 
CoreFoundation
fetchmail 5894 root  txt     VREG      14,10   801160  4583488 /usr/ 
lib/libobjc.A.dylib
fetchmail 5894 root  txt     VREG      14,10  1209056  4583589 /usr/ 
lib/libcrypto.0.9.7.dylib
fetchmail 5894 root  txt     VREG      14,10  1789252  4583565 / 
System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
fetchmail 5894 root    0u    VCHR        3,2    0t293 53111684 /dev/null
fetchmail 5894 root    1u    VCHR        3,2    0t293 53111684 /dev/null
fetchmail 5894 root    2u    VCHR        3,2    0t293 53111684 /dev/null
fetchmail 5894 root    3r  PSXSHM 0x0511b424     4096           
obj=0x03680ee0
fetchmail 5894 root    4u    unix 0x04af53b0      0t0          - 
 >0x032f3b60



The only difference is the OFFSET value of the /dev/null files (these  
OFFSET values stay the same after the network outage in several lsof  
calls I've performed). Honestly, though, I have no idea what that  
means. :-)


             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

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

On Wed, 28 Jun 2006, Uli Zappe wrote:

> Well, you *can* call getaddrinfo() a second time before calling  
> freeaddrinfo() first in Mac OS X without a crash or anything, and  
> it's thread-safe since Mac OS X 10.2 (though not before). The only  
> thing is that if you call it again with exactly the same query data  
> and without calling freeaddrinfo() in between, it will report the  
> data it cached from the last call. You might call this a bug, but  
> Apple most probably will call it a feature ... Note that on Mac OS X,  
> getaddrinfo() is nothing more than a wrapper around the system's so- 
> called "lookupd" daemon, which handles all network addressing issues  
> with code that's completely different from all other Unix  
> implementations.

Nothing wrong here.

> If with "amount of time" you refer to the fact that the Internet must  
> be down a certain amount of time for the issue to occur, this seems  
> to be because the DNS data is cached for a certain amount of time,  
> either by getaddrinfo() itself, or by Mac OS X's local caching BIND,  
> or possibly by the caching name server of my router. Only when  
> there's no cache anymore and getaddrinfo() (unsuccessfully) tries to  
> retrieve that query data anew from the Internet, the timeout  
> interruption will occur and prevent freeaddrinfo() from being called.
> 
> At least that's how I interpret all these error lines in my  
> logfiles. ;-)

Well, that's plausible, but I wonder if the resolver would finally
recover a long time after the network connection has been restored - and
perhaps if the negative TTL of cache entries can be configured.

But OTOH, if you say that proper freeaddrinfo() use avoids the problem,
then we don't need to think about this part, because I will add the
missed freeaddrinfo() calls.

> Maybe it's a good idea to check for all occurrences of freeaddrinfo()  
> whether they are certain to be performed whenever they should.  
> Glimpsing at the code, e.g. in servport.c, line 65, the default  
> switch condition is a goto jump that prevents freeaddrinfo() from  
> being called, although it should be called (getaddrinfo() had  
> returned 0/success before, so "res" had been allocated). It seems  
> that calling freeaddrinfo() was not taken all too seriously  
> throughout fetchmail.

I'll defend myself by calling these plain bugs, rather than not taking
these calls "not ... too seriously".

> Well, the force of the laws of logic isn't polite ... ;-)  (This was  
> not meant to be a social "must" but rather a logical one, as I indeed  
> see no other programming techniques to deal with that issue.)

Perhaps not in C. In the long run (fetchmail 7 or thereabouts), I might
switch to something more OOP-like so I can use objects that know how to
destruct themselves. (C++ is most likely from today's point of view.)

> Well, that's more than OK with me! If you deal with bugs in  
> connection with Mac OS X, what you are afraid of are months or years  
> until a fix is applied - days are no problem at all.  :-)

Alright. Below is a fix to the problem you reported for servport.c (it
was easy to fix), please try and let me know if MacOS X works with the
IPPROTO_TCP stuff.  The other getaddrinfo() calls require more attention
and I'll see to them later.
The "NEWS" hunk below will probably fail to apply, this is harmless.

-- 
Matthias Andree