Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fetchmail; continually losing authentication with gmx.net
132 views
Skip to first unread message
Ron Leach
Nov 24, 2014, 2:30:04 PM11/24/14
to
List, good evening,
We use Fetchmail to collect email from various addresses and
providers. The incoming mail is passed to Exim for delivery to
mailboxes, and served to local MUAs on the network using IMAP provided
by Dovecot. We've had this architecture in place since Debian Etch
(D4) and it is (still) working well. We are updating our network to
run those same applications on a new box with Wheezy, and we are
testing this at the moment. For testing purposes, we have set
Fetchmail on both machines (the live Etch system, and the trial Wheezy
system) to 'keep' the POP3 mail on the ISP servers, and not flush the
downloaded mails. This way, we can be sure that both machines will
'see' the same mail, and we can check everything is working on the new
machine. It isn't.
The new Wheezy system uses Fetchmail 6.3.21-4, and we are using the
exact fetchmailrc from the Etch system (Fetchmail 6.3.6-1etch2). The
usernames and passwords are in the fetchmailrc file. One of our POP3
providers is gmx.net, though we do not actively use that address so
much, and the traffic is low. We've noticed that Fetchmail on the new
Wheezy system isn't seeing most of the gmx.net email. This is
because, though it initially connects at each poll, presents the
password, and receives the mail, after a few polls, it seems to fail
the authorisation. (I'm not sure why, yet.) Fetchmail logs the poll
and reports authorisation failure. It never re-establishes
authorisation on successive polls. It does successfully download
mails from gmx.net after this, when I restart Fetchmail:
# /etc/init.d/fetchmail stop
# /etc/init.d/fetchmail start
The live Etch machine is reporting no authorisation problems, and sees
all the gmx.net mail.
I've looked through the man fetchmail pages and I'd like to get some
extra logging but I can't seem to pass the -vv parameter to fetchmail.
Fetchmail starts as a daemon, and I can stop it and start it again, but
# /etc/init.d/fetchmail start -vv
doesn't seem to have any effect.
Is there a way I could restart fetchmail as if it had been invoked as
'fetchmail -vv'? With the extra logging I am hoping it will say why
the authorisation is failing.
Grateful for any advice,
regards, Ron
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5473869D...@tesco.net
We use Fetchmail to collect email from various addresses and
providers. The incoming mail is passed to Exim for delivery to
mailboxes, and served to local MUAs on the network using IMAP provided
by Dovecot. We've had this architecture in place since Debian Etch
(D4) and it is (still) working well. We are updating our network to
run those same applications on a new box with Wheezy, and we are
testing this at the moment. For testing purposes, we have set
Fetchmail on both machines (the live Etch system, and the trial Wheezy
system) to 'keep' the POP3 mail on the ISP servers, and not flush the
downloaded mails. This way, we can be sure that both machines will
'see' the same mail, and we can check everything is working on the new
machine. It isn't.
The new Wheezy system uses Fetchmail 6.3.21-4, and we are using the
exact fetchmailrc from the Etch system (Fetchmail 6.3.6-1etch2). The
usernames and passwords are in the fetchmailrc file. One of our POP3
providers is gmx.net, though we do not actively use that address so
much, and the traffic is low. We've noticed that Fetchmail on the new
Wheezy system isn't seeing most of the gmx.net email. This is
because, though it initially connects at each poll, presents the
password, and receives the mail, after a few polls, it seems to fail
the authorisation. (I'm not sure why, yet.) Fetchmail logs the poll
and reports authorisation failure. It never re-establishes
authorisation on successive polls. It does successfully download
mails from gmx.net after this, when I restart Fetchmail:
# /etc/init.d/fetchmail stop
# /etc/init.d/fetchmail start
The live Etch machine is reporting no authorisation problems, and sees
all the gmx.net mail.
I've looked through the man fetchmail pages and I'd like to get some
extra logging but I can't seem to pass the -vv parameter to fetchmail.
Fetchmail starts as a daemon, and I can stop it and start it again, but
# /etc/init.d/fetchmail start -vv
doesn't seem to have any effect.
Is there a way I could restart fetchmail as if it had been invoked as
'fetchmail -vv'? With the extra logging I am hoping it will say why
the authorisation is failing.
Grateful for any advice,
regards, Ron
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5473869D...@tesco.net
Frédéric Marchal
Nov 24, 2014, 4:10:06 PM11/24/14
to
Le Monday 24 November 2014 20:27:25, Ron Leach a écrit :
> List, good evening,
The best thing to do when debugging that kind of problem is to have a look at
the content of /etc/init.d/fetchmail, find the actual fetchmail command started
by the script and run the command manually from the shell.
Don't forget to remove the option to run fetchmail as a daemon (I don't
remember its name but it's in the man page). You can add any option you need
such as -vv and see the output in the terminal.
When you have seen what you wanted to see, abort fetchmail with ctrl+c and
restart it with the init script to resume normal operation.
Frederic
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/201411242202.1824...@wowtechnology.com
> List, good evening,
>
> I've looked through the man fetchmail pages and I'd like to get some
> extra logging but I can't seem to pass the -vv parameter to fetchmail.
> Fetchmail starts as a daemon, and I can stop it and start it again, but
>
> # /etc/init.d/fetchmail start -vv
>
> doesn't seem to have any effect.
>
> Is there a way I could restart fetchmail as if it had been invoked as
> 'fetchmail -vv'? With the extra logging I am hoping it will say why
> the authorisation is failing.
You can't pass options to the init script like that.
> I've looked through the man fetchmail pages and I'd like to get some
> extra logging but I can't seem to pass the -vv parameter to fetchmail.
> Fetchmail starts as a daemon, and I can stop it and start it again, but
>
> # /etc/init.d/fetchmail start -vv
>
> doesn't seem to have any effect.
>
> Is there a way I could restart fetchmail as if it had been invoked as
> 'fetchmail -vv'? With the extra logging I am hoping it will say why
> the authorisation is failing.
The best thing to do when debugging that kind of problem is to have a look at
the content of /etc/init.d/fetchmail, find the actual fetchmail command started
by the script and run the command manually from the shell.
Don't forget to remove the option to run fetchmail as a daemon (I don't
remember its name but it's in the man page). You can add any option you need
such as -vv and see the output in the terminal.
When you have seen what you wanted to see, abort fetchmail with ctrl+c and
restart it with the init script to resume normal operation.
Frederic
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Leach
Nov 25, 2014, 3:40:05 PM11/25/14
to
On 24/11/2014 21:02, Frédéric Marchal wrote:
>
> The best thing to do when debugging that kind of problem is to have a look at
> the content of /etc/init.d/fetchmail, find the actual fetchmail command started
> by the script and run the command manually from the shell.
>
> Don't forget to remove the option to run fetchmail as a daemon (I don't
> remember its name but it's in the man page). You can add any option you need
> such as -vv and see the output in the terminal.
>
Did the trick. Logs show that fetchmail is
>
> The best thing to do when debugging that kind of problem is to have a look at
> the content of /etc/init.d/fetchmail, find the actual fetchmail command started
> by the script and run the command manually from the shell.
>
> Don't forget to remove the option to run fetchmail as a daemon (I don't
> remember its name but it's in the man page). You can add any option you need
> such as -vv and see the output in the terminal.
>
1. using opportunistic TLS on pop3, but
2. Sometimes times out after receiving a certificate, and then
3. Fetchmail declines to use TLS with the *next* user, but
4. gmx complains about not using ssl, and fails the authorisation.
That repeats at each poll. I wonder what might be causing the
timeout? But shouldn't fetchmail tolerate communication hiccups,
anyway? (Rhetorical Qs.)
I'll post the log showing the fail event(s) in case it helps, but I
think I'd like to run either the latest fetchmail (from sourceforge),
or the version from Debian Etch (which doesn't fail).
Here's a failing fetchmail log (anonymised). Fetchmail tries to
collect mail for 2 users, user1 and user2. TLS fails during user1,
and fetchmail then doesn't try TLS for user2 (and doesn't try TLS ever
again for user2, though not shown here), but gmx complains every time
about not using SSL.
fetchmail: awakened at Tue 25 Nov 2014 18:33:40 GMT
fetchmail: 6.3.21 querying pop.gmx.net (protocol POP3) at Tue 25 Nov
2014 18:33:40 GMT: poll started
fetchmail: Trying to connect to 212.227.17.169/110...connected.
fetchmail: POP3< +OK POP server ready H migmx123 0[…]
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< IMPLEMENTATION trinity
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation
fetchmail: Certificate chain, from root to peer, starting at depth 2:
fetchmail: Issuer Organisation: Deutsche Telekom AG
fetchmail: Issuer CommonName: Deutsche Telekom Root CA 2
fetchmail: Subject CommonName: Deutsche Telekom Root CA 2
fetchmail: Certificate at depth 1:
fetchmail: Issuer Organisation: Deutsche Telekom AG
fetchmail: Issuer CommonName: Deutsche Telekom Root CA 2
fetchmail: Subject CommonName: TeleSec ServerPass DE-1
fetchmail: Server certificate:
fetchmail: Issuer Organisation: T-Systems International GmbH
fetchmail: Issuer CommonName: TeleSec ServerPass DE-1
fetchmail: Subject CommonName: pop.gmx.net
fetchmail: Subject Alternative Name: pop.gmx.net
fetchmail: Subject Alternative Name: pop.gmx.de
fetchmail: pop.gmx.net key fingerprint:
8A:B7:78:CF:0D:73:4E:EE:FF:EB:B8:C0:90:7D:46:56
fetchmail: timeout after 100 seconds.
fetchmail: socket error while fetching from [user1]@gmx...@pop.gmx.net
fetchmail: 6.3.21 querying pop.gmx.net (protocol POP3) at Tue 25 Nov
2014 18:35:37 GMT: poll completed
fetchmail: Merged UID list from pop.gmx.net: 0[…]= SEEN
fetchmail: Query status=2 (SOCKET)
fetchmail: 6.3.21 querying pop.gmx.net (protocol POP3) at Tue 25 Nov
2014 18:35:37 GMT: poll started
fetchmail: Trying to connect to 212.227.17.169/110...connected.
fetchmail: POP3< +OK POP server ready H migmx123 0[…]
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< UIDL
fetchmail: POP3< STLS
fetchmail: POP3< USER
fetchmail: POP3< SASL PLAIN
fetchmail: POP3< IMPLEMENTATION trinity
fetchmail: POP3< .
fetchmail: POP3> STLS
fetchmail: POP3< +OK Begin TLS negotiation
fetchmail: pop.gmx.net: opportunistic upgrade to TLS failed, trying to
continue.
fetchmail: POP3> USER [user2]@gmx.net
fetchmail: Repoll immediately on [user2]@gmx...@pop.gmx.net
fetchmail: Trying to connect to 212.227.17.169/110...connected.
fetchmail: POP3< +OK POP server ready H migmx123 0[…]
fetchmail: POP3> USER [user2]@gmx.net
fetchmail: POP3< +OK password required for user "[user2]@gmx.net"
fetchmail: POP3> PASS *
fetchmail: POP3< -ERR Fehler beim Abruf Ihrer GMX E-Mails. Ihre
Verbindung ist nicht verschluesselt. Aktivieren Sie SSL in Ihrem
Mailprogramm. Anleitungen: https://ssl.gmx.net
fetchmail: Fehler beim Abruf Ihrer GMX E-Mails. Ihre Verbindung ist
nicht verschluesselt. Aktivieren Sie SSL in Ihrem Mailprogramm.
Anleitungen: https://ssl.gmx.net
Translation: Error retrieving your GMX email. Your connection is not
encrypted. Enable SSL in your mail program. Instructions:
https://ssl.gmx.net
fetchmail: Authorisation failure on [user2]@gmx...@pop.gmx.net
(previously authorised)
fetchmail: POP3> QUIT
fetchmail: 6.3.21 querying pop.gmx.net (protocol POP3) at Tue 25 Nov
2014 18:36:42 GMT: poll completed
fetchmail: Merged UID list from pop.gmx.net: 0[…]= SEEN
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Writing fetchids file.
fetchmail: sleeping at Tue 25 Nov 2014 18:36:42 GMT for 150 seconds
I've also saved a log showing the preceding (working) sequence where
fetchmail successfully checks mailboxes for both users; I didn't post
it, to save length, but can do if anyone wishes to see it.
I'm not sure what to do. In particular, I'm not sure whether I should
try to debug this a little further, in case there's a config problem
(though it's the same config as the Etch server, and fetchmail works
for a while before tripping, and I have tried with various config
tweaks before posting to the list) or in case there's an instability
in this version which the maintainers should be told about. Delighted
to have some advice on this.
I'd prefer to either (i) try the latest fetchmail (6.3.26) from
sourceforge:
http://www.fetchmail.info/
http://sourceforge.net/projects/fetchmail/files/branch_6.3/fetchmail-6.3.26.tar.xz/download?use_mirror=heanet&r=https%3A%2F%2Fsourceforge.net%2F&use_mirror=heanet
but it isn't signed and hasn't been checked by the Debian maintainers,
and it's a .xz file with the sources and a bunch of directories and
I've never compiled anything before, and I believe that Debian uses
certain principles for various directories and things, and this may
create a series of 'useful learning experiences' for me if I were to
go that route. Happy to try it, actually, but the absence of
integrity checking is my main concern, though.
or (2) I'd like to run the Etch version. Is that possible, and if so
how might I get that version into the wheezy box? I have a set of
Etch CDs but I haven't managed to get aptitude to use CDs. I guess
apt could read them and maybe I could ask apt to install the specific
older fetchmail version. I'm really asking whether that would be at
all viable and whether it would be expected to create problems for
Wheezy or the other apps on the box (Exim and Dovecot, in particular).
I'd be grateful for any opinions about how to move forward, including
the issue of fetchmail's instability on this box which isn't fully
determined at the moment.
Apologies for the length of the post,
regards, Ron
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Frédéric Marchal
Nov 26, 2014, 3:00:04 AM11/26/14
to
disabled system wide for security reasons (see the poodle attack).
I ran the following command to debug a ssl connection to your server
and it succeed:
openssl s_client -connect pop.gmx.net:110 -starttls pop3 -debug
But requiring SSLv3 doesn't work:
openssl s_client -connect pop.gmx.net:110 -starttls pop3 -debug -ssl3
The connection is rejected much like what your log shows.
You'll have to investigate a bit but my theory is that fetchmail is
requesting SSLv3. As it is disabled by wheezy but is accepted by etch
it works with the latter but not the former.
Fetchmail should have an option to force the ssl protocol to be TLSv1.
I think it should be --sslprotoversion tlsv1 or something similar.
Frederic
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Leach
Nov 29, 2014, 7:10:04 AM11/29/14
to
On 26/11/2014 07:50, Frédéric Marchal wrote:
>
> Fetchmail certainly uses the system ssl library and SSLv3 was recently
> disabled system wide for security reasons (see the poodle attack).
>
> [snip]
>
> Fetchmail certainly uses the system ssl library and SSLv3 was recently
> disabled system wide for security reasons (see the poodle attack).
>
>
> You'll have to investigate a bit but my theory is that fetchmail is
> requesting SSLv3. As it is disabled by wheezy but is accepted by etch
> it works with the latter but not the former.
>
> Fetchmail should have an option to force the ssl protocol to be TLSv1.
> I think it should be --sslprotoversion tlsv1 or something similar.
>
Astute, Frederick.
> You'll have to investigate a bit but my theory is that fetchmail is
> requesting SSLv3. As it is disabled by wheezy but is accepted by etch
> it works with the latter but not the former.
>
> Fetchmail should have an option to force the ssl protocol to be TLSv1.
> I think it should be --sslprotoversion tlsv1 or something similar.
>
I altered the poll details for ...@gmx.net to say:
poll pop.gmx.net with proto POP3 timeout 100 and options
auth password no dns uidl
user '[...]@gmx.net' there with password '[...]' is
'[...]' here options sslproto 'TLS1' keep stripcr fetchlimit 5
[the 'keep' parameter is only there while I am testing, so as not to
lose any mails after architecture changes or rebuilds etc. In the
production system the 'keep' will be absent.]
This has been running for 3 days, now, without missing a beat.
You solved it. Thank you for the insights.
regards, Ron
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages