fetchmail-users — User questions and discussion

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Martin K. <mk...@gm...>]

Hi Jerry,

On Sun, 25 Jan 2015, Jerry wrote:

> On Sun, 25 Jan 2015 19:48:25 +0100 (CET), Martin Koeppe stated:
>
>>>>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>>>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
>>>>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
>>
>> why socomplicated? I use this snippet:
>>
>> defaults:
>>  	proto pop3 timeout 300 sslproto 'TLS1' ssl
>>  	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
>>  	sslcertck
>>  	limit 50000000 warnings 86400
>>
>>
>> As pop.google.com has an "official" certificate, there is no need for
>> a fingerprint check. Just let fetchmail know your root ca certs. I
>> only use sslfingerprint for self-signed certs, as an override where
>> root ca cert verification fails. You don't seem to use sslcertck, but
>> better you should.
>>
>> Martin
>
> That doesn't work here:
>
> fetchmail: Server certificate verification error: unable to get local issuer certificate
> fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
> fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
> fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
> fetchmail: Query status=2 (SOCKET)

seems you have some box on the way to Google which does 
man-in-the-middle. I see the certificate for pop.gmail.com signed from 
"Google Internet Authority G2" (sha1 fingerprint: bb dc e1 3e 9d 53 7a 
52 29 91 5c b1 23 c7 aa b0 a8 55 e7 98)  which in turn is signed by 
"GeoTrust Global CA" (sha1 fingerprint: de 28 f4 a4 ff e5 b9 2f a3 c5 
03 d1 a3 49 a7 f9 96 2a 82 12). No "Equifax" at all.


Martin

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

Am 26.01.2015 um 07:18 schrieb grarpamp:
> On Sun, Jan 25, 2015 at 7:58 PM, Matthias Andree <mat...@gm...> wrote:
>> Am 25.01.2015 um 22:23 schrieb Jerry:
>>
>>>> As pop.google.com has an "official" certificate, there is no need for
>>>> a fingerprint check. Just let fetchmail know your root ca certs. I
>>>> only use sslfingerprint for self-signed certs, as an override where
>>>> root ca cert verification fails. You don't seem to use sslcertck, but
>>>> better you should.
>>
>> Martin's proposal is the same I'd have made:
>> 1. add sslcertck
>> 2. remove sslfingerprint + the hash.
>>
>> You need the root certificates installed locally.
> 
> Yes Google has their own intermediate CA. So if you put the
> full path of CA's just short of the server cert in the file that
> should prevent user from being annoyed at having to change
> prints all the time. I don't think fetchmail has an OSCP
> checking option yet. For that and other reasons I've covered
> previously, just know that prints do serve real security purposes
> that you cannot achieve with CA checking.

Fetchmail will probably not grow an OSCP option yet - most browser
vendors that played with it quickly found out it's a non-starter because
it limits availability.  Too many sites running broken OSCP servers, or
forgetting to run or check on them...

Either you dumb OSCP checking down and treat "not reachable" (in the
broadest sense) as "permit", which opens you up to using b0rked
certificates if some attacker DDoS'es the OSCP server out of the
network, or you treat "not reachable" (in the broadest sense) as fatal
failure, which then causes connection refusal.

I experimented with OSCP checking myself a bit, and quickly found out
many sites aren't up to the task.

Certificate pinning, and allowing to list multiple fingerprints, are
options I am willing to allow for experimenting.

Regarding listing intermediate CAs I am trying to find ways to avoid
them being listed as trust roots, and for some sites, stuffing an
intermediate CA into the trust store fails if the actual root is
missing.  There has been too much abuse with self-signed certs being
stuffed in the root; "abuse" meaning that people have been downloading
the certificate over the same channel because some web sites instructed
them to do so without giving proper security considerations.  Or
encouraged people to believe they weren't under MITM attacks while they
were downloading the certificates.

> Didn't know about thise selction. Figured OS just dumped them
> all in. For non browsing use, it's easy enough to cherry pick
> only the CA's you need to support your mail service rather
> than exposing yourself all the CA's.

True, best to just concatenate the desired root certificates to a PEM
(cat root1.pem root2.pem >fetchmail-trusted.pem) and then use
--sslcertfile fetchmail-trusted.pem to point fetchmail to it (note this
must be in the defaults section of the rcfile, or on the command line,
or it must be repeated for each and every poll statement, or skip
statements where you give servers on the command line).

This also only works with recent fetchmail versions.

>> And you also need up to date versions of fetchmail and OpenSSL.
> 
> You may wish to try out fetchmail 7.x, it's TLS and other
> designs are being updated and coming along perhaps to
> another beta/release in a while.

I propose that unexperienced users stay away from alphas.
I am in the process of getting a 6.4 version out with only a few TLS
revisions but not the other rummaging as a stop-gap release.  Once that
is released, I will discontinue 6.3 altogether.  This shifts some
support burden on the distribution, because - as usual - the reply on
the lists will be "use the latest formal release if you want support
from the fetchmail list".

> FreeBSD bits here.
> http://svnweb.freebsd.org/ports/head/security/nss/

This URL above isn't used for/by fetchmail. The two below may be useful,
however.

> http://svnweb.freebsd.org/ports/head/security/ca_root_nss/
> http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/ca_root_nss-3.17.3_1.txz
> 
> Or you can use the Mozilla + parser links I've previously posted.

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

On Sun, Jan 25, 2015 at 7:58 PM, Matthias Andree <mat...@gm...> wrote:
> Am 25.01.2015 um 22:23 schrieb Jerry:
>
>>> As pop.google.com has an "official" certificate, there is no need for
>>> a fingerprint check. Just let fetchmail know your root ca certs. I
>>> only use sslfingerprint for self-signed certs, as an override where
>>> root ca cert verification fails. You don't seem to use sslcertck, but
>>> better you should.
>
> Martin's proposal is the same I'd have made:
> 1. add sslcertck
> 2. remove sslfingerprint + the hash.
>
> You need the root certificates installed locally.

Yes Google has their own intermediate CA. So if you put the
full path of CA's just short of the server cert in the file that
should prevent user from being annoyed at having to change
prints all the time. I don't think fetchmail has an OSCP
checking option yet. For that and other reasons I've covered
previously, just know that prints do serve real security purposes
that you cannot achieve with CA checking.

