fetchmail-users — User questions and discussion

Re: [fetchmail-users] Correction to example in fetchmail(1) manual page

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

On Mon, Dec 19, 2005 at 01:33:33AM +0100, Matthias Andree wrote:
> 
> Thank you.  Does it document relevant changes to the x509 command, or
> what does the x509 manual page say WRT the default hash?

       -md2|-md5|-sha1|-mdc2
           the digest to use. This affects any signing or display option that
           uses a message digest, such as the -fingerprint, -signkey and -CA
           options. If not specified then SHA1 is used. If the key being used
           to sign with is a DSA key then this option has no effect: SHA1 is
           always used with DSA keys.

Re: [fetchmail-users] Correction to example in fetchmail(1) manual page

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

Jason White <jas...@in...> writes:

> On Sun, Dec 18, 2005 at 11:06:53AM +0100, Matthias Andree wrote:
>  
>> OpenSSL 0.9.7g's x509(1ssl) documents that the default were MD5 for
>> everything except DSA, which is forced to SHA1. Which OpenSSL version
>> are you using?

> The latest Debian Unstable package. It reports its version as
> OpenSSL 0.9.8a, 11 Oct 2005.

Thank you.  Does it document relevant changes to the x509 command, or
what does the x509 manual page say WRT the default hash?

-- 
Matthias Andree

Re: [fetchmail-users] Correction to example in fetchmail(1) manual page

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

On Sun, Dec 18, 2005 at 11:06:53AM +0100, Matthias Andree wrote:
 
> OpenSSL 0.9.7g's x509(1ssl) documents that the default were MD5 for
> everything except DSA, which is forced to SHA1. Which OpenSSL version
> are you using?
The latest Debian Unstable package. It reports its version as
OpenSSL 0.9.8a, 11 Oct 2005.

[fetchmail-users] fetchmail 6.3.1 release candidate - please test

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

I have released the final 6.3.1 release candidate,
dubbed fetchmail-6.3.1-rc1. It is available from
http://home.pages.de/~mandree/fetchmail/

Unless regressions since 6.3.0 are found, this will be released
as 6.3.1 somewhen next week.

The French translation lacks six messages I cannot translate properly by
myself, help will be appreciated (just send the missing msgid/msgstr
pairs to me either on- or off-list).

Please follow up to <fet...@li...> only.

Note that the fetchmail-friends@ list is supposed to be discontinued,
please resubscribe at BerliOS, for information, please see
<https://lists.berlios.de/mailman/listinfo/fetchmail-users>

These are the changes since 6.3.0:

>-------------------------------------------------------------------------------
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release. (MA)
>-------------------------------------------------------------------------------
* Fix broken default port in POP2. Patch by Stanislav Brabec, SUSE [CZ]. (MA)
* Fix manual page, some lines starting with ' were escaped by \&.
  Reported by Simon Barner. (MA)
* Ship with gettext-0.14.3 again, as 6.2.9-rc10 did. Found by Sunil Shetye. (MA)
* Actually set default SSL certificate path if --sslcertpath is unset.
  Reported by Heino Tiedemann and Rob MacGregor. (MA)
* Remove bogus Netscape IMAP4rev1 Service >= 3.6 warning about BODY[TEXT]
  that we are not using. Patch by Sunil Shetye. (MA)
* Plug potential memory and socket leak when polling multiple folders or when
  the upstream sends bogus message sizes.  Patch by Sunil Shetye. (MA)
* Fix segfault (null pointer dereference) in multidrop mode with headerless
  email.  Reported by Daniel Drake, patch by Sunil Shetye. (MA)
* Update Catalan translation, by Ernest Adrogué Calveras. (MA)
* Fix segfault (null pointer dereference) on some operating systems with
  fetchmail's obsolete DNS MX/host alias lookups in multidrop mode.
  Patch by Dr.-Ing. Andreas Haakh. (MA)
* Close SMTP sockets early, to reduce resource usage, trigger earlier delivery
  with some MTAs and avoid SIGPIPE (SIG 13) when the SMTP listener gets bored
  and drops the connection after timeout.  Patch by Sunil Shetye. (MA)
* Don't treat hitting a fetch limit as error.  Patch by Sunil Shetye. (MA)
* Fix negative "messages left on server" on idle/repoll with fetchlimit.
  Patch by Sunil Shetye. (MA)
* Properly track logout stage.  Patch by Sunil Shetye. (MA)
* Preserve error conditions across postconnect script.  Sunil Shetye. (MA)
* Do not trash destination domain if multiple messages are forwarded into the
  same SMTP/LMTP connection. Reported by Joachim Feise, Berlios Bug #5849. (MA)
  (This patch had not been committed to SVN at the time of the 6.3.1-pre1
  release on 2005-12-13.)
* Manual page: Add "-md5" to "openssl x509" example in --sslfingerprint
  documentation.  Suggested by Jason White. (MA)
* Cope with servers that return UID information in response to non-UID
  RFC822.{SIZE|HEADER} requests. Reported by Jason White.
  Patch suggestion by by Sunil Shetye, simplified by MA.
>-------------------------------------------------------------------------------

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDpUR3vmGDOQUufZURAguXAJ9tslzlbNY3Xn7LiWwQdOqZfUXIlACgi6mJ
9glYchTf96xevABPML/kByE=
=o61G
-----END PGP SIGNATURE-----

Re: [fetchmail-users] [PATCH] Re: IMAP problem (fetchmail 6.3.1-pre1)

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

Jason White <jas...@in...> writes:

> On Sat, Dec 17, 2005 at 03:52:30PM +0100, Matthias Andree wrote:
>> Sunil Shetye <sh...@bo...> writes:
>> 
>> > Matthias, please consider this patch for 6.3.1.
>> 
>> I wonder if it's the right thing to do, or if the server of the day
>> might return the flags or some other information along with the size. I
>> had a quick glance at the standard, and I'm not at all sure if it's
>> allowed for the server to return excess information. 
> There is a statemenn section 2.2.2, but I am not sure whether it is meant to
> cover this case:
> "   A client MUST be prepared to accept any server response at all times.
>    This includes server data that was not requested.  Server data SHOULD
>    be recorded, so that the client can reference its recorded copy
>    rather than sending a command to the server to request the data.  In
>    the case of certain server data, the data MUST be recorded.
>
>    This topic is discussed in greater detail in the Server Responses
>    section."
>
> I couldn't find any more specific guidance in section 7, but then I didn't
> read it carefully. Also, this could be read as implying only to entire
> responses and not to additional data included within responses that are
> requested.

