fetchmail-users — User questions and discussion

Re: [Fetchmail-users] ssl config

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

Am 09.05.2015 um 01:09 schrieb Joe Acquisto-j4:
>>>> On 5/8/2015 at 10:41 AM, Matthias Andree <mat...@gm...> wrote:
>> Am 07.05.2015 um 22:20 schrieb Joe Acquisto-j4:
>>>>>> Matthias Andree <mat...@gm...> 05/07/15 2:51 PM >>>
>>> Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
>>>> As my provider is soon going exclusively to ssl/tls, I need to finally get 
>> fetchmail configured correctly for certs.
>>>>
>>>> I am seeing this: fetchmail: Server certificate verification error: 
>> certificate signature failure
>>>>
>>>> I checked and the cert is expired.  Could that be it?
>>>>
>>>> Also, my fetchmail is probably well out of date, and I expect some public 
>> shaming, so to facilitate that:
>>>>
>>>> This is fetchmail release 
>> 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
>>>>
>>>> I am prepared.  I think.
>>>
>>> I think I fixed certificate-check-related bugs in the 24 releases since
>>> then... but with expired certificates the provider is putting shame on
>>> itself, too.
>>>
>>> Twenty four since the version I'm using?  (look of shame).   
>>>
>>> Anyway, the error message is related to the *providers* cert, not me?
>>
>> First of all, use mail software that can attribute and indent quoted
>> material properly.
>>
>> Then, yes, it's time to upgrade - I do not recall what 6.3.2 did wrong,
>> and I am inclined to let people (i. e. you) read the NEWS file of a
>> newer version by themselves to figure out what got repaired...
>> at the very least, you will get clearer SSL/TLS error reporting out of
>> newer versions, so you can then assess the situation better.
>>
> 
> So running 6.3.26 now.  Downloaded it a while back, actually,
> 
> 
> Below is a snippet:
> 
> fetchmail: POP3< .
> fetchmail: POP3> STLS
> fetchmail: POP3< +OK Begin TLS negotiation now.
> fetchmail: Issuer Organization: GeoTrust, Inc.
> fetchmail: Issuer CommonName: RapidSSL CA
> fetchmail: Server CommonName: *.myisp.com
> fetchmail: Subject Alternative Name: *.myisp.com
> fetchmail: Subject Alternative Name: myisp.com
> fetchmail: mail.bravehost.com key fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
> fetchmail: Server certificate verification error: certificate signature failure
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK
> 
> 
> Mail does get fetched and delivers locally as before.  The other end is, supposedly, configured to do ssl/tls only.  May I infer (correctly!)
> it is using TLS despite the message?

It is continuing to use TLS, but the certificate verification is failed,
and thus something is messing up the security layer.

Add --sslcertck to have fetchmail abort in this situation.
(You can put a "default" entry into the rcfile, see the manual for details.)

Now, what OpenSSL version are you using? Is it some 1.0.0 or 1.0.1
version?  It should be, 0.X.Y versions are way out of date.

NOTE: You may need to recompile fetchmail after upgrading OpenSSL.

Re: [Fetchmail-users] ssl config

[J. E. <j.e...@ec...>]

Am 09.05.2015 um 03:01 schrieb Joe Acquisto-j4:
>>>> On 5/8/2015 at 8:06 PM, grarpamp <gra...@gm...> wrote:
>> MD5 Fingerprint=56:13:D6:65:39:C9:E3:06:50:4F:17:74:5C:4F:CF:9F
>>
>> The cert it not expired. Check the root bundle on your host
>> and that the path rolls up... ie make sure it includes the Rssl crt
>> http://rapidssl-aia.geotrust.com/rapidssl.crt
>>
> Hey! No fair peeking in headers!  And after I went to all that trouble to "obfuscate" too.
>
> tsk.  Sigh.
>
> Seriously, it's sorted, for now, anyway.
>
> joe a.
>
you should check what grarpamp said ;)

Re: [Fetchmail-users] ssl config

[Joe Acquisto-j. <jo...@j4...>]

>>> On 5/8/2015 at 8:06 PM, grarpamp <gra...@gm...> wrote:
> MD5 Fingerprint=56:13:D6:65:39:C9:E3:06:50:4F:17:74:5C:4F:CF:9F
> 
> The cert it not expired. Check the root bundle on your host
> and that the path rolls up... ie make sure it includes the Rssl crt
> http://rapidssl-aia.geotrust.com/rapidssl.crt .
> Consider use of fingerprint it you want to pin down the cert.
> 
> Read up on examples of examining certs and config of fetchmail with
> openssl s_client
> openssl x509
> openssl verify
> fetchmail(1) --ssl related options and section
>  Secure Socket Layers (SSL) and Transport Layer Security (TLS)
> 
> And you'll be good to go with maybe a minor update to
> your config, which we cannot see to tell you.
> f
> Fetchmail won't downgrate to plaintext midstream if ssl was
> specified but errors should be examined and fixed.
> 