> isn't a one-stop solution.  ca-certificates, ca_root_nss are packages
> that Ubuntu and FreeBSD offer.  Some distributions require you to select
> which certificates you want to install into the trust store.

Didn't know about thise selction. Figured OS just dumped them
all in. For non browsing use, it's easy enough to cherry pick
only the CA's you need to support your mail service rather
than exposing yourself all the CA's.

> And you also need up to date versions of fetchmail and OpenSSL.

You may wish to try out fetchmail 7.x, it's TLS and other
designs are being updated and coming along perhaps to
another beta/release in a while.

FreeBSD bits here.
http://svnweb.freebsd.org/ports/head/security/nss/
http://svnweb.freebsd.org/ports/head/security/ca_root_nss/
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/ca_root_nss-3.17.3_1.txz

Or you can use the Mozilla + parser links I've previously posted.

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

Am 25.01.2015 um 22:23 schrieb Jerry:

>> As pop.google.com has an "official" certificate, there is no need for 
>> a fingerprint check. Just let fetchmail know your root ca certs. I 
>> only use sslfingerprint for self-signed certs, as an override where 
>> root ca cert verification fails. You don't seem to use sslcertck, but 
>> better you should.
>>
>> Martin
> 
> That doesn't work here:
> 
> fetchmail: Server certificate verification error: unable to get local issuer certificate
> fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
> fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
> fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
> fetchmail: Query status=2 (SOCKET)

Martin's proposal is the same I'd have made:
1. add sslcertck
2. remove sslfingerprint + the hash.

You need the root certificates installed locally.

Many distributions package Mozilla's certificate package for OpenSSL,
but the various distros have various names for the package, so there
isn't a one-stop solution.  ca-certificates, ca_root_nss are packages
that Ubuntu and FreeBSD offer.  Some distributions require you to select
which certificates you want to install into the trust store.

Some info is in <http://www.fetchmail.info/fetchmail-FAQ.html#K5> but I
haven't tried it recently, so I'm not sure if it applies. Let me know if
it does not so that I can revise or remove that.

And you also need up to date versions of fetchmail and OpenSSL. There
used to lurk bugs in older versions of both.

Tell us your distro and version, and chances are that someone knows what
packages you need to install and perhaps configure and responds to the list.

[Fetchmail-users] HEADS-UP digest subscribers (was: Fetchmail-users Digest, Vol 5, Issue 2)

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

Please do not reply to digest bundles without proper unbundling.
This breaks threading, and confuses people because it loses the Subject,
as seen.

Before replying, unbundle the mail digest, or better subscribe to the
plain list (rather the digests) if you do not have software that can
unbundle digests properly.

I reserve the rights to:

1. filter the list and reject anything that looks like a reply to a
digest that was not properly unbundled;

2. ban repeat offenders from posting to the lists

3. move all digest members to undigested (plain) subscriptions and ban
digests altogether if this goes out of hand in the future.

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

On Sun, 25 Jan 2015 19:48:25 +0100 (CET), Martin Koeppe stated:

> 
> Hi Jerry,
> 
> >>>> I have several users here that use Google's "gmail". Google has
> >>>> been changing their SSL certificate on a nearly monthly basis.
> >>>> This causes havoc with our mail system.
> >>>>
> >>>> Fetchmail is configured to fetch mail from 11 different "gmail"
> >>>> accounts. Each account has a different "user name" and "password".
> >>>> The config line in the global fetchmailrc file read like this:
> >>>>
> >>>> user 'us...@gm...' there with password 'SECRET' options forcecr
> >>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> >>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> 
> why socomplicated? I use this snippet:
> 
> defaults:
>  	proto pop3 timeout 300 sslproto 'TLS1' ssl
>  	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
>  	sslcertck
>  	limit 50000000 warnings 86400
> 
> 
> As pop.google.com has an "official" certificate, there is no need for 
> a fingerprint check. Just let fetchmail know your root ca certs. I 
> only use sslfingerprint for self-signed certs, as an override where 
> root ca cert verification fails. You don't seem to use sslcertck, but 
> better you should.
> 
> Martin

That doesn't work here:

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

-- 
Jerry

Re: [Fetchmail-users] Fetchmail-users Digest, Vol 5, Issue 2

[Juergen E. <fli...@te...>]

Hello Gene,

> 1) Is it possible to configure fetchmail to send an error notice to
>    the user immediately if an ssl error has occurred?

you can use the 'postconnect "/path/send-fingerprint-email.sh"'
command to execute a script after a connection to an email server
is taken down.. If you add it to the last checked account it runs
only once for every poll cycle ;-)

> 2) How else could I configure fetchmail to simply not check the fingerprint?

If you do not want Fetchmail to check the fingerprint for an account,
just remove the 'sslfingerprint ...' line for that account.

Regards
Juergen

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Martin K. <mk...@gm...>]

Hi Jerry,

>>>> I have several users here that use Google's "gmail". Google has
>>>> been changing their SSL certificate on a nearly monthly basis.
>>>> This causes havoc with our mail system.
>>>>
>>>> Fetchmail is configured to fetch mail from 11 different "gmail"
>>>> accounts. Each account has a different "user name" and "password".
>>>> The config line in the global fetchmailrc file read like this:
>>>>
>>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
>>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'

why socomplicated? I use this snippet:

defaults:
 	proto pop3 timeout 300 sslproto 'TLS1' ssl
 	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
 	sslcertck
 	limit 50000000 warnings 86400


As pop.google.com has an "official" certificate, there is no need for 
a fingerprint check. Just let fetchmail know your root ca certs. I 
only use sslfingerprint for self-signed certs, as an override where 
root ca cert verification fails. You don't seem to use sslcertck, but 
better you should.

Martin

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Gene H. <ghe...@wd...>]

