From b207b3e0065226b86c13ccb636cd91db34c24da2 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Mon, 6 Mar 2000 20:24:47 +0000 Subject: Added FAQ item X6. svn path=/trunk/; revision=2800 --- fetchmail-FAQ.html | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 96 insertions(+), 5 deletions(-) (limited to 'fetchmail-FAQ.html') 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 @@
Back to Fetchmail Home Page To Site Map -$Date: 2000/03/06 07:19:35 $ +$Date: 2000/03/06 20:24:47 $

Frequently Asked Questions About Fetchmail

@@ -136,6 +136,7 @@ my Received headers as it should.
X3. Messages containing "From" at start of line are being split.
X4. My mail is being mangled in a new and different way.
X5. Using POP3, retrievals seems to be fetching too much!
+X6. My mail attachments are being dropped or mangled.

Other problems:

@@ -2497,9 +2498,99 @@ TOP argument in 4.4.7 fixed this.

Fix: Upgrade to a later version of fetchmail.

-Workaround: set the fetchall option. Under POP3 in these -fetchmail version only, this had the side effect of forcing RETR -use.

+Workaround: set the fetchall option. Under POP3 +this has the side effect of forcing RETR use.

+ +

+

X6. My mail attachments are being dropped or mangled.

+ +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).

+ +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.

+ +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).

+ +One solution to problems related to misformatted MIME attachments is +the emil +program; see its tutorial +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.

+ +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.

+ +A possible rule to be inserted into a .procmailrc file for using emil +would be: + +

+: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}'
+}
+
+ +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.

+ +The emil call itself tries to ensure that the message uses: +

+ +Most of these (the primary exceptions being the character set and the +Apple binary format) are as they should be for good internet +interoperability.

+ +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.

O1. The --logfile option doesn't work if the logfile doesn't exist.

@@ -2668,7 +2759,7 @@ terminate it.

Back to Fetchmail Home Page To Site Map -$Date: 2000/03/06 07:19:35 $ +$Date: 2000/03/06 20:24:47 $

Eric S. Raymond <esr@snark.thyrsus.com>
-- cgit v1.2.3