Well, I'll just use an equivalent modification of Sunil's patch for
6.3.1, because, after looking at the respective code, the entire IMAP
response parser must be rewritten - for instance, to support the ALERT
response code or * BYE. And this rewrite is stuff for 6.4.0.

We'll just use the minimal change that fixes the problem in 6.3.1. I'll
release 6.3.1-rc1 later, and I'd ask you to test again so that my
changes haven't broken the fix.

-- 
Matthias Andree

Re: [fetchmail-users] Correction to example in fetchmail(1) manual page

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

Jason White <jas...@in...> writes:

> Under the description of the sslfingerprint option, an example is provided
> showing how to use openssl to extract the fingerprint.
>
> I found that the -md5 option had to be included on the openssl command line to
> obtain an MD5 fingerprint; otherwise, openssl defaulted to SHA-1. Thus the
> example should be
> openssl x509 -in cert.pem -noout -md5 -fingerprint

OpenSSL 0.9.7g's x509(1ssl) documents that the default were MD5 for
everything except DSA, which is forced to SHA1. Which OpenSSL version
are you using?

I will change the manual page nonetheless, since fetchmail itself is
hardcoded to use MD5 at this time (we'll have to change _that_ for
6.4.0, too, and offer other fingerprints).

Thank you for your report.

-- 
Matthias Andree

[fetchmail-users] Correction to example in fetchmail(1) manual page

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

Under the description of the sslfingerprint option, an example is provided
showing how to use openssl to extract the fingerprint.

I found that the -md5 option had to be included on the openssl command line to
obtain an MD5 fingerprint; otherwise, openssl defaulted to SHA-1. Thus the
example should be
openssl x509 -in cert.pem -noout -md5 -fingerprint

Re: [fetchmail-users] [PATCH] Re: IMAP problem (fetchmail 6.3.1-pre1)

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

On Sat, Dec 17, 2005 at 03:52:30PM +0100, Matthias Andree wrote:
> Sunil Shetye <sh...@bo...> writes:
> 
> > Matthias, please consider this patch for 6.3.1.
> 
> I wonder if it's the right thing to do, or if the server of the day
> might return the flags or some other information along with the size. I
> had a quick glance at the standard, and I'm not at all sure if it's
> allowed for the server to return excess information. 
There is a statemenn section 2.2.2, but I am not sure whether it is meant to
cover this case:
"   A client MUST be prepared to accept any server response at all times.
   This includes server data that was not requested.  Server data SHOULD
   be recorded, so that the client can reference its recorded copy
   rather than sending a command to the server to request the data.  In
   the case of certain server data, the data MUST be recorded.

   This topic is discussed in greater detail in the Server Responses
   section."

I couldn't find any more specific guidance in section 7, but then I didn't
read it carefully. Also, this could be read as implying only to entire
responses and not to additional data included within responses that are
requested.

Note also that in Fetchmail, imap_fetch_body() loops until it finds the
required response.
> 
> At any case, if a server does that, we're dead in the water again. I'd
> rather use a bit more of a parser to take the fetch response apart.
I agree with this and would be interested in an interpretation of the RFC as
well regarding whether this is expected of the client. At least it might be
considered good practice; Fetchmail already contains code to deal with the
eccentricities of various servers and it wouldn't hurt to generalize it here
if you consider it appropriate to do so.

Re: [fetchmail-users] [PATCH] Re: IMAP problem (fetchmail 6.3.1-pre1)

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

Sunil Shetye <sh...@bo...> writes:

> Matthias, please consider this patch for 6.3.1.

I wonder if it's the right thing to do, or if the server of the day
might return the flags or some other information along with the size. I
had a quick glance at the standard, and I'm not at all sure if it's
allowed for the server to return excess information. 

At any case, if a server does that, we're dead in the water again. I'd
rather use a bit more of a parser to take the fetch response apart.

If we choose not to do that, the patch can be simplified and use this
structure:

   if (sscanf(s, "pattern", ...) == 2
    || sscanf(s, "other pattern", ...) == 2)
   {
      do whatever is appropriate
   }

What do you think?

-- 
Matthias Andree

[fetchmail-users] [PATCH] Re: IMAP problem (fetchmail 6.3.1-pre1)

[Sunil S. <sh...@bo...>]

Quoting from Jason White's mail on Sat, Dec 17, 2005:
> On Fri, Dec 16, 2005 at 05:01:58PM +0530, Sunil Shetye wrote:
>  
> > Your IMAP server is also sending UID information in the response. It
> > needs to be checked if sending UIDs in response is valid or not.
> Yes, I was wondering whether the server was conforming to the RFC.
> > 
> > fetchmail is not expecting UIDs in the response. Hence the protocol
> > error. Could you try this patch and tell me if it works for you? Note
> > that you may get more errors if UIDs are sent in further responses
> > (like RFC822.TEXT) which have not been reached yet.
> With the patch applied, Fetchmail read and delivered the entire message. Here
> is the log of the body portion:
> Dec 17 10:38:26 jdc fetchmail[4404]: IMAP> A0007 FETCH 1 BODY.PEEK[TEXT] 
> Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< * 1 FETCH (UID 17 BODY[TEXT] {94} 
> Dec 17 10:38:26 jdc fetchmail[4404]:  (94 body octets) 
> Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< ) 
> 
> Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< A0007 OK FETCH completed 
> 
> I can carry out whatever further testing you consider appropriate, either to
> this or to any generalized version of the patch that you decide to create.
> I haven't tried messages with attachments yet, but thought I should report the
> initial results.

Thanks for your update. It looks like the code reading the response to
BODY[TEXT] is far more liberal. So, no further patches and tests are
required.

Here is the same patch with comments updated.

Matthias, please consider this patch for 6.3.1.

Index: fetchmail/imap.c
===================================================================
--- fetchmail/imap.c	(revision 4550)
+++ fetchmail/imap.c	(working copy)
@@ -880,8 +880,24 @@
 	    if (num >= first && num <= last)
 	        sizes[num - first] = size;
 	    else