On Sunday 25 January 2015 12:22:58 Jerry did opine
And Gene did reply:
> On Sun, 25 Jan 2015 11:40:50 -0500, Gene Heskett stated:
> > On Sunday 25 January 2015 08:48:28 Jerry did opine
> > 
> > And Gene did reply:
> > > I do not know if there is an easy way around this problem, so I
> > > thought I would simply ask for assistance.
> > > 
> > > I have several users here that use Google's "gmail". Google has
> > > been changing their SSL certificate on a nearly monthly basis.
> > > This causes havoc with our mail system.
> > > 
> > > Fetchmail is configured to fetch mail from 11 different "gmail"
> > > accounts. Each account has a different "user name" and "password".
> > > The config line in the global fetchmailrc file read like this:
> > > 
> > > user 'us...@gm...' there with password 'SECRET' options forcecr
> > > dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> > > sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> > > 
> > > Every time Google changes certs, I have to get their new
> > > fingerprint and change it on all of the gmail accounts. Fetchmail
> > > does not send a notice to the user that SSL has failed. Therefore,
> > > it is sometimes a day or two before anyone actually knows it has
> > > happened. That is rare though. Most of the time they realize it
> > > after not receiving any mail for 24 hours.
> > > 
> > > My question are:
> > > 
> > > 1) Is it possible to configure fetchmail to send an error notice to
> > > the user immediately if an ssl error has occurred?
> > > 
> > > 2) How else could I configure fetchmail to simply not check the
> > > fingerprint?
> > > 
> > > I did notice that "fetchmailconf" will print out the new
> > > fingerprint when used to access gmail. Is there a way to have
> > > fetchmail send that to the user. I currently use openssl to
> > > download the certs and extract the fingerprint.
> > > 
> > > By the way, I use fetchmail > Postfix > Dovecot. I have never been
> > > able to get fetchmail > Dovecot without using Postfix as the
> > > intermediary.
> > > 
> > > I am open to any suggestions?
> > 
> > But on a reread of the man page for fetchmail, I see no mention of a
> > way to make such a failure verbose enough in the logs that it leaves
> > a failure hint there.  Perhaps it needs to "grow" such a reporting
> > option?
> 
> Fetchmail leaves this error message in the logs:
> 
> fetchmail: pop.gmail.com fingerprints do not match!
> fetchmail: OpenSSL reported: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from
> us...@gm...@pop.gmail.com fetchmail: Query status=2 (SOCKET)

That is very similar to what I saw at the time. Then it went away for a 
couple weeks then came back and I just quit polling it. I'd long since 
moved all my mailing lists subs off it, mainly due to their duplicate 
policy.  Its not open for discussion, I tried. So I just moved everything 
back to my lifetime account on a qmail server at the tv station.  Lots 
more spam but hey, it also Just Works(TM).

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

On Sun, 25 Jan 2015 11:40:50 -0500, Gene Heskett stated:

> On Sunday 25 January 2015 08:48:28 Jerry did opine
> And Gene did reply:
> > I do not know if there is an easy way around this problem, so I thought
> > I would simply ask for assistance.
> > 
> > I have several users here that use Google's "gmail". Google has been
> > changing their SSL certificate on a nearly monthly basis. This causes
> > havoc with our mail system.
> > 
> > Fetchmail is configured to fetch mail from 11 different "gmail"
> > accounts. Each account has a different "user name" and "password". The
> > config line in the global fetchmailrc file read like this:
> > 
> > user 'us...@gm...' there with password 'SECRET' options forcecr
> > dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> > sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> > 
> > Every time Google changes certs, I have to get their new fingerprint
> > and change it on all of the gmail accounts. Fetchmail does not send a
> > notice to the user that SSL has failed. Therefore, it is sometimes a
> > day or two before anyone actually knows it has happened. That is rare
> > though. Most of the time they realize it after not receiving any mail
> > for 24 hours.
> > 
> > My question are:
> > 
> > 1) Is it possible to configure fetchmail to send an error notice to the
> > user immediately if an ssl error has occurred?
> > 
> > 2) How else could I configure fetchmail to simply not check the
> > fingerprint?
> > 
> > I did notice that "fetchmailconf" will print out the new fingerprint
> > when used to access gmail. Is there a way to have fetchmail send that
> > to the user. I currently use openssl to download the certs and extract
> > the fingerprint.
> > 
> > By the way, I use fetchmail > Postfix > Dovecot. I have never been able
> > to get fetchmail > Dovecot without using Postfix as the intermediary.
> > 
> > I am open to any suggestions?

> But on a reread of the man page for fetchmail, I see no mention of a way 
> to make such a failure verbose enough in the logs that it leaves a failure 
> hint there.  Perhaps it needs to "grow" such a reporting option?

Fetchmail leaves this error message in the logs:

fetchmail: pop.gmail.com fingerprints do not match!
fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from us...@gm...@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

-- 
Jerry

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Gene H. <ghe...@wd...>]

On Sunday 25 January 2015 08:48:28 Jerry did opine
And Gene did reply:
> I do not know if there is an easy way around this problem, so I thought
> I would simply ask for assistance.
> 
> I have several users here that use Google's "gmail". Google has been
> changing their SSL certificate on a nearly monthly basis. This causes
> havoc with our mail system.
> 
> Fetchmail is configured to fetch mail from 11 different "gmail"
> accounts. Each account has a different "user name" and "password". The
> config line in the global fetchmailrc file read like this:
> 
> user 'us...@gm...' there with password 'SECRET' options forcecr
> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> 
> Every time Google changes certs, I have to get their new fingerprint
> and change it on all of the gmail accounts. Fetchmail does not send a
> notice to the user that SSL has failed. Therefore, it is sometimes a
> day or two before anyone actually knows it has happened. That is rare
> though. Most of the time they realize it after not receiving any mail
> for 24 hours.
> 
> My question are:
> 
> 1) Is it possible to configure fetchmail to send an error notice to the
> user immediately if an ssl error has occurred?
> 
> 2) How else could I configure fetchmail to simply not check the
> fingerprint?
> 
> I did notice that "fetchmailconf" will print out the new fingerprint
> when used to access gmail. Is there a way to have fetchmail send that
> to the user. I currently use openssl to download the certs and extract
> the fingerprint.
> 
> By the way, I use fetchmail > Postfix > Dovecot. I have never been able
> to get fetchmail > Dovecot without using Postfix as the intermediary.
> 
> I am open to any suggestions?

This is a new bit of news to me as I have fetchmail scanning a very little 
used account at gmail, one my ISP farmed out to gmail when they disco'd 
their own mail server about 2 years ago, and it is not logging any 
failures.  OTOH I do not use it except as a pop3 fetcher, feeding procmail 
which runs it thru SA and clamav. Those accounts do have the  line "ssl" 
in their stanza.