Hey! No fair peeking in headers!  And after I went to all that trouble to "obfuscate" too.

tsk.  Sigh.

Seriously, it's sorted, for now, anyway.

joe a.

Re: [Fetchmail-users] ssl config

[grarpamp <gra...@gm...>]

MD5 Fingerprint=56:13:D6:65:39:C9:E3:06:50:4F:17:74:5C:4F:CF:9F

The cert it not expired. Check the root bundle on your host
and that the path rolls up... ie make sure it includes the Rssl crt
http://rapidssl-aia.geotrust.com/rapidssl.crt .
Consider use of fingerprint it you want to pin down the cert.

Read up on examples of examining certs and config of fetchmail with
openssl s_client
openssl x509
openssl verify
fetchmail(1) --ssl related options and section
 Secure Socket Layers (SSL) and Transport Layer Security (TLS)

And you'll be good to go with maybe a minor update to
your config, which we cannot see to tell you.
f
Fetchmail won't downgrate to plaintext midstream if ssl was
specified but errors should be examined and fixed.

Re: [Fetchmail-users] ssl config

[Joe Acquisto-j. <jo...@j4...>]

>>> On 5/8/2015 at 7:09 PM, "Joe Acquisto-j4" <jo...@j4...> wrote:
>>>> On 5/8/2015 at 10:41 AM, Matthias Andree <mat...@gm...> wrote:
>> Am 07.05.2015 um 22:20 schrieb Joe Acquisto-j4:
>>>>>> Matthias Andree <mat...@gm...> 05/07/15 2:51 PM >>>
>>> Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
>>>> As my provider is soon going exclusively to ssl/tls, I need to finally get 
>> fetchmail configured correctly for certs.
>>>>
>>>> I am seeing this: fetchmail: Server certificate verification error: 
>> certificate signature failure
>>>>
>>>> I checked and the cert is expired.  Could that be it?
>>>>
>>>> Also, my fetchmail is probably well out of date, and I expect some public 
>> shaming, so to facilitate that:
>>>>
>>>> This is fetchmail release 
>> 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
>>>>
>>>> I am prepared.  I think.
>>> 
>>> I think I fixed certificate-check-related bugs in the 24 releases since
>>> then... but with expired certificates the provider is putting shame on
>>> itself, too.
>>> 
>>> Twenty four since the version I'm using?  (look of shame).   
>>> 
>>> Anyway, the error message is related to the *providers* cert, not me?
>> 
>> First of all, use mail software that can attribute and indent quoted
>> material properly.
>> 
>> Then, yes, it's time to upgrade - I do not recall what 6.3.2 did wrong,
>> and I am inclined to let people (i. e. you) read the NEWS file of a
>> newer version by themselves to figure out what got repaired...
>> at the very least, you will get clearer SSL/TLS error reporting out of
>> newer versions, so you can then assess the situation better.
>> 
> 
> So running 6.3.26 now.  Downloaded it a while back, actually,
> 
> 
> Below is a snippet:
> 
> fetchmail: POP3< .
> fetchmail: POP3> STLS
> fetchmail: POP3< +OK Begin TLS negotiation now.
> fetchmail: Issuer Organization: GeoTrust, Inc.
> fetchmail: Issuer CommonName: RapidSSL CA
> fetchmail: Server CommonName: *.myisp.com
> fetchmail: Subject Alternative Name: *.myisp.com
> fetchmail: Subject Alternative Name: myisp.com
> fetchmail: mail.bravehost.com key fingerprint: 
> xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
> fetchmail: Server certificate verification error: certificate signature 
> failure
> fetchmail: POP3> CAPA
> fetchmail: POP3< +OK
> 
> 
> Mail does get fetched and delivers locally as before.  The other end is, 
> supposedly, configured to do ssl/tls only.  May I infer (correctly!)
> it is using TLS despite the message?
> 
> joe a
> 
> 

Message seems to have been sorted by adding this to each fetch line in .fetchmailrc :

sslfingerprint "the.cert.sig" sslcertpath /my/path/to/certs

joe a.

Re: [Fetchmail-users] ssl config