-		report(stderr, "Warning: ignoring bogus data for message sizes returned by the server.\n");
+		report(stderr,
+			GT_("Warning: ignoring bogus data for message sizes returned by the server.\n"));
 	}
+	/* some servers (like mail.internode.on.net bld-mail04) return UID information here
+	 *
+	 * IMAP> A0005 FETCH 1 RFC822.SIZE
+	 * IMAP< * 1 FETCH (UID 16 RFC822.SIZE 1447)
+	 * IMAP< A0005 OK FETCH completed
+	 *
+	 */
+	else if (sscanf(buf, "* %u FETCH (UID %*s RFC822.SIZE %u)", &num, &size) == 2)
+	{
+	    if (num >= first && num <= last)
+	        sizes[num - first] = size;
+	    else
+		report(stderr,
+			GT_("Warning: ignoring bogus data for message sizes returned by the server.\n"));
+	}
     }
 
     return(PS_SUCCESS);
@@ -948,8 +964,19 @@
 	if ((ok = gen_recv(sock, buf, sizeof(buf))))
 	    return(ok);
  	ptr = skip_token(buf);	/* either "* " or "AXXXX " */
- 	if (sscanf(ptr, "%d FETCH (%*s {%d}", &num, lenp) == 2)
+	if (sscanf(ptr, "%d FETCH (RFC822.HEADER {%d}", &num, lenp) == 2)
   	    break;
+	/* some servers (like mail.internode.on.net bld-mail04) return UID information here
+	 *
+	 * IMAP> A0006 FETCH 1 RFC822.HEADER
+	 * IMAP< * 1 FETCH (UID 16 RFC822.HEADER {1360}
+	 * ...
+	 * IMAP< )
+	 * IMAP< A0006 OK FETCH completed
+	 *
+	 */
+	else if (sscanf(ptr, "%d FETCH (UID %*s RFC822.HEADER {%d}", &num, lenp) == 2)
+	    break;
 	/* try to recover from chronically fucked-up M$ Exchange servers */
  	else if (!strncmp(ptr, "NO", 2))
 	{

-- 
Sunil Shetye.

Re: [fetchmail-users] Re: IMAP problem (fetchmail 6.3.1-pre1)

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

On Fri, Dec 16, 2005 at 05:01:58PM +0530, Sunil Shetye wrote:
 
> Your IMAP server is also sending UID information in the response. It
> needs to be checked if sending UIDs in response is valid or not.
Yes, I was wondering whether the server was conforming to the RFC.
> 
> fetchmail is not expecting UIDs in the response. Hence the protocol
> error. Could you try this patch and tell me if it works for you? Note
> that you may get more errors if UIDs are sent in further responses
> (like RFC822.TEXT) which have not been reached yet.
With the patch applied, Fetchmail read and delivered the entire message. Here
is the log of the body portion:
Dec 17 10:38:26 jdc fetchmail[4404]: IMAP> A0007 FETCH 1 BODY.PEEK[TEXT] 
Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< * 1 FETCH (UID 17 BODY[TEXT] {94} 
Dec 17 10:38:26 jdc fetchmail[4404]:  (94 body octets) 
Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< ) 

Dec 17 10:38:26 jdc fetchmail[4404]: IMAP< A0007 OK FETCH completed 

I can carry out whatever further testing you consider appropriate, either to
this or to any generalized version of the patch that you decide to create.
I haven't tried messages with attachments yet, but thought I should report the
initial results.

[fetchmail-users] Re: IMAP problem (fetchmail 6.3.1-pre1)

[Sunil S. <sh...@bo...>]

Quoting from Jason White's mail on Fri, Dec 16, 2005:
> I am quite confident this is a protocol issue, but I don't know IMAP and
> Fetchmail well enough to debug it. For some reason, it appears that Fetchmail
> doesn't detect the final "OK" message from the server and simply times out
> after retrieving the headers. Using an MUA (e.g., muttng), I can successfully
> retrieve messages via IMAP from this server. For the moment, I have configured
> fetchmail to use pop3 instead as a work-around so I can read mail easily from
> this account.

Your IMAP server is also sending UID information in the response. It
needs to be checked if sending UIDs in response is valid or not.

> From syslog:

...

> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0005 FETCH 1 RFC822.SIZE 
> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 FETCH (UID 16 RFC822.SIZE 1447) 
                                                         ^^^^^^
> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0005 OK FETCH completed 

> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0006 FETCH 1 RFC822.HEADER 
> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 FETCH (UID 16 RFC822.HEADER {1360} 
                                                         ^^^^^^

...

> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0006 OK FETCH completed 

fetchmail is not expecting UIDs in the response. Hence the protocol
error. Could you try this patch and tell me if it works for you? Note
that you may get more errors if UIDs are sent in further responses
(like RFC822.TEXT) which have not been reached yet.

Here's the patch:

Index: fetchmail/imap.c
===================================================================
--- fetchmail/imap.c	(revision 4550)
+++ fetchmail/imap.c	(working copy)
@@ -880,8 +880,18 @@
 	    if (num >= first && num <= last)
 	        sizes[num - first] = size;
 	    else
-		report(stderr, "Warning: ignoring bogus data for message sizes returned by the server.\n");
+		report(stderr,
+			GT_("Warning: ignoring bogus data for message sizes returned by the server.\n"));
 	}
+	/* some servers return UID information here */
+	else if (sscanf(buf, "* %u FETCH (UID %*s RFC822.SIZE %u)", &num, &size) == 2)
+	{
+	    if (num >= first && num <= last)
+	        sizes[num - first] = size;
+	    else
+		report(stderr,
+			GT_("Warning: ignoring bogus data for message sizes returned by the server.\n"));
+	}
     }
 
     return(PS_SUCCESS);
@@ -948,8 +958,11 @@
 	if ((ok = gen_recv(sock, buf, sizeof(buf))))
 	    return(ok);
  	ptr = skip_token(buf);	/* either "* " or "AXXXX " */
- 	if (sscanf(ptr, "%d FETCH (%*s {%d}", &num, lenp) == 2)
+	if (sscanf(ptr, "%d FETCH (RFC822.HEADER {%d}", &num, lenp) == 2)
   	    break;