I did have a 2nd, real gmail account, but it died, presumably from their 
dance with ssl, and since I haven't actually used it for a list 
subscribing address for several years, I just turned off the poll stanza 
as I couldn't care less if they save 50Gb of spam in an account I can't 
access.

But on a reread of the man page for fetchmail, I see no mention of a way 
to make such a failure verbose enough in the logs that it leaves a failure 
hint there.  Perhaps it needs to "grow" such a reporting option?

Or, if as you state, fetchmailconf can fetch the missing fingerprints, 
then obviously the code to do so exists, why not transfer it to fetchmail 
with a daemon option to enable it?

That way, the fix could be automated.  It would be nice if the 
"postmaster" got a message that the new fingerprint fetch was done though.
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

[Fetchmail-users] Constantly changing ssl fingerprints

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

I do not know if there is an easy way around this problem, so I thought I
would simply ask for assistance.

I have several users here that use Google's "gmail". Google has been changing
their SSL certificate on a nearly monthly basis. This causes havoc with our
mail system.

Fetchmail is configured to fetch mail from 11 different "gmail" accounts. Each
account has a different "user name" and "password". The config line in the
global fetchmailrc file read like this:

user 'us...@gm...' there with password 'SECRET' options forcecr dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'

Every time Google changes certs, I have to get their new fingerprint and
change it on all of the gmail accounts. Fetchmail does not send a notice to
the user that SSL has failed. Therefore, it is sometimes a day or two before
anyone actually knows it has happened. That is rare though. Most of the time
they realize it after not receiving any mail for 24 hours.

My question are:

1) Is it possible to configure fetchmail to send an error notice to the user
immediately if an ssl error has occurred?

2) How else could I configure fetchmail to simply not check the fingerprint?

I did notice that "fetchmailconf" will print out the new fingerprint when
used to access gmail. Is there a way to have fetchmail send that to the user.
I currently use openssl to download the certs and extract the fingerprint.

By the way, I use fetchmail > Postfix > Dovecot. I have never been able to
get fetchmail > Dovecot without using Postfix as the intermediary.

I am open to any suggestions?

-- 
Jerry

Re: [Fetchmail-users] Problems with empty Body

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

Am 09.01.2015 um 22:42 schrieb Samy Silva:
> Hello guys,
> 
> I think we have found a bug.

Hi Samy,

thanks for the report.  Yes did find a malfunction, but you found it in
your IMAP server or some en-route application-level cache, load balancer
or other proxy ("application firewall", if any).
The bug is *not* in fetchmail's IMAP client.

Check that you have all relevant service packs and hotfixes for your
high-level routers, firewalls, and Exchange server installed,
check that relevant configuration is set properly, and
then if the problems persist, please take this up to the vendor of the
offending software or appliance, and let us know how the status.

> Conducted tests via Telnet, and found that the calling execute the FETCH BODY no data return.
> So far so good, but if fetchmail try processing it occurs problems.

I disagree on the "so far so good". The lack of data is a malfunction
and violates RFC-3501 on various accounts, namely sections 6.4.5 on page
54, 7.4 on page 72, 7.4.2 on page 74:

"6.4.5. FETCH Command


   Arguments:  sequence set
               message data item names or macro

   Responses:  untagged responses: FETCH
(...)"

"7.4. Server Responses - Message Status


   These responses are always untagged.  This is how message data are
   transmitted from the server to the client, often as a result of a
   command with the same name.  Immediately following the "*" token is a
   number that represents a message sequence number."

(...)

"7.4.2. FETCH Response


   Contents:   message data

      The FETCH response returns data about a message to the client.
      The data are pairs of data item names and their values in
      parentheses.  (...)

      BODY[<section>]<<origin octet>>
         A string expressing the body contents of the specified section.
      ..."

and 4.3 on page 16 that defines the string:

"4.3. String


   A string is in one of two forms: either literal or quoted
   string.  The literal form is the general form of string.
 (...)

   The empty string is represented as either "" (a quoted string
   with zero characters between double quotes) or as {0} followed
   by CRLF (a literal with an octet count of 0).
 (...)"


The server must send the item name and the empty string, either as {0}
or as "". It fails to do so, and fetchmail concludes it has lost
synchronization with the server because it sees the tagged response too
early.  That is correct and intended behaviour of fetchmail's.  This is
what you should get:

C FETCH 3802 BODY.PEEK[TEXT]
* 3802 FETCH (BODY[TEXT] {0}
)
C OK Fetch completed.


or alternatively, but uncommon:

C FETCH 3802 BODY.PEEK[TEXT]
* 3802 FETCH (BODY[TEXT] "")
C OK Fetch completed.

> fetchmail: IMAP> A0011 FETCH 1 BODY.PEEK[TEXT]
> fetchmail: IMAP< A0011 OK FETCH completed.
> fetchmail: IMAP> A0012 LOGOUT
> fetchmail: IMAP< * BYE Microsoft Exchange Server 2010  IMAP4 server signing off.
> fetchmail: IMAP< A0012 OK LOGOUT completed.
> 
> fetchmail: client/server synchronization error while fetching from dirsync_Base_G_09@192.168.125.100

The server is malfunctioning, and fetchmail aborts the connection at
that point.

Best regards
Matthias

[Fetchmail-users] Problems with empty Body

[Samy S. <sam...@ms...>]

Hello guys,

I think we have found a bug.

We have systems that perform archiving messages via IMAP with fetchmail.

We found that there are some e-mails that break the archiving routines. Analyzing the problem e-mails, we find that are automatic messages such as: auto response, accepted meetings, etc.

Conducted tests via Telnet, and found that the calling execute the FETCH BODY no data return.
So far so good, but if fetchmail try processing it occurs problems.

Linux: CentOS release 5.11 (Final) -- 2.6.18-308.el5 #1 SMP Tue Feb 21 20:06:06 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
Fetchmail release: 6.3.17+GSS+RPA+NTLM+SDPS+SSL+HESIOD+NLS+KRB5.

Hugs
Samy

====



##### TEST TELNET

 

[root@s11p06a001 ~]# telnet 192.168.125.100
imap

Trying 192.168.125.100...

Connected to 192.168.125.100.

Escape character is '^]'.

* OK CAS01.mydomain

a1 login dirsync_Base_G_09 MailPassword

a1 OK LOGIN completed.

a2 select troubleshoot

* 2 EXISTS

* 0 RECENT

* FLAGS (\Seen \Answered \Flagged \Deleted \Draft
$MDNSent)

* OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted
\Draft $MDNSent)] Permanent flags

* OK [UNSEEN 2] Is the first unseen message

* OK [UIDVALIDITY 119] UIDVALIDITY value

* OK [UIDNEXT 7] The next unique identifier value

a2 OK [READ-WRITE] SELECT completed.

a3 expunge

* 2 EXISTS

a3 OK EXPUNGE completed.

a4 fetch 1 RFC822.SIZE

* 1 FETCH (RFC822.SIZE 4376)

a4 OK FETCH completed.

a5 fetch 1 RFC822.HEADER

* 1 FETCH (RFC822.HEADER {730}

MIME-Version: 1.0

Content-Type: multipart/mixed;

       
boundary="_225ffd60-c6cb-409b-93dd-abef398ee06f_"

Subject:
=?iso-8859-1?Q?Aceito:_SWOT_-_1=AA_Apresenta=E7=E3o_dos_Planos_de_A=E7=E3?=

 =?iso-8859-1?Q?o.?=

To: Edson Shimada <eds...@my...>

From: "Marcelo M. Vieira" <mar...@my...>

Sender:
<Mic...@la... >

Message-ID:
<edb...@jo...nerator>

Date: Tue, 11 Feb 2014 22:45:14 +0000

Content-Transfer-Encoding: binary

X-MS-Journal-Report:

X-MS-Exchange-Organization-AuthSource: CAS01.la.ad

X-MS-Exchange-Organization-AuthAs: Internal

X-MS-Exchange-Organization-AuthMechanism: 05

Keywords:

 

)

a5 OK FETCH completed.

a6 fetch 1 BODY.PEEK[TEXT]

a6 OK FETCH completed.

a7 logout

* BYE Microsoft Exchange Server 2010 IMAP4 server signing
off.

a7 OK LOGOUT completed.

Connection closed by foreign host.

 



##### TEST FETCHMAIL
[root@s11p06a001 ~]# cat fetchmailrc_troubleshoot
poll 192.168.125.100 protocol imap:
        username "dirsync_Base_G_09" password "MailPassword" is "dirsync_troubleshoot" here options fetchall
        mda "/usr/bin/procmail -f %F -d %T";


 

[root@s11p06a001 ~]#
fetchmail -f fetchmailrc_troubleshoot -rtroubleshoot -vvv --sslproto
"" > test_body 2>&1

 

[root@s11p06a001 ~]# cat test_body

fetchmail: WARNING: Running as root is discouraged.

Old UID list from 192.168.125.100: <empty>

Scratch list of UIDs: <empty>

fetchmail: 6.3.17 querying 192.168.125.100 (protocol
IMAP) at Thu 08 Jan 2015 10:28:51 PM BRST: poll started

Trying to connect to 192.168.125.100/143...connected.

fetchmail: IMAP< * OK CAS01.la.ad

fetchmail: IMAP> A0001 CAPABILITY

fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1
AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE
LITERAL+

fetchmail: IMAP< A0001 OK CAPABILITY completed.

fetchmail: Protocol identified as IMAP4 rev 1

fetchmail: Using service name [imap@192.168.125.100]

fetchmail: IMAP> A0002 AUTHENTICATE GSSAPI

fetchmail: IMAP< +

fetchmail: Sending credentials

fetchmail: Error exchanging credentials

fetchmail: IMAP< +
YHYGBisGAQUFAqBsMGqgPDA6BgorBgEEAYI3AgIeBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKoZIhvcSAQICAwYKKwYBBAGCNwICCqMqMCigJhskbm90X2RlZmluZWRfaW5fUkZDNDE3OEBwbGVhc2VfaWdub3Jl

fetchmail: IMAP> A0003 *

fetchmail: IMAP> A0004 AUTHENTICATE NTLM

fetchmail: IMAP< A0002 NO AUTHENTICATE failed.

fetchmail: IMAP> A0005 *

fetchmail: IMAP> A0006
LOGIN "dirsync_Base_G_09" *

fetchmail: IMAP< +

fetchmail: IMAP< A0004 NO AUTHENTICATE failed.

fetchmail: IMAP< A0006 OK LOGIN completed.

fetchmail: selecting or re-polling folder troubleshoot

fetchmail: IMAP> A0007
SELECT "troubleshoot"

fetchmail: IMAP< * 2 EXISTS

fetchmail: IMAP< * 2 RECENT

fetchmail: IMAP< * FLAGS (\Seen \Answered \Flagged
\Deleted \Draft $MDNSent)

fetchmail: IMAP< * OK [PERMANENTFLAGS (\Seen \Answered
\Flagged \Deleted \Draft $MDNSent)] Permanent flags

fetchmail: IMAP< * OK [UNSEEN 2] Is the first unseen
message

fetchmail: IMAP< * OK [UIDVALIDITY 119] UIDVALIDITY
value

fetchmail: IMAP< * OK [UIDNEXT 7] The next unique
identifier value

fetchmail: IMAP< A0007 OK [READ-WRITE] SELECT
completed.

fetchmail: 2 messages waiting after first poll

fetchmail: IMAP> A0008
EXPUNGE

fetchmail: IMAP< * 2 EXISTS

fetchmail: IMAP< A0008 OK EXPUNGE completed.

fetchmail: 2 messages waiting after expunge

2 messages for dirsync_Base_G_09 at 192.168.125.100
(folder troubleshoot).

fetchmail: IMAP> A0009
FETCH 1:2 RFC822.SIZE

fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 4376)

fetchmail: IMAP< * 2 FETCH (RFC822.SIZE 5289)

fetchmail: IMAP< A0009 OK FETCH completed.

fetchmail: IMAP> A0010
FETCH 1 RFC822.HEADER

fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {730}

reading message dirsync_Base_G_09@192.168.125.100:1 of 2
(730 header octets)About to rewrite To: Edson Shimada <eds...@my...>...

...rewritten version is To: Edson Shimada
<eds...@my...>.