[Joe Acquisto-j. <jo...@j4...>]

>>> On 5/8/2015 at 10:41 AM, Matthias Andree <mat...@gm...> wrote:
> Am 07.05.2015 um 22:20 schrieb Joe Acquisto-j4:
>>>>> Matthias Andree <mat...@gm...> 05/07/15 2:51 PM >>>
>> Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
>>> As my provider is soon going exclusively to ssl/tls, I need to finally get 
> fetchmail configured correctly for certs.
>>>
>>> I am seeing this: fetchmail: Server certificate verification error: 
> certificate signature failure
>>>
>>> I checked and the cert is expired.  Could that be it?
>>>
>>> Also, my fetchmail is probably well out of date, and I expect some public 
> shaming, so to facilitate that:
>>>
>>> This is fetchmail release 
> 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
>>>
>>> I am prepared.  I think.
>> 
>> I think I fixed certificate-check-related bugs in the 24 releases since
>> then... but with expired certificates the provider is putting shame on
>> itself, too.
>> 
>> Twenty four since the version I'm using?  (look of shame).   
>> 
>> Anyway, the error message is related to the *providers* cert, not me?
> 
> First of all, use mail software that can attribute and indent quoted
> material properly.
> 
> Then, yes, it's time to upgrade - I do not recall what 6.3.2 did wrong,
> and I am inclined to let people (i. e. you) read the NEWS file of a
> newer version by themselves to figure out what got repaired...
> at the very least, you will get clearer SSL/TLS error reporting out of
> newer versions, so you can then assess the situation better.
> 

So running 6.3.26 now.  Downloaded it a while back, actually,


Below is a snippet:

fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation now.
fetchmail: Issuer Organization: GeoTrust, Inc.
fetchmail: Issuer CommonName: RapidSSL CA
fetchmail: Server CommonName: *.myisp.com
fetchmail: Subject Alternative Name: *.myisp.com
fetchmail: Subject Alternative Name: myisp.com
fetchmail: mail.bravehost.com key fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
fetchmail: Server certificate verification error: certificate signature failure
fetchmail: POP3> CAPA
fetchmail: POP3< +OK


Mail does get fetched and delivers locally as before.  The other end is, supposedly, configured to do ssl/tls only.  May I infer (correctly!)
it is using TLS despite the message?

joe a

Re: [Fetchmail-users] ssl config

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

Am 07.05.2015 um 22:20 schrieb Joe Acquisto-j4:
>>>> Matthias Andree <mat...@gm...> 05/07/15 2:51 PM >>>
> Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
>> As my provider is soon going exclusively to ssl/tls, I need to finally get fetchmail configured correctly for certs.
>>
>> I am seeing this: fetchmail: Server certificate verification error: certificate signature failure
>>
>> I checked and the cert is expired.  Could that be it?
>>
>> Also, my fetchmail is probably well out of date, and I expect some public shaming, so to facilitate that:
>>
>> This is fetchmail release 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
>>
>> I am prepared.  I think.
> 
> I think I fixed certificate-check-related bugs in the 24 releases since
> then... but with expired certificates the provider is putting shame on
> itself, too.
> 
> Twenty four since the version I'm using?  (look of shame).   
> 
> Anyway, the error message is related to the *providers* cert, not me?

First of all, use mail software that can attribute and indent quoted
material properly.

Then, yes, it's time to upgrade - I do not recall what 6.3.2 did wrong,
and I am inclined to let people (i. e. you) read the NEWS file of a
newer version by themselves to figure out what got repaired...
at the very least, you will get clearer SSL/TLS error reporting out of
newer versions, so you can then assess the situation better.

Re: [Fetchmail-users] ssl config

[Joe Acquisto-j. <jo...@j4...>]

>>> Matthias Andree <mat...@gm...> 05/07/15 2:51 PM >>>
Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
> As my provider is soon going exclusively to ssl/tls, I need to finally get fetchmail configured correctly for certs.
> 
> I am seeing this: fetchmail: Server certificate verification error: certificate signature failure
> 
> I checked and the cert is expired.  Could that be it?
> 
> Also, my fetchmail is probably well out of date, and I expect some public shaming, so to facilitate that:
> 
> This is fetchmail release 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
> 
> I am prepared.  I think.

I think I fixed certificate-check-related bugs in the 24 releases since
then... but with expired certificates the provider is putting shame on
itself, too.

Twenty four since the version I'm using?  (look of shame).   

Anyway, the error message is related to the *providers* cert, not me?

Re: [Fetchmail-users] ssl config

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

