Note that this FAQ is occasionally updated from the SVN repository +
Note that this FAQ is occasionally updated from the Git repository and speaks in the past tense ("since") about a fetchmail release that is not yet available. Please try a release candidate for that version in case you need the new option.
@@ -186,7 +186,9 @@ messages but before deleting themFetchmail is licensed under the GNU General Public -License.
+href="http://www.gnu.org/licenses/old-licenses/gpl-2.0.html">GNU General Public +License v2. Details, including an exception that allows linking +against OpenSSL, are in the COPYING file in the fetchmail +distribution.If you found this FAQ in the distribution, see the README for fetchmail's full feature list.
@@ -350,7 +354,9 @@ save us both time if you upgrade and test with the latestBugs will be fixed, provided you include enough diagnostic information for me to go on. Send bugs to fetchmail-users. -When reporting bugs, please include the following:
+When sending bugs or asking for help, please do not make up + information except your password and please +report the following:If you still need to use Google's mail service, these links may help (valid as of 2011-04-13):
+Fetchmail can use RFC1731 GSSAPI authorization to safely identify you to your IMAP server, as long as you can share Kerberos V credentials with your mail host and you have a GSSAPI-capable -IMAP server - those are few.
+IMAP server.fetchmail does not compile in support for GSS by -default, since it requires libraries from the Kerberos V -distribution (available via FTP at athena-dist.mit.edu). -If you have these, compiling in GSS support is simple: add a +default, since it requires libraries from a Kerberos V +distribution, such as MIT + Kerberos or Heimdal + Kerberos.
+ +If you have these, compiling in GSS support is simple: add a
You'll need to have the OpenSSL libraries installed, and they
-should at least be version 0.9.6.
+should at least be version 0.9.7.
Configure with --with-ssl. If you have the OpenSSL libraries
installed in commonly-used default locations, this will
suffice. If you have them installed in a non-default location,
@@ -2472,6 +2489,64 @@ declaration auth password in your .fetchmailrc.--with-gssapi=[/path/to/krb5/root] option to
configure. For instance, I have all of my Kerberos V libraries
installed under /usr/krb5 so I run configure
@@ -2103,7 +2120,7 @@ SSL?
If the upgrade you did encompassed an upgrade to OpenSSL 1.0.0 or newer, you
+may need to run c_rehash on your certificate directories,
+particularly if you are using local certs directories (f. i. through fetchmail's --sslcertpath option).
Reason: OpenSSL 1.0.0, relative to earlier versions, uses a different hash
+for the symbolic links (symlinks) in its certs/ directory, so you
+need to recreate the symlinks by running c_rehash
+ /etc/ssl/certs (adjust this to where your installation keeps its
+certificates), and you cannot easily share this certs directory with
+applications linked against older OpenSSL versions.
Note: OpenSSL's c_rehash script is broken in several versions,
+which can cause malfunction if several OpenSSL tools versions are installed in
+parallel in separate directories. In such cases, you may need a workaround to
+get things going. Assuming your OpenSSL 1.0.0 is installed in
+/opt/openssl1.0.0 and your certificates are in
+/home/hans/certs, you'd do this (the corresponding fetchmail
+option is --sslcertpath /home/hans/certs on the commandline and
+sslcertpath /home/hans/cert in the rcfile):
+env PATH=/opt/openssl1.0.0/bin /opt/openssl1.0.0/bin/c_rehash /home/hans/certs ++ +
First, try upgrading to fetchmail 6.3.18 or newer. Release 6.3.18 has +received a considerable number of bug fixes for the authentication +feature (AUTH, AUTHENTICATE, SASL). Most notably, fetchmail aborts SASL +authentication attempts properly with an asterisk if it detects that it +cannot make progress with a particular authentication scheme. This fixes +issues where GSSAPI-enabled fetchmail cannot authenticate against +Microsoft Exchange 2007 and 2010. Note that this is a +bug in old fetchmail versions!
+ +Fetchmail by default attempts to authenticate using various schemes. +Fetchmail tries these schemes in order of descending security, meaning +the most secure schemes are tried first.
+ +However, sometimes the server offers a secure authentication scheme +that is not properly configured, or an authentication scheme such as +GSSAPI that requires credentials to be acquired externally. In some +situations, fetchmail cannot know that the scheme will fail beforehand, +without trying it. In most cases, fetchmail should proceed to the next +authentication scheme automatically, but this sometimes does not +work.
+ +Solution: Configure the right authentication scheme
+explicitly, for instance, with --auth cram-md5 or --auth
+ password on the command line or auth "cram-md5" or
+ auth "password" in the rcfile. Details can be found
+ in the manual page.
+ Note that auth password should only be used
+ across secure links (see the sslcertck and ssl/sslproto options).
+
The symption: 'fetchmail -v' retrieves the first few messages, +
Symptom: 'fetchmail -v' retrieves the first few messages, but hangs returning:
@@ -3231,12 +3306,12 @@ truncated, and fetchmail will later attempt to redownload the message (providing the server is standards conformant).The reason for the truncation is that fetchmail streams the body -directly from the POP3/IMAP server into the SMTP/LMTP server or MDA, so -fetchmail has already written a part of the message before it notices it -will be incomplete, and fetchmail cannot abort a transaction it has -started, and it's unclear if it ever will be able to, because this is -not standardized and the outcome will depend on the receiving software -(be it SMTP/LMTP or MDA).
+directly from the POP3/IMAP server into the SMTP/LMTP server or MDA (in +order to save memory), so fetchmail has already written a part of the +message before it notices it will be incomplete, and fetchmail cannot +abort a transaction it has started, and it's unclear if it ever will be +able to, because this is not standardized and the outcome will depend on +the receiving software (be it SMTP/LMTP or MDA).
Other problems