About to rewrite From: "Marcelo M. Vieira"
<mar...@my...>...

...rewritten version is From: "Marcelo M.
Vieira" <mar...@my...>.

About to rewrite Sender:
<Mic...@la...>...

...rewritten version is Sender:
<Mic...@la... >.

fetchmail: about to deliver with: /usr/bin/procmail -f
'Mic...@la...' -d
'dirsync_troubleshoot'

fetchmail: IMAP< )

fetchmail: IMAP< A0010 OK FETCH completed.

fetchmail: IMAP> A0011
FETCH 1 BODY.PEEK[TEXT]

fetchmail: IMAP< A0011 OK
FETCH completed.

fetchmail: IMAP> A0012 LOGOUT

fetchmail: IMAP< * BYE Microsoft Exchange Server 2010
IMAP4 server signing off.

fetchmail: IMAP< A0012 OK LOGOUT completed.

fetchmail: client/server synchronization error while
fetching from dirsync_Base_G_09@192.168.125.100

fetchmail: 6.3.17 querying 192.168.125.100 (protocol
IMAP) at Thu 08 Jan 2015 10:28:51 PM BRST: poll completed

Merged UID list from 192.168.125.100: <empty>

fetchmail: Query status=7 (ERROR)

fetchmail: normal termination,
status 7


 		 	   		  

Re: [Fetchmail-users] Fetchmail multiple instances increasing load average

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

Am 29.12.2014 um 09:16 schrieb Anshul Chauhan:
> Hi,
> 
> I’m running centos 5.7 with sendmail-8.13.8-8.1.el5_7,
> fetchmail-6.3.6-4.el5 and procmail-3.22-17.1.el5.centos. My server is
> having around 2000 mailboxes and this server used to fetch mails for all
> these users using fetchmail from the other MX server. I’ve configured the
> below cron job using webmin for downloading these mail
> 
>  5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/webmin/fetchmail/check.pl
> --file /var/log/fetchmaillog.

Neither Webmin nor outdated fetchmail versions are supported on this
list, whatever check.pl does isn't known here (nor do we care).

Please check with the Webmin support.

Re: [Fetchmail-users] Fetchmail multiple instances increasing load average

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

On Mon Dec 29 2014 at 8:18:17 AM Anshul Chauhan <cha...@gm...>
wrote:

> Hi,
>
> I’m running centos 5.7 with sendmail-8.13.8-8.1.el5_7,
> fetchmail-6.3.6-4.el5 and procmail-3.22-17.1.el5.centos. My server is
> having around 2000 mailboxes and this server used to fetch mails for
> all these users using fetchmail from the other MX server. I’ve configured
> the below cron job using webmin for downloading these mail
>

Your fetchmail version is (very) out of date, as is your version of CentOS.
You should consider upgrading.


>  5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/webmin/fetchmail/check.pl
> --file /var/log/fetchmaillog.
>
> But the load average for the server goes high automatically after every
> 4 to 5 hours due to multiple fetchmail instances and after that I’ve to
> either kill all the fetchmail jobs or restart the server for making the
> system up again.
>
> Kindly suggest how can i reduce this load average issue or any other
> way out for downloading the mails from the parent server running on
> sendmail again.
>

Why are you running it every 5 minutes from cron? Why not use the daemon
mode?

-- 
Rob MacGregor

[Fetchmail-users] Fetchmail multiple instances increasing load average

[Anshul C. <cha...@gm...>]

Hi,

I’m running centos 5.7 with sendmail-8.13.8-8.1.el5_7,
fetchmail-6.3.6-4.el5 and procmail-3.22-17.1.el5.centos. My server is
having around 2000 mailboxes and this server used to fetch mails for all
these users using fetchmail from the other MX server. I’ve configured the
below cron job using webmin for downloading these mail

 5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/webmin/fetchmail/check.pl
--file /var/log/fetchmaillog.



But the load average for the server goes high automatically after every 4
to 5 hours due to multiple fetchmail instances and after that I’ve to
either kill all the fetchmail jobs or restart the server for making the
system up again.


Kindly suggest how can i reduce this load average issue or any other way
out for downloading the mails from the parent server running on sendmail
again.


Warm Regards,
Anshul Chauhan
"Never expect things to happen struggle & make them happen Never expect
yourself to be given a good value Create a value for your own.."

Re: [Fetchmail-users] Fetchmail is not fetching Sent folder from Gmail

[Jagannath N. <jag...@fo...>]

Dear Javi,





On 1 December 2014 at 00:47, Javi P <buz...@gm...> wrote:

> * On 30 nov 2014, Jagannath Naidu wrote:
>
> > Dear All,
> >
> >
> > poll imap.gmail.com port 993 with protocol imap
> > user 'XX...@XX...' password 'XXXXXXXXX' is user 'XX...@XX...'
> > folder "[Gmail]\Sent Mail"
> > ssl
> > sslproto SSL3
> > fetchall
> > keep
> > no rewrite;
> > #mda "/usr/bin/procmail -f %F -d %T";
> >
>
>
> NOTE: dont use SSL3, it is a dead protocol.
>
>
> You are using a backslash in your IMAP folder definition ("[Gmail]\Sent
> Mail")
>

Thanks Javi, problem resolved.  "[Gmail]/Sent Mail" did worked


> It should be a slash ("[Gmail]/Sent Mail").
>
>
> But note that some Gmail accounts have been created with localized
> (non-English) names, so you should first check your account with
> openssl, with a session like this (SSL certificates in ~/.ssl_certs):
>
> 1) first connect to IMAP server:
>         $ openssl s_client -crlf -connect imap.gmail.com:993 -CApath
> ~/.ssl_certs
>
> 2) send this commands:
>         a001 capability
>
>         a002 login myu...@gm... mypassword
>                         USE Your username and password
>
>         a003 capability
>
>         a004 list "" "*"
>
>         a005 list "" "%"
>
>
> In my account (english)
>
> a004 list "" "*"
> * LIST (\HasNoChildren) "/" "INBOX"
> * LIST (\Noselect \HasChildren) "/" "[Gmail]"
> * LIST (\HasNoChildren \All) "/" "[Gmail]/All Mail"
> * LIST (\HasNoChildren \Drafts) "/" "[Gmail]/Drafts"
> * LIST (\HasNoChildren \Important) "/" "[Gmail]/Important"
> * LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"
> * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam"
> * LIST (\HasNoChildren \Flagged) "/" "[Gmail]/Starred"
> * LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash"
> a004 OK Success
>
>
> Regards
> --
>
> Javi P
>