+	/* some servers return UID information here */
+	else if (sscanf(ptr, "%d FETCH (UID %*s RFC822.HEADER {%d}", &num, lenp) == 2)
+	    break;
 	/* try to recover from chronically fucked-up M$ Exchange servers */
  	else if (!strncmp(ptr, "NO", 2))
 	{

-- 
Sunil Shetye.

Re: [fetchmail-users] IMAP problem (fetchmail 6.3.1-pre1)

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

Jason White <jas...@in...> writes:

> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0006 FETCH 1 RFC822.HEADER 
> Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 FETCH (UID 16
> RFC822.HEADER {1360} 

Well, this tells fetchmail that 1360 bytes (octets) will
follow. Since this works for me with a Dovecot upstream server, I wonder
if it's really fetchmail's fault or perhaps SurgeMail's.

Could I possibly get a test mail account on that server to find out
which software is wrong?  If so, please send the IMAP server, mail
address (where I would send test messages), account and password or
other credentials off-list. The X-PGP-Key header mentions my GnuPG key
so encrypted communication is possible (and should be used).

If that is not possible, can you change your password, run ethereal,
tethereal or tcpdump -s5000 to capture to a file (the tcpdump filter
rule would be "host mail.internode.on.net and port 143"), run fetchmail
once, then change your password again and mail me the resulting tcpdump
or tethereal capture file? It contains the password, hence the hassle
with changing it. Looking at the tcpdump/tethereal dump should also give
us an idea which of the two sides miscounted the message size.

> Dec 16 18:40:33 jdc fetchmail[13415]: timeout after 30 seconds waiting for server mail.internode.on.net. 
> Dec 16 18:40:33 jdc fetchmail[13415]: socket error while fetching from jas...@ma... 

Thank you for retrying with 6.3.1-pre1 and reporting your problem.

-- 
Matthias Andree

[fetchmail-users] IMAP problem (fetchmail 6.3.1-pre1)

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

I initially raised this question on the fetchmail-friends list, but was wisely
advised to test with 6.3.1-pre1 and bring the problem here.

I am quite confident this is a protocol issue, but I don't know IMAP and
Fetchmail well enough to debug it. For some reason, it appears that Fetchmail
doesn't detect the final "OK" message from the server and simply times out
after retrieving the headers. Using an MUA (e.g., muttng), I can successfully
retrieve messages via IMAP from this server. For the moment, I have configured
fetchmail to use pop3 instead as a work-around so I can read mail easily from
this account.

From syslog:

Dec 16 18:40:02 jdc fetchmail[13415]: 6.3.1-pre1 querying mail.internode.on.net (protocol IMAP) at Fri Dec 16 18:40:02 2005: poll started 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * OK internode.on.net bld-mail04 Ready 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0001 CAPABILITY 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * CAPABILITY IMAP4 IMAP4REV1 NAMESPACE QUOTA UIDPLUS IDLE XFLDDATA SURGEMAIL 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0001 OK CAPABILITY completed 
Dec 16 18:40:03 jdc fetchmail[13415]: Protocol identified as IMAP4 rev 1 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0002 LOGIN "jasonjgw" * 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0002 OK LOGIN completed 
Dec 16 18:40:03 jdc fetchmail[13415]: selecting or re-polling default folder 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0003 SELECT "INBOX" 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 EXISTS 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 0 RECENT 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * OK [UIDVALIDITY 1134522857] UIDs valid 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Draft \Seen)] Limited 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0003 OK [READ-WRITE] SELECT completed 
Dec 16 18:40:03 jdc fetchmail[13415]: 1 message waiting after first poll 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0004 EXPUNGE 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0004 OK EXPUNGE completed 
Dec 16 18:40:03 jdc fetchmail[13415]: 1 message waiting after expunge 
Dec 16 18:40:03 jdc fetchmail[13415]: 1 message for jasonjgw at mail.internode.on.net. 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0005 FETCH 1 RFC822.SIZE 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 FETCH (UID 16 RFC822.SIZE 1447) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0005 OK FETCH completed 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP> A0006 FETCH 1 RFC822.HEADER 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< * 1 FETCH (UID 16 RFC822.HEADER {1360} 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Received: from beatrice.nipl.net (unverified [62.94.93.142])  
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Iby mail.internode.on.net (SurgeMail 3.2f) with ESMTP id 4426396  
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Ifor <jas...@in...>; Fri, 16 Dec 2005 18:09:13 +1030 (CDT) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Return-Path: <ja...@ni...> 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Received: from localhost (localhost.localdomain [127.0.0.1]) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Iby beatrice.nipl.net (Postfix) with ESMTP id 0336EE8624 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Ifor <jas...@in...>; Fri, 16 Dec 2005 07:39:04 +0000 (UTC) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Received: from beatrice.nipl.net ([127.0.0.1]) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Iby localhost (beatrice.nipl.net [127.0.0.1]) (amavisd-new, port 10024) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Iwith ESMTP id 01175-07 for <jas...@in...>; 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^IFri, 16 Dec 2005 07:39:01 +0000 (UTC) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Received: by beatrice.nipl.net (Postfix, from userid 1010) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ^Iid 79CEBE8644; Fri, 16 Dec 2005 07:39:01 +0000 (UTC) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Date: Fri, 16 Dec 2005 18:39:00 +1100 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< From: Jason White <ja...@ni...> 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< To: jas...@in... 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Subject: Fetchmail test for 6.3.1 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Message-ID: <200...@ni...> 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Mime-Version: 1.0 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Content-Type: text/plain; charset=us-ascii 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< Content-Disposition: inline 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< User-Agent: Mutt/1.5.9i 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at nipl.net 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-Rcpt-To: <jas...@in...> 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-Vpipe: Scanner said clean (/usr/local/clamav/sbin/vscand-clamav) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-NotAscii: charset=us-ascii 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-IP-stats: Incoming Last 0, First 0, in=1, out=0, spam=0 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< X-External-IP: 62.94.93.142 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP<  
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< ) 
Dec 16 18:40:03 jdc fetchmail[13415]: IMAP< A0006 OK FETCH completed 
Dec 16 18:40:33 jdc fetchmail[13415]: timeout after 30 seconds waiting for server mail.internode.on.net. 
Dec 16 18:40:33 jdc fetchmail[13415]: socket error while fetching from jas...@ma... 
Dec 16 18:40:33 jdc fetchmail[13415]: 6.3.1-pre1 querying mail.internode.on.net (protocol IMAP) at Fri Dec 16 18:40:33 2005: poll completed 
Dec 16 18:40:33 jdc fetchmail[13415]: Query status=2 (SOCKET) 
Dec 16 18:40:33 jdc fetchmail[13415]: Deleting fetchids file. 
Dec 16 18:40:33 jdc fetchmail[13415]: sleeping at Fri Dec 16 18:40:33 2005 

