<title>The Fetchmail FAQ</title>
<meta name="description"
content="Frequently asked questions about fetchmail."/>
-<meta name="keywords" content="fetchmail, POP, POP2, POP3, IMAP, remote mail"/>
+<meta name="keywords" content="fetchmail, POP3, IMAP, remote mail"/>
</head>
<body>
<table width="100%" cellpadding="0" summary="Canned page footer">
<h2><a id="G8" name="G8">G8. What is the best server to use with
fetchmail?</a></h2>
-<p>Fetchmail will work with any POP, IMAP, ETRN, or ODMR server
+<p>Fetchmail will work with any POP3, IMAP, ETRN, or ODMR server
that conforms to the relevant standards/RFCs (and even some outright
broken ones like <a href="#S2">Microsoft Exchange</a> and <a
href="#S6">Novell GroupWise</a>). This doesn't mean it works equally
-well with all, however. POP2 servers, and POP3 servers without UIDL,
+well with all, however. POP3 servers without UIDL
limit fetchmail's capabilities in various ways described on the manual
page.</p>
a terminating newline get the POP3 message termination dot emitted
-- you guessed it -- right after the last character of the message,
with no terminating newline added. This will hang fetchmail or any
-other RFC-compliant server. IMAP is alleged to work OK, though.</p>
-
-<p>Older versions of Exchange are semi-usable. They randomly drop
-attachments on the floor, though. Microsoft acknowledges this
-as a known bug and apparently has no plans to fix it.</p>
+other RFC-compliant client. IMAP is alleged to work OK, though.</p>
+
+<p>Exchange 2003 SP2 has been observed to alter MIME boundary
+lines in multipart messages between one IMAP FETCH command and the next
+under some circumstances -- for instance, when the top-level
+Content-Transfer-Encoding is "binary" (which is commonplace with Perl's
+MIME::Lite module). This causes MUAs to not detect attachments, but
+render the whole message body as one lump of hardly legible to
+unintelligible text, rather than nicely presenting text part and
+attachments or images separately. The cause is that Exchange uses its
+own message store and needs to convert back to MIME message format
+on-the-fly, and apparently this is sometimes subject to such
+inconsistencies.
+</p>
<p>Fetchmail using IMAP usually supports the proprietary NTLM mode used
with Microsoft Exchange servers. "Usually" here means that it fails on some
</ul>
</blockquote>
-<p>But, the best option involves finding a server that runs better
-software.</p>
-
<h2><a id="S3" name="S3">S3. How can I use fetchmail with HP
OpenMail?</a></h2>
the mail that fetchmail fetches. It's best to avoid fetching mail from
Google until they are using standards-compliant software.</p>
+<p>If you still need to use Google's mail service, these links may help (valid as of 2011-04-13):</p>
+<ul>
+ <li><a href="http://mail.google.com/support/bin/topic.py?hl=en&topic=12805">Other ways to access Gmail > POP</a></li>
+ <li><a href="http://mail.google.com/support/bin/topic.py?hl=en&topic=12806">Other ways to access Gmail > IMAP</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&answer=47948">Using POP on multiple clients or mobile devices</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&answer=13291">Some [POP3] mail was not downloaded</a></li>
+<li><a href="http://mail.google.com/support/bin/answer.py?hl=en&answer=78774">I'm having problems downloading [IMAP] mail</a></li>
+</ul>
+
<hr/>
<h1>How to set up well-known security and authentication
methods</h1>
<h2><a id="R15" name="R15">R15. Help, I'm getting Authorization failure!</a></h2>
+<p>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. <strong>Note</strong> that this is a
+bug in old fetchmail versions!</p>
+
<p>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.</p>
<p>However, sometimes the server offers a secure authentication scheme
that is not properly configured, or an authentication scheme such as
GSSAPI does requires credentials to be acquired externally. In some
-situations, fetchmail cannot know the scheme will fail without trying.</p>
+situations, fetchmail cannot know the scheme will fail without trying
+it. In most cases, fetchmail should proceed to the next authentication
+scheme automatically, but this sometimes does not work.</p>
<p><strong>Solution:</strong> Configure the right authentication scheme
explicitly, for instance, with <kbd>--auth cram-md5</kbd> or <kbd>--auth
first message in your mailbox. This usually stems from a message like
the one shown below, which is automatically created on your server. This
message shows up if the University of Washington IMAP or PINE software
-is used on the server together with a POP2 or POP3 daemon that is not
+is used on the server together with a POP3 daemon that is not
aware of these messages, such as some versions of Qualcomm Popper
(QPOP):</p>
projects / ~andy / fetchmail / blobdiff