-- 
Thanks & Regards

B Jagannath
Keen & Able Computers Pvt. Ltd.1

[Fetchmail-users] Fetchmail is not fetching Sent folder from Gmail

[Jagannath N. <jag...@fo...>]

Dear All,

I am facing issue when i configure fetchmail to get "Sent Mial" from
gmail. Can someone suggest if you have also faced the same issue

I am running fecthmail as a normal user (not root). My .fetchmailrc

set no bouncemail
#set logfile /home/neocortex/fetchlogs/harsha
defaults:
  antispam -1
  batchlimit 100

poll imap.gmail.com port 993 with protocol imap
user 'XX...@XX...' password 'XXXXXXXXX' is user 'XX...@XX...'
folder "[Gmail]\Sent Mail"
ssl
sslproto SSL3
fetchall
keep
no rewrite;
#mda "/usr/bin/procmail -f %F -d %T";

fetching mail from inbox is working good, But I am unable to fecth
mail from Sent Items.
I run the following command

user@domain$fetchmail -kv 2>error >>output &

I also tried alternative : removed "folder "[Gmail]\Sent Mail"" from
fetchmailrc and then run

user@domain$fetchmail -kv --folder INBOX.Sent 2>error >>output &

and also tried

user@domain$fetchmail -kv --folder "[Gmail]\Sent Mail" 2>error >>output &

but still no success.









-- 
Thanks & Regards

B Jagannath
Keen & Able Computers Pvt. Ltd.

Re: [Fetchmail-users] fetchmail not polling multiple servers when IMAP IDLE used

[Hendrik H. <hen...@gm...>]

Hi,
using separate config folders and pids works great for me. I added a
script that creates the fetchmail files based on my own config file and
monitor all that with a cron job.
regards,
Hendrik

On 19/11/14 06:24, Jeremy Chadwick wrote:
> On Tue, Nov 18, 2014 at 07:52:24PM -0600, Corey Halpin wrote:
>> On 2014-11-18, Jeremy Chadwick wrote:
>>> It's almost as if use of IMAP IDLE causes the daemon to effectively
>>> ignore any other poll sections.
>> From the fetchmail manpage, in "The Run Control File" section, under
>> "Singledrop vs Multidrop options":
>>
>>   The 'idle' option is intended to be used with IMAP servers
>>   supporting the RFC2177 IDLE command extension, but does not strictly
>>   require it.  If it is enabled, and fetchmail detects that IDLE is
>>   supported, an IDLE will be issued at the end of each poll.  This
>>   will tell the IMAP server to hold the connection open and notify the
>>   client when new mail is available.  If IDLE is not supported,
>>   fetchmail will simulate it by periodically issuing NOOP. If you need
>>   to poll a link frequently, IDLE can save bandwidth by eliminating
>>   TCP/IP connects and LOGIN/LOGOUT sequences. On the other hand, an
>>   IDLE connection will eat almost all of your fetchmail's time,
>>   because it will never drop the connection and allow other polls to
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   occur unless the server times out the IDLE.  It also doesn't work
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   with multiple folders; only the first folder will ever be polled.
> Thank you Corey!
>
> Yup, I didn't actually manage to read that in the man page.  Bummer,
> although that conflicts with the following from section "GENERAL
> OPERATION":
>
>   Each  server name that you specify following the options on the
>   command line will be queried.  If you don't specify any servers on
>   the command line, each 'poll' entry in your ~/.fetchmailrc file
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   will be queried.
>   ^^^^^^^^^^^^^^^^
>
> Back to cronjobs, either that or maintaining two separate fetchmail
> config files + pid files, etc.  :/
>

Re: [Fetchmail-users] fetchmail not polling multiple servers when IMAP IDLE used

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

Am 23.11.2014 um 13:13 schrieb Peter Pentchev:
> On Sat, Nov 22, 2014 at 12:45:28AM +0100, Matthias Andree wrote:
>> Am 19.11.2014 um 06:24 schrieb Jeremy Chadwick:
>>
>>> Yup, I didn't actually manage to read that in the man page.  Bummer,
>>> although that conflicts with the following from section "GENERAL
>>> OPERATION":
>>>
>>>   Each  server name that you specify following the options on the
>>>   command line will be queried.  If you don't specify any servers on
>>>   the command line, each 'poll' entry in your ~/.fetchmailrc file
>>>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>   will be queried.
>>>   ^^^^^^^^^^^^^^^^
>>
>>
>>>
>>> Back to cronjobs, either that or maintaining two separate fetchmail
>>> config files + pid files, etc.  :/
>>
>> Jeremy,
>>
>> sorry about that.  In my opinion IMAP IDLE is somewhat useless due to
>> its limited applicability.  Either you bind resources on server and
>> client end keeping lots of connections open, or it simply won't work.
>> It may have been conceived as an INBOX monitor but once we start talking
>> about server-side filters, possibly sieve, that assumption seems
>> far-fetched...
>>
>> Thanks for pointing out the inconsistency in the manual page, I have
>> seen do that, and the next fetchmail releases will error out if --idle
>> is combined with multiple mailboxes and/or accounts.
> 
> Hmm, shouldn't it only error out in daemon mode?  I guess it might be
> fine for a single round of checks for new mail.
> 
> G'luck,
> Peter
> 

Hi Peter,

--idle does not look at --daemon, so --idle will make fetchmail sit on
the first polled IMAP mailbox that offers idle support and loop there,
so I presume the refusal should be independent of daemon mode.

Cheers,
Matthias

Re: [Fetchmail-users] fetchmail not polling multiple servers when IMAP IDLE used

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

Am 19.11.2014 um 06:24 schrieb Jeremy Chadwick:

> Yup, I didn't actually manage to read that in the man page.  Bummer,
> although that conflicts with the following from section "GENERAL
> OPERATION":
> 
>   Each  server name that you specify following the options on the
>   command line will be queried.  If you don't specify any servers on
>   the command line, each 'poll' entry in your ~/.fetchmailrc file
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   will be queried.
>   ^^^^^^^^^^^^^^^^