Configuration:

# global options
set daemon 60
set syslog
# Server options (mail.internode.on.net)
poll mail.internode.on.net
protocol imap
timeout 30
# User options (internode.on.net)
username jasonjgw is jason here
password secret
fetchall

Re: [fetchmail-users] comcast.net pop3 broken after 5.9.12 upgraded

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

On 15/12/05, Denis Hainsworth <de...@al...> wrote:
> hello all,
> fetchmail has been awesome and worked flawlessly for years for me, thats
> why this is so odd.  my system is redhat fedora core 3ish (i upgrade
> packages as I need to) anyway I had an rpm of fetchmail 5.9.12 installed
> which was working fine.  I did something dumb with postfix and stopped
> receiving mail, while troubleshooting it I upgraded fetchmail to
> fetchmail-6.2.5-7.fc4.1.i386.rpm.  Once I found my problem with postfix
> I verified that fetchmail could connect to my univeristy IMAP account
> and it started downloading my mail.  Great.  Several days later I
> realized I was no longer receiving mail from my comcast.new pop3 acocunt
> which is AFTER my IMAP account in my fetchmailrc file.
<---SNIP--->
> -- fetchmailrc file --
>
> poll mail.comcast.net with proto pop3:
>   user xxxxxxxxx is xxxxxxxx here pass xxxxxxxxx options fetchall

That would appear to be less than the entire file, given your initial
statement.  What does the entire .fetchmailrc file look like?

However, once you install 6.3.x we really need to see the output of
that - it's little use providing us with diagnostic output of
everything *but* the version you're having problems with :-)

--
                 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] comcast.net pop3 broken after 5.9.12 upgraded

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

Denis Hainsworth <de...@al...> writes:

> fetchmail has been awesome and worked flawlessly for years for me, thats
> why this is so odd.  my system is redhat fedora core 3ish (i upgrade
> packages as I need to) anyway I had an rpm of fetchmail 5.9.12 installed
> which was working fine.  I did something dumb with postfix and stopped
> receiving mail, while troubleshooting it I upgraded fetchmail to 
> fetchmail-6.2.5-7.fc4.1.i386.rpm.  Once I found my problem with postfix
> I verified that fetchmail could connect to my univeristy IMAP account
> and it started downloading my mail.  Great.  Several days later I
> realized I was no longer receiving mail from my comcast.new pop3 acocunt
> which is AFTER my IMAP account in my fetchmailrc file.

Can you try fetchmail-6.3.0 or 6.3.1-pre1 and see if the problem
persists? There have been dozens of bugfixes since 6.2.5.

> [624] christmas /home/denis% fetchmail -v -v
> fetchmail: 5.9.13 querying mail.comcast.net (protocol POP3) at Thu, 15
> Dec 2005 16:56:18 -0500 (EST): poll started
> fetchmail: fetchmail: getaddrinfo(mail.comcast.net.pop3)
> fetchmail: 5.9.13 querying mail.comcast.net (protocol POP3) at Thu, 15
> Dec 2005 16:56:18 -0500 (EST): poll completed
> fetchmail: Query status=2 (SOCKET)
> fetchmail: Deleting fetchids file.
> fetchmail: normal termination, status 2
> fetchmail: Deleting fetchids file.

getaddrinfo is, AFAIR, only used if inet6 is enabled. Does your system
have complete IPv6 implementation, recent (i. e. no older than what was
shipped with Fedora Core 3) glibc, resolver and similar code? Is your
glibc fit for a 2.6 kernel? Pre-2.6 user space may cause trouble on 2.6
kernels, and unfortunately, Linux 2.6.X is not what other operating
systems or software programmers would call "stable".

While Linux 2.6.6 is generally speaking new enough for IPv6, if you
upgrade packages as opportunity arises, this in itself may introduce
inconsistencies that cause all kinds of problems.

This is really hard to debug, if the 6.3.0 (or 6.3.1-pre1) still fail,
perhaps strace can shed some light.

See http://home.pages.de/~mandree/fetchmail/ or
    http://fetchmail.berlios.de/
for downloads of 6.3.1-pre1 and 6.3.0, respectively.

-- 
Matthias Andree

[fetchmail-users] comcast.net pop3 broken after 5.9.12 upgraded

[Denis H. <de...@al...>]

hello all,
fetchmail has been awesome and worked flawlessly for years for me, thats
why this is so odd.  my system is redhat fedora core 3ish (i upgrade
packages as I need to) anyway I had an rpm of fetchmail 5.9.12 installed
which was working fine.  I did something dumb with postfix and stopped
receiving mail, while troubleshooting it I upgraded fetchmail to 
fetchmail-6.2.5-7.fc4.1.i386.rpm.  Once I found my problem with postfix
I verified that fetchmail could connect to my univeristy IMAP account
and it started downloading my mail.  Great.  Several days later I
realized I was no longer receiving mail from my comcast.new pop3 acocunt
which is AFTER my IMAP account in my fetchmailrc file.

After trying a number of different RPMs I grabbed my old working
fetchmail binary from a backup and low and behold everything was fine
again.  As you can see from the enclosed files there is not much of an
error.  More like a lack of anything.  I tried to capture the pop3
packets with ethereal and never saw anything after the host lookup.

So anyway I was curious if anyone had any ideas. Right now I am fine
running 5.9.12. I have tried the earliest RPM I can find which is
fetchmail-5.9.13-1.i386.rpm and it has the same problems.  Output from
both the working and non-working versions is included below.

-- fetchmailrc file --