Am 07.05.2015 um 01:09 schrieb Joe Acquisto-j4:
> As my provider is soon going exclusively to ssl/tls, I need to finally get fetchmail configured correctly for certs.
> 
> I am seeing this: fetchmail: Server certificate verification error: certificate signature failure
> 
> I checked and the cert is expired.  Could that be it?
> 
> Also, my fetchmail is probably well out of date, and I expect some public shaming, so to facilitate that:
> 
> This is fetchmail release 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS
> 
> I am prepared.  I think.

I think I fixed certificate-check-related bugs in the 24 releases since
then... but with expired certificates the provider is putting shame on
itself, too.

Re: [Fetchmail-users] ssl config

[grarpamp <gra...@gm...>]

On Wed, May 6, 2015 at 7:09 PM, Joe Acquisto-j4 <jo...@j4...> wrote:
> I checked and the cert is expired.  Could that be it?

An expired cert will cause errors.
Update the cert or pin down the fingerprint.

> This is fetchmail release 6.3.2

Old versions are not supported.
Upgrade to the latest version, currently 6.3.26 .
http://www.fetchmail.info/

[Fetchmail-users] ssl config

[Joe Acquisto-j. <jo...@j4...>]

As my provider is soon going exclusively to ssl/tls, I need to finally get fetchmail configured correctly for certs.

I am seeing this: fetchmail: Server certificate verification error: certificate signature failure

I checked and the cert is expired.  Could that be it?

Also, my fetchmail is probably well out of date, and I expect some public shaming, so to facilitate that:

This is fetchmail release 6.3.2+POP2+IMAP-GSS+RPA+NTLM+SDPS+SSL+OPIE+SOCKS+NLS

I am prepared.  I think.

joe a.

Re: [Fetchmail-users] Notifying users about mail retrieval problems

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

Am 16.04.2015 um 20:13 schrieb Mick Crane:
> I'm pretty sure that you can pass a message to procmail for this .

You cannot - fetchmail does not trigger anything on a failed connection.
The only thing you could do is to parse logs. Log synchronization is the
next challenge then.

Probably easier to write some C code, and if anyone feels inclined to,
only do so against the Git "master" branch so it can become part of
7.0.0 and has some rate limiting, too.
No new features for the legacy* branches.

Re: [Fetchmail-users] Notifying users about mail retrieval problems

[Mick C. <mic...@gm...>]

I'm pretty sure that you can pass a message to procmail for this .

--
Key ID: 0x4BFEBB31

> On 16 Apr 2015, at 17:46, Christian Schwarz <me...@cs...> wrote:
> 
> Hi folks,
> 
> I have multiple user entries in one fetchmail configuration file. The entries look like the following:
> 
> ```
> poll “source.example.com"
>    proto IMAP
>    port 143
>    user “de...@so... <mailto:de...@so...>"
>    password "demo1"
>    smtphost localhost smtpname us...@my... <mailto:de...@my...>
>    keep
>    idle
> ```
> 
> I want my users to be individually notified via e-mail if fetchmail cannot connect to the host that is polled.
> Example: If fetchmail cannot connect / log in to source.example.com <http://source.example.com/> with the given credentials, I want a notification going straight to us...@my... <mailto:us...@my...>. (I guarantee this mail address exists).
> 
> From what I can tell, the `set bouncemail` and `set postmaster <postmaster mail address>` option seem to be good starting points, but neither configuration option seems to have any effect.
> 
> The OS is a Debian Jessie.
> 
> If you have any suggestion how to solve the problem, I would be happy to hear from you.
> 
> Thanks,
> 
> Christian
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li...
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

Re: [Fetchmail-users] Notifying users about mail retrieval problems

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

Am 16.04.2015 um 18:46 schrieb Christian Schwarz:
> Hi folks,
> 
> I have multiple user entries in one fetchmail configuration file. The entries look like the following:
> 
> ```
> poll “source.example.com"
> 	proto IMAP
> 	port 143
> 	user “de...@so... <mailto:de...@so...>"
> 	password "demo1"
> 	smtphost localhost smtpname us...@my... <mailto:de...@my...>
> 	keep
> 	idle
> ```
> 
> I want my users to be individually notified via e-mail if fetchmail cannot connect to the host that is polled.
> Example: If fetchmail cannot connect / log in to source.example.com <http://source.example.com/> with the given credentials, I want a notification going straight to us...@my... <mailto:us...@my...>. (I guarantee this mail address exists).
> 
> From what I can tell, the `set bouncemail` and `set postmaster <postmaster mail address>` option seem to be good starting points, but neither configuration option seems to have any effect.
> 
> The OS is a Debian Jessie.
> 
> If you have any suggestion how to solve the problem, I would be happy to hear from you.

Such code does not exist.  Fetchmail sends warnings about connection
timeouts, oversized messages, and authentication failures, and that's it.

[Fetchmail-users] Notifying users about mail retrieval problems

[Christian S. <me...@cs...>]

Hi folks,

I have multiple user entries in one fetchmail configuration file. The entries look like the following:

```
poll “source.example.com"
	proto IMAP
	port 143
	user “de...@so... <mailto:de...@so...>"
	password "demo1"
	smtphost localhost smtpname us...@my... <mailto:de...@my...>
	keep
	idle
```

I want my users to be individually notified via e-mail if fetchmail cannot connect to the host that is polled.
Example: If fetchmail cannot connect / log in to source.example.com <http://source.example.com/> with the given credentials, I want a notification going straight to us...@my... <mailto:us...@my...>. (I guarantee this mail address exists).

From what I can tell, the `set bouncemail` and `set postmaster <postmaster mail address>` option seem to be good starting points, but neither configuration option seems to have any effect.

The OS is a Debian Jessie.

If you have any suggestion how to solve the problem, I would be happy to hear from you.

Thanks,

Christian

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

Am 10.04.2015 um 22:04 schrieb Jerry:
> On Fri, 10 Apr 2015 19:03:54 +0200, Matthias Andree stated:
> 
>> Now, retracing your previous setup and workaround experiments:
>> When I suggested to use --sslproto tls1 for a workaround,
>> you got longish delays before the failure.
>>
>> I should mention that you need to be sure to specify --ssl in that case
>> to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you
>> give --sslproto tls1.
> 
> Success:
> 
> env LC_ALL=C fetchmail --nodetach -vvv --nosyslog
> Old UID list from pop3.live.com: <empty>
> Scratch list of UIDs: <empty>
> fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:38 2015: poll started
> Trying to connect to 134.170.170.231/995...connected.
> fetchmail: Certificate chain, from root to peer, starting at depth 2:
...
> fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76
> fetchmail: pop3.live.com fingerprints match.
> fetchmail: POP3< +OK dub0-pop605 POP3 server ready

...

> Anyway, at least it is working again. Thanks for your assistance.

OK, thank you for this feedback.

JFTR, the --ssl is not a general requirement (many servers will also be
happy with STARTTLS), but specific to servers that only offer
SSL/TLS-wrapped POP3 (or IMAP) on port 995 (or 993, for IMAP), but do
not offer STARTTLS or similar on the default ports 110 (for POP3) or 143
(for IMAP).  I suppose you might have removed that in the first
experiment when you added --sslproto, and maybe my instructions weren't
clear on what I was suggesting to do.

Lesson learned: we probably need to be able to specify TLS versions
explicitly in future fetchmail versions so that users can work around
server limitations.  I don't currently think any of this can be
automatic though - version fallback would be too dangerous.

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Jerry <je...@se...>]

On Fri, 10 Apr 2015 19:03:54 +0200, Matthias Andree stated:

> Now, retracing your previous setup and workaround experiments:
> When I suggested to use --sslproto tls1 for a workaround,
> you got longish delays before the failure.
> 
> I should mention that you need to be sure to specify --ssl in that case
> to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you
> give --sslproto tls1.

Success:

env LC_ALL=C fetchmail --nodetach -vvv --nosyslog
Old UID list from pop3.live.com: <empty>
Scratch list of UIDs: <empty>
fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:38 2015: poll started
Trying to connect to 134.170.170.231/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Root CA
fetchmail: Subject CommonName: GlobalSign Root CA
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Root CA
fetchmail: Subject CommonName: GlobalSign Organization Validation CA - G2
fetchmail: Server certificate:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Organization Validation CA - G2
fetchmail: Subject CommonName: *.hotmail.com
fetchmail: Subject Alternative Name: *.hotmail.com
fetchmail: Subject Alternative Name: *.live.com
fetchmail: Subject Alternative Name: *.outlook.com
fetchmail: Subject Alternative Name: hotmail.com
fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76
fetchmail: pop3.live.com fingerprints match.
fetchmail: POP3< +OK dub0-pop605 POP3 server ready
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unrecognized command
fetchmail: unrecognized command
fetchmail: Repoll immediately on ME...@ou...@pop3.glbdns2.microsoft.com
Trying to connect to 134.170.170.231/995...connected.
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Root CA
fetchmail: Subject CommonName: GlobalSign Root CA
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Root CA
fetchmail: Subject CommonName: GlobalSign Organization Validation CA - G2
fetchmail: Server certificate:
fetchmail: Issuer Organization: GlobalSign nv-sa
fetchmail: Issuer CommonName: GlobalSign Organization Validation CA - G2
fetchmail: Subject CommonName: *.hotmail.com
fetchmail: Subject Alternative Name: *.hotmail.com
fetchmail: Subject Alternative Name: *.live.com
fetchmail: Subject Alternative Name: *.outlook.com
fetchmail: Subject Alternative Name: hotmail.com
fetchmail: pop3.live.com key fingerprint: 86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76
fetchmail: pop3.live.com fingerprints match.
fetchmail: POP3< +OK dub0-pop599 POP3 server ready
fetchmail: POP3> USER ME...@ou...
fetchmail: POP3< +OK password required
fetchmail: POP3> PASS *
fetchmail: POP3< +OK mailbox has 0 messages
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for ME...@ou... at pop3.live.com
fetchmail: POP3> QUIT
fetchmail: POP3< +OK mailbox unchanged, POP3 server signing off
fetchmail: 6.3.26 querying pop3.live.com (protocol POP3) at Fri Apr 10 15:55:50 2015: poll completed
New UID list from pop3.live.com: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: normal termination, status 1

I have this in the ".fetchmailrc" file:

poll pop3.live.com with proto POP3 service 995 timeout 30 and options bad-header accept

user 'ME...@ou...' there with password 'PASSWORD' is 'ME' here options flush forcecr dropdelivered smtpname 'ME...@IS...'  sslproto tls1 ssl  sslfingerprint '86:60:F6:38:1C:84:A6:AC:94:92:51:2F:67:9A:7D:76'

Anyway, at least it is working again. Thanks for your assistance.

-- 
Jerry

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

Am 10.04.2015 um 16:18 schrieb Jerry:
> On Thu, 09 Apr 2015 22:00:38 +0200, Matthias Andree stated:
> 
>> Do remove openssl and then rebuild things.  This should use the OpenSSL
>> version from the base system.  OpenSSL-from-Ports only ever caused
>> trouble for me.
> 
> Unfortunately, that is not really an option. The "ports" version is tightly
> integrated to several other applications that I use. Reverting to the "base
> system" version is a step backwards and not one that I feel is advantageous.
> 
> What I am confused about is why MUA's like "Claws-Mail" that utilize
> "openssl" from ports is not encountering the same problem that "fetchmail"
> is. In any case, at some point, the base system will be updated to the latest
> version of "openssl". Therefore it becomes crucial that this problem is
> corrected.

Jerry,

I concur that such a problem needs to be corrected.

However, having seen the network traces, I'd say this needs to be fixed
on the server's end.

Is claws also connecting to pop3.live.com in your situation?  What does
it do in a different way, compared to fetchmail?

The pop3.live.com server in your case just sees the first package of TLS
negotiation and directly hangs up, without any more TLS packets. That
seems like a protocol violation, thus, a malfunction on the server's
end, to me.  My interpretation is that pop3.live.com's service (or some
preceding application-level firewall) does not support TLS v1.2 and gets
scared to death when a client offers TLS v1.2.

If the negotiation fails, one normally expects to see something along
the lines of

> fetchmail: OpenSSL reported: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
(when forcing TLS v1.1 on pop3.live.com, which it rejects)

or:

> fetchmail: OpenSSL reported: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
(when only offering ciphers that aren't acceptable to the server)

but instead you're getting a rude plain disconnect which I also see when
/forcing/ TLS v1.2 (I am using the Git master branch for experimenting
which allows a bit more control over TLS protocols and ciphers than
RELEASE-6-3-26 aka fetchmail-6.3.26 does).


Now, retracing your previous setup and workaround experiments:
When I suggested to use --sslproto tls1 for a workaround,
you got longish delays before the failure.

I should mention that you need to be sure to specify --ssl in that case
to avoid STARTTLS that is implied by fetchmail 6.3.x versions if you
give --sslproto tls1.

HTH
Matthias

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Jerry <je...@se...>]

On Thu, 09 Apr 2015 22:00:38 +0200, Matthias Andree stated:

> Do remove openssl and then rebuild things.  This should use the OpenSSL
> version from the base system.  OpenSSL-from-Ports only ever caused
> trouble for me.