> 
> Back to cronjobs, either that or maintaining two separate fetchmail
> config files + pid files, etc.  :/

Jeremy,

sorry about that.  In my opinion IMAP IDLE is somewhat useless due to
its limited applicability.  Either you bind resources on server and
client end keeping lots of connections open, or it simply won't work.
It may have been conceived as an INBOX monitor but once we start talking
about server-side filters, possibly sieve, that assumption seems
far-fetched...

Thanks for pointing out the inconsistency in the manual page, I have
seen do that, and the next fetchmail releases will error out if --idle
is combined with multiple mailboxes and/or accounts.

Cheers,
Matthias

Re: [Fetchmail-users] fetchmail not polling multiple servers when IMAP IDLE used

[Jeremy C. <jd...@ko...>]

On Tue, Nov 18, 2014 at 07:52:24PM -0600, Corey Halpin wrote:
> On 2014-11-18, Jeremy Chadwick wrote:
> > It's almost as if use of IMAP IDLE causes the daemon to effectively
> > ignore any other poll sections.
> 
> From the fetchmail manpage, in "The Run Control File" section, under
> "Singledrop vs Multidrop options":
> 
>   The 'idle' option is intended to be used with IMAP servers
>   supporting the RFC2177 IDLE command extension, but does not strictly
>   require it.  If it is enabled, and fetchmail detects that IDLE is
>   supported, an IDLE will be issued at the end of each poll.  This
>   will tell the IMAP server to hold the connection open and notify the
>   client when new mail is available.  If IDLE is not supported,
>   fetchmail will simulate it by periodically issuing NOOP. If you need
>   to poll a link frequently, IDLE can save bandwidth by eliminating
>   TCP/IP connects and LOGIN/LOGOUT sequences. On the other hand, an
>   IDLE connection will eat almost all of your fetchmail's time,
>   because it will never drop the connection and allow other polls to
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   occur unless the server times out the IDLE.  It also doesn't work
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   with multiple folders; only the first folder will ever be polled.

Thank you Corey!

Yup, I didn't actually manage to read that in the man page.  Bummer,
although that conflicts with the following from section "GENERAL
OPERATION":

  Each  server name that you specify following the options on the
  command line will be queried.  If you don't specify any servers on
  the command line, each 'poll' entry in your ~/.fetchmailrc file
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  will be queried.
  ^^^^^^^^^^^^^^^^

Back to cronjobs, either that or maintaining two separate fetchmail
config files + pid files, etc.  :/

-- 
| Jeremy Chadwick                                   jd...@ko... |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

[Fetchmail-users] fetchmail not polling multiple servers when IMAP IDLE used

[Jeremy C. <jd...@ko...>]

Hi, I'm hoping this is a config mistake or brain fart on my part, but
I've spent a lot of time looking at fetchmail(1) and can't find anything
that would explain this behaviour.

I'm using fetchmail 6.3.26 on FreeBSD 9.3-STABLE.

The following is in my .fetchmailrc:

set daemon 120

poll imap.server
	protocol imap
	username user password pass
  	idle
	ssl sslfingerprint "aa:bb..."

poll pop3.server
	protocol pop3
	username user password pass
	ssl sslfingerprint "cc:dd..."

The behaviour I expect from this, based on the fetchmail(1) man page, is
that because I'm using daemon mode, fetchmail should remain running and
keep an active IMAP IDLE connection to imap.server, but then
periodically (every 120 seconds) poll (via POP3) pop3.server.  These are
two completely different servers, just to clarify.

Well, pop3.server never gets polled.  Using "set logfile blah.log" then
looking at that logfile never shows the daemon never attempting to
communicate to pop3.server barring this one scenario:

If I reverse the order of the two sections (i.e. put the pop3 one first)
and start fetchmail, it polls pop3.server once -- and only once -- then
proceeds to do IMAP IDLE to imap.server from that point forward.  It
never re-polls pop3.server.

Things I've tried:

* Setting "interval 60" (or some equivalent) inside of the pop3.server
  polling block -- no difference (and fetchmail --configdump shows that
  the parameter changes from 'interval':0 to 'interval':60)

* Running "fetchmail" by itself, which should "wake up" the daemon and
  attempt polling from defined servers -- it never does, meaning it acts
  as if the pop3.server poll section doesn't exist

* fetchmail --configdump shows both imap.server and pop3.server, and
  both are 'active':TRUE

If I remove use of the IMAP IDLE feature, things behave as I'd expect.
(I see the "sleeping at {date} for N seconds" message in the log, etc.)

It's almost as if use of IMAP IDLE causes the daemon to effectively
ignore any other poll sections.

Thoughts?

-- 
| Jeremy Chadwick                                   jd...@ko... |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

Re: [Fetchmail-users] $16 question about --bad-headers

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

Am 11.11.2014 um 07:09 schrieb Gene Heskett:
> Greetings;
> 
> Using a fetchmail thats only a couple months old, built from your tarball,
> 
> I just had to set, from a restart on the command line giving it the 
> --bad-header accept option in order to clear and retrieve an obviously C&C 
> message from a bot controller, or something similar.
> 
> The header really was bad:

Dear Gene,

Did the original header of the inbound message contain the "X-procmail:
user=gene" header?  Can you be positive that procmail and whatever
you're calling from it are not modifying it?

Is anything in your inbound path transforming messages ("decoding")?
Just to rule out that, for instance, some "MIME decode" is making a mess
of your mail.

> Received: from nx ([218.109.100.99])
> 	(authenticated user ad...@bh...)
> 	by empireland.net (Kerio Connect 7.1.2);
> 	Thu, 23 Oct 2014 12:42:33 -0600
> X-procmail: user=gene
> 
> »ú·¿»·¾³·¨¹æ
> Message-ID: <201...@bh...>

...

> Followed by about 23.5kb of what looked to be base64 encoded crap. 
> Image,virus, c&c, I have no clue.
> 
> Does anything in that look familiar to you folks? I haven't cleaned it up.

Doesn't look familiar to me, but I presume most of the crap is set aside
by the spam filters here. On the other hand, I do not  operate
large-scale mail servers at this time.

Probably not all that helpful to you.

Best regards,
Matthias