poll mail.comcast.net with proto pop3:
  user xxxxxxxxx is xxxxxxxx here pass xxxxxxxxx options fetchall


-- output of fetchmail -v -v version 5.9.12

[620] christmas /home/denis% fetchmail -v -v
fetchmail: 5.9.12 querying mail.comcast.net (protocol POP3) at Thu, 15
Dec 2005 16:54:21 -0500 (EST): poll started
fetchmail: POP3< +OK (rwcrpxc60) Maillennium POP3/PROXY server #176
fetchmail: POP3> USER xxxxxxxxxx
fetchmail: POP3< +OK
fetchmail: POP3> PASS 
fetchmail: POP3< +OK ready
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for xxxxxxxxx at mail.comcast.net
fetchmail: POP3> QUIT
fetchmail: POP3< +OK comcast.net
fetchmail: 5.9.12 querying mail.comcast.net (protocol POP3) at Thu, 15
Dec 2005 16:54:24 -0500 (EST): poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 1
fetchmail: Deleting fetchids file.

-- output of fetchmail -v -v version 5.9.13

[624] christmas /home/denis% fetchmail -v -v
fetchmail: 5.9.13 querying mail.comcast.net (protocol POP3) at Thu, 15
Dec 2005 16:56:18 -0500 (EST): poll started
fetchmail: fetchmail: getaddrinfo(mail.comcast.net.pop3)
fetchmail: 5.9.13 querying mail.comcast.net (protocol POP3) at Thu, 15
Dec 2005 16:56:18 -0500 (EST): poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 2
fetchmail: Deleting fetchids file.

-- output of fetchmail -V version 5.9.12

[637] christmas /home/denis% fetchmail -V
This is fetchmail release 5.9.12
Linux christmas.auspice.net 2.6.6 #7 Sun Jun 27 15:44:05 EDT 2004 i686
i686 i386 GNU/Linux
Taking options from command line and /home/denis/.fetchmailrc
Idfile is /home/denis/.fetchids
Fetchmail will forward misaddressed multidrop messages to denis.
Options for retrieving from den...@ma...:
  True name of server is mail.comcast.net.
  Protocol is POP3.
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush
off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits
off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Messages will be SMTP-forwarded to: localhost (default)
  Recognized listener spam block responses are: 571 550 501 554
  Single-drop mode: 1 local name(s) recognized.
  No UIDs saved from this host.


-- output of fetchmail -V version 5.9.13

[635] christmas /home/denis% fetchmail -V
This is fetchmail release 5.9.13+INET6
Fallback MDA: (none)
Linux christmas.auspice.net 2.6.6 #7 Sun Jun 27 15:44:05 EDT 2004 i686
i686 i386 GNU/Linux
Taking options from command line and /home/denis/.fetchmailrc
Idfile is /home/denis/.fetchids
Fetchmail will forward misaddressed multidrop messages to denis.
Options for retrieving from den...@ma...:
  True name of server is mail.comcast.net.
  Protocol is POP3.
  All available authentication methods will be tried.
  Server nonresponse timeout is 300 seconds (default).
  Default mailbox selected.
  All messages will be retrieved (--all on).
  Fetched messages will not be kept on the server (--keep off).
  Old messages will not be flushed before message retrieval (--flush
off).
  Rewrite of server-local addresses is enabled (--norewrite off).
  Carriage-return stripping is disabled (stripcr off).
  Carriage-return forcing is disabled (forcecr off).
  Interpretation of Content-Transfer-Encoding is enabled (pass8bits
off).
  MIME decoding is disabled (mimedecode off).
  Idle after poll is disabled (idle off).
  Nonempty Status lines will be kept (dropstatus off)
  Delivered-To lines will be kept (dropdelivered off)
  Messages will be SMTP-forwarded to: localhost (default)
  Recognized listener spam block responses are: 571 550 501 554
  Single-drop mode: 1 local name(s) recognized.
  No UIDs saved from this host.


Final bit of info is that I believe this is the info for the RPM I have
of 5.9.12

[585] christmas /mnt/mac/var/lib/rpm% rpm -qi fetchmail-5.9.12-1
--dbpath /mnt/mac/var/lib/rpm
Name        : fetchmail                    Relocations: (not relocateable)
Version     : 5.9.12                            Vendor: Eric Conspiracy Secret Labs
Release     : 1                             Build Date: Tue Jun  4 15:20:29 2002
Install Date: Sat Jun 15 15:05:26 2002      Build Host: snark.thyrsus.com
Group       : Applications/Mail             Source RPM: fetchmail-5.9.12-1.src.rpm
Size        : 752644                           License: GPL
Signature   : (none)
Packager    : Eric S. Raymond <es...@th...>
URL         : http://www.tuxedo.org/~esr/fetchmail
Summary     : Full-featured POP/IMAP mail retrieval daemon


-denis

-- 
____________________________________________________________
Denis Alan Hainsworth     | http://www.cs.brandeis.edu/~denis/  
de...@al... | "Life is just one big sad christmas."

[fetchmail-users] fetchmail 6.3.1-pre1 snapshot - please test

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

I have released a first 6.3.1 beta quality release candidate,
dubbed fetchmail-6.3.1-pre1. It is available from
http://home.pages.de/~mandree/fetchmail/

I am calling it "beta quality" because some of the changes at the bottom
of the list require testing in multidrop and/or LMTP configurations
that I do not currently have available.

Feedback is sought, particularly from those who reported bugs against
6.3.0 and haven't yet responded if a patch they had been sent fixed
their bug.

I plan to release this as 6.3.1 next week-end.

These are the changes since 6.3.0:

>-------------------------------------------------------------------------------
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release. (MA)
>-------------------------------------------------------------------------------
* Fix broken default port in POP2. Patch by Stanislav Brabec, SUSE [CZ]. (MA)
* Fix manual page, some lines starting with ' were escaped by \&.
  Reported by Simon Barner. (MA)
* Ship with gettext-0.14.3 again, as 6.2.9-rc10 did. Found by Sunil Shetye. (MA)
* Actually set default SSL certificate path if --sslcertpath is unset.
  Reported by Heino Tiedemann and Rob MacGregor. (MA)
* Remove bogus Netscape IMAP4rev1 Service >= 3.6 warning about BODY[TEXT]
  that we are not using. Patch by Sunil Shetye. (MA)
* Plug potential memory and socket leak when polling multiple folders or when
  the upstream sends bogus message sizes.  Patch by Sunil Shetye. (MA)
* Fix segfault (null pointer dereference) in multidrop mode with headerless
  email.  Reported by Daniel Drake, patch by Sunil Shetye. (MA)
* Update Catalan translation, by Ernest Adrogué Calveras. (MA)
* Fix segfault (null pointer dereference) on some operating systems with
  fetchmail's obsolete DNS MX/host alias lookups in multidrop mode.
  Patch by Dr.-Ing. Andreas Haakh. (MA)
* Close SMTP sockets early, to reduce resource usage, trigger earlier delivery
  with some MTAs and avoid SIGPIPE (SIG 13) when the SMTP listener gets bored
  and drops the connection after timeout.  Patch by Sunil Shetye. (MA)
* Don't treat hitting a fetch limit as error.  Patch by Sunil Shetye. (MA)
* Fix negative "messages left on server" on idle/repoll with fetchlimit.
  Patch by Sunil Shetye. (MA)
* Properly track logout stage.  Patch by Sunil Shetye. (MA)
* Preserve error conditions across postconnect script.  Sunil Shetye. (MA)
* Do not trash destination domain if multiple messages are forwarded into the
  same SMTP/LMTP connection. Reported by Joachim Feise, Berlios Bug #5849. (MA)
  (This patch had not been committed to SVN at the time of the 6.3.1-pre1
  release on 2005-12-13.)
>-------------------------------------------------------------------------------

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDnofhvmGDOQUufZURAv6qAKCPRq70AK3RkGyZRkw69r2HHKnT/gCeLtuu
YVANbwz0kkwHLmM+prwMbsY=
=6zvB
-----END PGP SIGNATURE-----

Fw: [fetchmail-users] segmentation fault using 6.3.0

[Adamsonh <ad...@po...>]

Hi Sunil Shetye,

Thanks for your concern.  Simon has solved my problem.

Adamson

----- Original Message ----- 
From: "Simon Barner" <ba...@gm...>
To: <ad...@po...>
Sent: Sunday, December 11, 2005 10:27 PM
Subject: Re: [fetchmail-users] segmentation fault using 6.3.0


Hi,

I am the maintainer of the FreeBSD port. I've just received a patch that
seems to resolve this issue. I've forwarded it to the authors for review
but you might want to try it.

Just put the attached file into your mail/fetchmail/files directory and
rebuild.

P.S.: I am not subscribed to fetchmail-users, I just had a look at the
      archives because I wanted to see if this was a known issue.

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

[fetchmail-users] Re: segmentation fault using 6.3.0

[Sunil S. <sh...@bo...>]

Quoting from Adamsonh's mail on Sun, Dec 11, 2005:
> Hi, I portupgraded my fetchmail to 6.3.0 days ago and found it produced a segmentatioin fault when fetching mails from my ISP.  I have to switch back to 6.2.5 because the old version works fine with my pop3 account.
> 
> Please advice.  Thanks.
> 
> ------------------------
> fetchmail: 6.3.0 querying corppop.netvigator.com (protocol POP3) at Sun Dec 11 18:41:48 2005: poll started

...

> fetchmail: POP3> STAT
> fetchmail: POP3< +OK 1 132323
> 1 message for xxx at corppop.netvigator.com (132323 octets).
> fetchmail: POP3> LIST 1
> fetchmail: POP3< +OK 1 132323
> fetchmail: POP3> RETR 1
> fetchmail: POP3< +OK 132323 octets
> reading message xx...@po...:1 of 1 (132323 octets)
> Segmentation fault (core dumped)

Please send the output (after removing password information) of:

$ fetchmail -V [your fetchmail options here]

Are you using fetchmail in multidrop mode? If so, can you run
fetchmail in single drop mode (with keep option, so that mails can be
distributed later) and report if the segmentation fault still occurs?

To get a better gdb output, rerun configure this way:

$ export CFLAGS="-g -ggdb"
$ ./configure [your configure options here]
$ make
# and as root
$ make install         # not install-strip

-- 
Sunil Shetye.

Re: [fetchmail-users] Fetchmail 6.3.0 released

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

On Sun, 11 Dec 2005, Simon Barner wrote:

> > The version differences should not matter, as c_rehash only hashes the
> > certificates, i. e. runs openssl against the certificate and creates a
> > symlink from XXXXXXXX.N to the actual certificate file, so that access
> > is fast.
> 
> s/access is fast/the certificates are found/
> 
> From my experience without the c_rehash run openssl will fail to find
> the certificates:

Right, the reason is that hash access is O(1) and scanning the whole
directory would be O(n), so the former is the only implemented access
scheme.

> As previously mentioned, fetchmail-6.3.0_2 and the entry to
> ports/UPDATING should make everybody happy.

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail 6.3.0 released

[Simon B. <ba...@Fr...>]

Matthias Andree wrote:
> Rob MacGregor <rob...@gm...> writes:
> 
> > So, the only way to get it to work is to point /etc/ssl/certs at
> > /usr/local/openssl/certs and use the c_rehash that comes with the port
> > (but given the version differences, I doubt that's a good idea, even
> > if it's what I've done).
> 
> The version differences should not matter, as c_rehash only hashes the
> certificates, i. e. runs openssl against the certificate and creates a
> symlink from XXXXXXXX.N to the actual certificate file, so that access
> is fast.

s/access is fast/the certificates are found/

From my experience without the c_rehash run openssl will fail to find
the certificates:

% ls .certs 
ca.pem       serverca.pem
% fetchmail
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
fetchmail: No mail for user at xxxxxxxxxx
^Cfetchmail: terminated with signal 2
% perl /usr/src/crypto/openssl/tools/c_rehash .certs 
Doing .certs
serverca.pem => 55974652.0
ca.pem => 1356e92d.0
% fetchmail                                         
fetchmail: No mail for user at xxxxxxxxxx
^Cfetchmail: terminated with signal 2
% ls .certs 
1356e92d.0   55974652.0   ca.pem       serverca.pem

Excerpt from .fetchmailrc:

options fetchall ssl sslcertpath /home/simon/.certs sslfingerprint '...'

'
> 
> > I'm happy to raise a PR about this as I'd like to see this easier for
> > others to get working - FreeBSD really shouldn't be this hard, that's
> > what Linux is for :-)
>

As previously mentioned, fetchmail-6.3.0_2 and the entry to
ports/UPDATING should make everybody happy.

-- 
Best regards / Viele Grüße,                             ba...@Fr...
 Simon Barner                                                ba...@gm...

Re: [fetchmail-users] Fetchmail 6.3.0 released

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

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

> So, the only way to get it to work is to point /etc/ssl/certs at
> /usr/local/openssl/certs and use the c_rehash that comes with the port
> (but given the version differences, I doubt that's a good idea, even
> if it's what I've done).

The version differences should not matter, as c_rehash only hashes the
certificates, i. e. runs openssl against the certificate and creates a
symlink from XXXXXXXX.N to the actual certificate file, so that access
is fast.

> I'm happy to raise a PR about this as I'd like to see this easier for
> others to get working - FreeBSD really shouldn't be this hard, that's
> what Linux is for :-)

:-)

-- 
Matthias Andree

[fetchmail-users] segmentation fault using 6.3.0

[Adamsonh <ad...@po...>]

Hi, I portupgraded my fetchmail to 6.3.0 days ago and found it produced a segmentatioin fault when fetching mails from my ISP.  I have to switch back to 6.2.5 because the old version works fine with my pop3 account.

Please advice.  Thanks.

------------------------
fetchmail: 6.3.0 querying corppop.netvigator.com (protocol POP3) at Sun Dec 11 18:41:48 2005: poll started
fetchmail: POP3< +OK InterMail POP3 server ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< RESP_CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< EXPIRE NEVER
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Openwave Email vM.6.01.05.02 201-2131-123-102-20
fetchmail: POP3< 050715
fetchmail: POP3< .
fetchmail: POP3> USER xxx
fetchmail: POP3< +OK please send PASS command
fetchmail: POP3> PASS *
fetchmail: POP3< +OK xxx is welcome here
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 132323
1 message for xxx at corppop.netvigator.com (132323 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 132323
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 132323 octets
reading message xx...@po...:1 of 1 (132323 octets)
Segmentation fault (core dumped)

--------------------------
gdb result.
--------------------------
Core was generated by `fetchmail'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libintl.so.6
Reading symbols from /usr/lib/libopie.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libopie.so.2
Reading symbols from /lib/libcrypt.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /lib/libmd.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libmd.so.2
Reading symbols from /lib/libkvm.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libkvm.so.2
Reading symbols from /usr/local/lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libcom_err.so.2
Reading symbols from /usr/lib/libssl.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /lib/libcrypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.3
Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x282b6e12 in strcasecmp () from /lib/libc.so.5
(gdb) backtrace full
#0  0x282b6e12 in strcasecmp () from /lib/libc.so.5
No symbol table info available.
#1  0x0806551c in sigprocmask ()
No symbol table info available.
#2  0x080590fd in sigprocmask ()
No symbol table info available.
#3  0x0805a9bf in sigprocmask ()
No symbol table info available.
#4  0x08057584 in sigprocmask ()
No symbol table info available.
#5  0x08058963 in sigprocmask ()
No symbol table info available.
#6  0x08058e8c in sigprocmask ()
No symbol table info available.
#7  0x0804e658 in sigprocmask ()
No symbol table info available.
#8  0x0805342b in sigprocmask ()
No symbol table info available.
#9  0x08051709 in sigprocmask ()
No symbol table info available.
#10 0x0804ad82 in sigprocmask ()
No symbol table info available.

[fetchmail-users] segmentation fault using 6.3.0

[test <ad...@po...>]

Hi, I portupgraded my fetchmail to 6.3.0 days ago and found it produced a segmentatioin fault when fetching mails from my ISP.  I have to switch back to 6.2.5 because the old version works smoothly with my pop3 account.

Please help.  Thanks.

------------------------
fetchmail: 6.3.0 querying corppop.netvigator.com (protocol POP3) at Sun Dec 11 18:41:48 2005: poll started
fetchmail: POP3< +OK InterMail POP3 server ready.
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< USER
fetchmail: POP3< RESP_CODES
fetchmail: POP3< PIPELINING
fetchmail: POP3< EXPIRE NEVER
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION Openwave Email vM.6.01.05.02 201-2131-123-102-20
fetchmail: POP3< 050715
fetchmail: POP3< .
fetchmail: POP3> USER xxx
fetchmail: POP3< +OK please send PASS command
fetchmail: POP3> PASS *
fetchmail: POP3< +OK xxx is welcome here
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 132323
1 message for xxx at corppop.netvigator.com (132323 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 132323
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 132323 octets
reading message xx...@po...:1 of 1 (132323 octets)
Segmentation fault (core dumped)

--------------------------
gdb result.
--------------------------
Core was generated by `fetchmail'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libintl.so.6
Reading symbols from /usr/lib/libopie.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libopie.so.2
Reading symbols from /lib/libcrypt.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /lib/libmd.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libmd.so.2
Reading symbols from /lib/libkvm.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libkvm.so.2
Reading symbols from /usr/local/lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libcom_err.so.2
Reading symbols from /usr/lib/libssl.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /lib/libcrypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.3
Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x282b6e12 in strcasecmp () from /lib/libc.so.5
(gdb) backtrace full
#0  0x282b6e12 in strcasecmp () from /lib/libc.so.5
No symbol table info available.
#1  0x0806551c in sigprocmask ()
No symbol table info available.
#2  0x080590fd in sigprocmask ()
No symbol table info available.
#3  0x0805a9bf in sigprocmask ()
No symbol table info available.
#4  0x08057584 in sigprocmask ()
No symbol table info available.
#5  0x08058963 in sigprocmask ()
No symbol table info available.
#6  0x08058e8c in sigprocmask ()
No symbol table info available.
#7  0x0804e658 in sigprocmask ()
No symbol table info available.
#8  0x0805342b in sigprocmask ()
No symbol table info available.
#9  0x08051709 in sigprocmask ()
No symbol table info available.
#10 0x0804ad82 in sigprocmask ()
No symbol table info available.