Unfortunately, that is not really an option. The "ports" version is tightly
integrated to several other applications that I use. Reverting to the "base
system" version is a step backwards and not one that I feel is advantageous.

What I am confused about is why MUA's like "Claws-Mail" that utilize
"openssl" from ports is not encountering the same problem that "fetchmail"
is. In any case, at some point, the base system will be updated to the latest
version of "openssl". Therefore it becomes crucial that this problem is
corrected.

Just my 2¢.

-- 
Jerry

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

Am 09.04.2015 um 20:25 schrieb Jerry:

> Sorry, about the confusion. I did not remove openssl. Rather, I rebuilt
> everything, including fetchmail that depended on it. The problem still exists.

Do remove openssl and then rebuild things.  This should use the OpenSSL
version from the base system.  OpenSSL-from-Ports only ever caused
trouble for me.

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Jerry <je...@se...>]

On Thu, 09 Apr 2015 18:26:34 +0200, Matthias Andree stated:

> Am 09.04.2015 um 13:16 schrieb Jerry:
> > On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated:
> > 
> >> As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you
> >> have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail
> >> (and all other SSL-based applications that got built after you'd
> >> installed the OpenSSL 1.0.2+ port or package).  I'm not sure what really
> >> causes the Microsoft server to hang up with the newer OpenSSL.  Might be
> >> worth asking on the OpenSSL lists.
> > 
> > Thanks for your hard work on this problem.
> > 
> > I tried rebuilding "fetchmail" and using the "--sslproto tls1" and
> > "--sslproto ssl3" settings; however, it still failed to work, although it
> > did hang for a while before crapping out.
> 
> That would probably rather point to a local problem because I see the
> hang-up with OpenSSL 1.0.2* happen right away.  No delay.
> 
> Check ldd, and check with a fetchmail rebuilt after you've removed the
> openssl pkg.
> 
> > I am going to see if I can get an answer on the MS forum. Is it all right
> > with you if I post your debug info on that forum?
> 
> Yes, it is - this list has public archives anyhow, but I would rather
> search on the local end.  Any other changes happening at the same time
> as the openssl upgrade?
> 
> Tried pkg upgrade -f to upgrade everything?

Sorry, about the confusion. I did not remove openssl. Rather, I rebuilt
everything, including fetchmail that depended on it. The problem still exists.

-- 
Jerry

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

Am 09.04.2015 um 13:16 schrieb Jerry:
> On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated:
> 
>> As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you
>> have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail
>> (and all other SSL-based applications that got built after you'd
>> installed the OpenSSL 1.0.2+ port or package).  I'm not sure what really
>> causes the Microsoft server to hang up with the newer OpenSSL.  Might be
>> worth asking on the OpenSSL lists.
> 
> Thanks for your hard work on this problem.
> 
> I tried rebuilding "fetchmail" and using the "--sslproto tls1" and
> "--sslproto ssl3" settings; however, it still failed to work, although it did
> hang for a while before crapping out.

That would probably rather point to a local problem because I see the
hang-up with OpenSSL 1.0.2* happen right away.  No delay.

Check ldd, and check with a fetchmail rebuilt after you've removed the
openssl pkg.

> I am going to see if I can get an answer on the MS forum. Is it all right
> with you if I post your debug info on that forum?

Yes, it is - this list has public archives anyhow, but I would rather
search on the local end.  Any other changes happening at the same time
as the openssl upgrade?

Tried pkg upgrade -f to upgrade everything?

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Jerry <je...@se...>]

On Wed, 08 Apr 2015 01:29:21 +0200, Matthias Andree stated:

> As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you
> have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail
> (and all other SSL-based applications that got built after you'd
> installed the OpenSSL 1.0.2+ port or package).  I'm not sure what really
> causes the Microsoft server to hang up with the newer OpenSSL.  Might be
> worth asking on the OpenSSL lists.

Thanks for your hard work on this problem.

I tried rebuilding "fetchmail" and using the "--sslproto tls1" and
"--sslproto ssl3" settings; however, it still failed to work, although it did
hang for a while before crapping out.

I am going to see if I can get an answer on the MS forum. Is it all right
with you if I post your debug info on that forum?

-- 
Jerry

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

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

Git's new legacy_64 branch, as of c3c106ac, now has code to check for
this situation and report it as "Server shut down connection prematurely
during SSL_connect().", and has other SSL changes and fixes.

I need to merge some of the SSL code between legacy_64 and master
branches and will then try to do a 6.4.0 beta2 release with updated SSL
code shortly.

Note that the repository has moved from gitorious.org to
https://gitlab.com/groups/fetchmail and the sourceforge.net and my
homepage mirrors remain in place and active.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlUkcAgACgkQvmGDOQUufZUdYACeNFxS59nuB3V+rbSPwNe/weTf
g+MAn30lPPXKT7fB+jTtuHJ+7EonswyB
=bV63
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] Unable to fetch mail from "outlook"

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

Am 07.04.2015 um 12:22 schrieb Jerry:

> I guess I should have stated in my original post, that the ".fetchmailrc"
> file, etcetera is exactly what I have been using for two years now without a
> single problem until few days ago when I updated "openssl" on my system. You
> don't have to be genius to figure out that the cause of the problem was the
> updated "openssl"; however, what is triggering it is what I am trying to
> decipher.

You updated openssl to version 1.0.2a from ports.  The tricky part is
that typing "openssl" would grab the version from /usr/bin and not
/usr/local/bin with default PATH, so the version from "openssl version"
may not be version of the library that fetchmail is linked against.

> Or this:
> 
> openssl s_client -tls1 -crlf -showcerts -verify 5 -CAfile /usr/local/share/certs/ca-root-nss.crt -connect pop3.live.com:995  
> verify depth is 5
...

Which is again not what fetchmail would be doing, it just uses
SSLv23_*_method() without the -tls1 option.

What I know is that installing openssl as a port, rather than using the
base system's OpenSSL, has always caused strange problems for me, so
let's try something else:

> $ /usr/local/bin/openssl s_client -crlf -showcerts -verify 5 \ 
>   -CAfile  /usr/local/share/certs/ca-root-nss.crt \
>   -connect pop3.live.com:995
> CONNECTED(00000003)
> 34381952888:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Oops!

I can reproduce your problem if I compile fetchmail against OpenSSL
1.0.2a, and in Wireshark I see what's going on. This is what comes out
of fetchmail's calling SSLOpen() with OpenSSL 1.0.2a:

... (first frames are regular TCP connection set-up, i. e.
the normal 3-way >SYN <SYN|ACK >ACK sequence)

> Frame 4: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface 0
> ...
> Secure Sockets Layer
>     SSL Record Layer: Handshake Protocol: Client Hello
>         Content Type: Handshake (22)
>         Version: TLS 1.0 (0x0301)
>         Length: 512
>         Handshake Protocol: Client Hello
>             Handshake Type: Client Hello (1)
>             Length: 508
>             Version: TLS 1.2 (0x0303)
> ...

So OpenSSL 1.0.2a wants to negotiate TLS v1.2, with a list of ciphers,
and no DEFLATE compression support (not shown here, see attached text
file - it

And this is what Microsoft's server responds:

> Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
> ...
> Transmission Control Protocol, Src Port: 995 (995), Dst Port: 25580 (25580), Seq: 1, Ack: 518, Len: 0
>     Source Port: 995 (995)
>     Destination Port: 25580 (25580)
>     [Stream index: 0]
>     [TCP Segment Len: 0]
>     Sequence number: 1    (relative sequence number)
>     Acknowledgment number: 518    (relative ack number)
>     Header Length: 32 bytes
>     .... 0000 0001 0001 = Flags: 0x011 (FIN, ACK)

Oops again.  The sucker of Microsoft's server doesn't like our SSL
client hello message and just hangs up without saying goodbye or telling
us of the problem.

For some unknown reason, OpenSSL makes it exceptionally hard to identify
and repeat this situation.  It does not hit the SSL error queue, it does
not end up in errno, and it takes guessing from circumstances to figure
out that the server just hung up.

As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you
have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail
(and all other SSL-based applications that got built after you'd
installed the OpenSSL 1.0.2+ port or package).  I'm not sure what really
causes the Microsoft server to hang up with the newer OpenSSL.  Might be
worth asking on the OpenSSL lists.


To identify "base vs. ports/packages OpenSSL",
this is what I get with ldd, most importantly, libssl goes to /usr/lib,
not /usr/local/lib (ditto for libcrypto, from /lib - not to be confused
with libcrypt (without trailing o), which does not matter here.)

$ ldd /usr/local/bin/fetchmail
/usr/local/bin/fetchmail:
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800858000)
	libopie.so.7 => /usr/lib/libopie.so.7 (0x800a62000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c6b000)
	libkvm.so.6 => /lib/libkvm.so.6 (0x800e8b000)
	libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801093000)
	libssl.so.7 => /usr/lib/libssl.so.7 (0x801295000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x801500000)
	libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x8018f4000)
...

HTH!