1 files changed, 96 insertions, 5 deletions
diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html
index 271b1aa6..4ff55724 100644
--- a/fetchmail-FAQ.html
+++ b/fetchmail-FAQ.html
@@ -10,7 +10,7 @@
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2000/03/06 07:19:35 $
+<td width="30%" align=right>$Date: 2000/03/06 20:24:47 $
 </table>
 <HR>
 <H1>Frequently Asked Questions About Fetchmail</H1>
@@ -136,6 +136,7 @@ my Received headers as it should.</a><br>
 <a href="#X3">X3. Messages containing "From" at start of line are being split.</a><br>
 <a href="#X4">X4. My mail is being mangled in a new and different way.</a><br>
 <a href="#X5">X5. Using POP3, retrievals seems to be fetching too much!</a><br>
+<a href="#X6">X6. My mail attachments are being dropped or mangled.</a><br>
 
 <h1>Other problems:</h1>
 
@@ -2497,9 +2498,99 @@ TOP argument in 4.4.7 fixed this.<P>
 
 Fix: Upgrade to a later version of fetchmail.<P>
 
-Workaround: set the <code>fetchall</code> option.  Under POP3 in these
-fetchmail version only, this had the side effect of forcing RETR
-use.<P>
+Workaround: set the <code>fetchall</code> option.  Under POP3
+this has the side effect of forcing RETR use.<P>
+
+<hr>
+<h2><a name="X6">X6. My mail attachments are being dropped or mangled.</a></h2>
+
+This isn't fetchmail's doing -- fetchmail never drops lines in message
+bodies or attachments. It may be your POP server, or it may be the
+sender's mail user agent (or a bad combination of both).<p>
+
+The Mail Max POP3 server and the InterChange and Imail IMAP servers
+are known to simply drop MIME attachments when uploading messages.
+We've had sporadic reports of problems with Microsoft Exchange and
+Outlook servers.  Windows- and NT-based POP servers seem especially
+prone to mangle attachments.  If you are running one of these,
+replacing your server with a Unix machine is probably the only
+effective solution.<p>
+
+Rob Funk explains: Unfortunately there also remain many mail user
+agents that don't write correct MIME messages. One big offender is Sun
+MailTool attachments, which are formatted enough like MIME that some
+programs could get confused; these are generated by the mailtool and
+dtmail programs (the mail programs in Sun's OpenWindows and CDE
+environments).<p>
+
+One solution to problems related to misformatted MIME attachments is
+the <a href="ftp://ftp.uu.se/pub/unix/networking/mail/emil/">emil</a>
+program; see its <a
+href="ftp://ftp.uu.se/pub/unix/networking/mail/emil/TUTORIAL.html">tutorial</a>
+file at that site for details on emil.  It is useful for
+converting character sets, attachment encodings, and attachment
+formats.  At this writing, emil does not appear to have been
+maintained since a patch to version 2.1.0beta9 in late 1997, but it is
+still useful.<p>
+
+One good way of using emil is from within procmail.  You can have
+procmail look for signs of problematic message formatting, and pipe
+those messages through emil to be fixed.  emil will not always be able
+to fix the problem, in which case the message is unchanged.<p>
+
+A possible rule to be inserted into a .procmailrc file for using emil
+would be:
+
+<pre>
+:0HB
+* 1^1 ^Content-Type: \/X-sun[^;]*
+* 1^1 ^Content-Type: \/application/mac-binhex[^;]*
+* 1^1 ^Content-Transfer-Encoding: \/x-binhex[^;]*
+* 1^1 ^Content-Transfer-Encoding: \/x-uuencode[^;]*
+{
+  LOG="Converting $MATCH
+"
+  :0fw
+  | emil -A B -T Q -B BA -C iso-8859-1 -H Q -F MIME | gawk
++'{gsub(/\r\n?/,"\n");print $0}'
+}
+</pre>
+
+The "1^1" in the conditions is a way of specifying to procmail that if
+any one of the four listed expressions is found in the message, the
+total condition is considered true, and the message gets passed into
+emil.  These four subconditions check whether the message has a Sun
+attachment, a binhex attachment, or a uuencoded attachment; there are
+others that could be added to check these things better and to check
+other relevant conditions.  The "LOG=" line writes a line into the
+procmail log; the lone double-quote beginning the following line makes
+sure the log entry gets an end-of-line character.  The call to gawk
+(GNU awk) is for fixing end-of-line conventions, since emil sometimes
+leaves those in the format of the originating machine; it could
+probably be replaced with a sed subsitution.<p>
+
+The emil call itself tries to ensure that the message uses:
+<ul>
+<li> BinHex encoding for any Apple Macintosh-only attachments
+<li> Quoted-Printable encoding for text (when necessary)
+<li> Base64 Encoding for binary attachments
+<li> iso-8859-1 character set for text (unfortunately emil can't yet
+  convert from windows-1252 to iso-8859-1)
+<li> Quoted-Printable encoding for headers
+<li> MIME attachment format
+</ul>
+
+Most of these (the primary exceptions being the character set and the
+Apple binary format) are as they should be for good internet
+interoperability.<p>
+  
+Some mail servers (Lotus Domino is a suspect here) mangle
+Sun-formatted messages, so the conversion to MIME needs to happen
+before such programs see the message.  The ideal is to rid the world
+of Sun-formatted messages: don't use mailtool for sending attachments
+(it doesn't understand MIME anyway, and most of the world doesn't
+understand its attachments, so it really shouldn't be used at all),
+and make sure dtmail is set to use MIME rather than mailtool's format.<p>
 
 <hr>
 <h2><a name="O1">O1. The --logfile option doesn't work if the logfile doesn't exist.</a></h2>
@@ -2668,7 +2759,7 @@ terminate it.<p>
 <table width="100%" cellpadding=0><tr>
 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2000/03/06 07:19:35 $
+<td width="30%" align=right>$Date: 2000/03/06 20:24:47 $
 </table>
 
 <P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</A></ADDRESS>