/* Getopt for GNU. NOTE: getopt is now part of the C library, so if you don't know what "Keep this file name-space clean" means, talk to roland@gnu.ai.mit.edu before changing it! Copyright (C) 1987, 88, 89, 90, 91, 92, 93, 94, 95 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ /* This tells Alpha OSF/1 not to define a getopt prototype in . Ditto for AIX 3.2 and . */ #ifndef _NO_PROTO #define _NO_PROTO #endif #ifdef HAVE_CONFIG_H #include "config.h" #endif #if !defined (__STDC__) || !__STDC__ /* This is a separate conditional since some stdc systems reject `defined (const)'. */ #ifndef const #define const #endif #endif #include #include /* Comment out all this code if we are using the GNU C Library, and are not actually compiling the library itself. This code is part of the GNU C Library, but also included in many other GNU distributions. Compiling and linking in this code is a waste when using the GNU C library (especially if it is a shared library). Rather than having every GNU program understand `configure --with-gnu-libc' and omit the object files, it is simpler to just do this in the source for each such file. */ #if defined (_LIBC) || !defined (__GNU_LIBRARY__) /* This needs to come after some library #include to get __GNU_LIBRARY__ defined. */ #ifdef __GNU_LIBRARY__ /* Don't include stdlib.h for non-GNU C libraries because some of them contain conflicting prototypes for getopt. */ #include #endif /* GNU C library. */ /* This is for other GNU distributions with internationalized messages. The GNU C Library itself does not yet support such messages. */ #if HAVE_LIBINTL_H # include #else # define gettext(msgid) (msgid) #endif /* This version of `getopt' appears to the caller like standard Unix `getopt' but it behaves differently for the user, since it allows the user to intersperse the options with the other arguments. As `getopt' works, it permutes the elements of ARGV so that, when it is done, all the options precede everything else. Thus all application programs are extended to handle flexible argument order. Setting the environment variable POSIXLY_CORRECT disables permutation. Then the behavior is completely standard. GNU application programs can use a third alternative mode in which they can distinguish the relative order of options and other arguments. */ #include "getopt.h" /* For communication from `getopt' to the caller. When `getopt' finds an option that takes an argument, the argument value is returned here. Also, when `ordering' is RETURN_IN_ORDER, each non-option ARGV-element is returned here. */ char *optarg = NULL; /* Index in ARGV of the next element to be scanned. This is used for communication to and from the caller and for communication between successive calls to `getopt'. On entry to `getopt', zero means this is the first call; initialize. When `getopt' returns EOF, this is the index of the first of the non-option elements that the caller should itself scan. Otherwise, `optind' communicates from one call to the next how much of ARGV has been scanned so far. */ /* XXX 1003.2 says this must be 1 before any call. */ int optind = 0; /* The next char to be scanned in the option-element in which the last option character we returned was found. This allows us to pick up the scan where we left off. If this is zero, or a null string, it means resume the scan by advancing to the next ARGV-element. */ static char *nextchar; /* Callers store zero here to inhibit the error message for unrecognized options. */ int opterr = 1; /* Set to an option character which was unrecognized. This must be initialized on some systems to avoid linking in the system's own getopt implementation. */ int optopt = '?'; /* Describe how to deal with options that follow non-option ARGV-elements. If the caller did not specify anything, the default is REQUIRE_ORDER if the environment variable POSIXLY_CORRECT is defined, PERMUTE otherwise. REQUIRE_ORDER means don't recognize them as options; stop option processing when the first non-option is seen. This is what Unix does. This mode of operation is selected by either setting the environment variable POSIXLY_CORRECT, or using `+' as the first character of the list of option characters. PERMUTE is the default. We permute the contents of ARGV as we scan, so that eventually all the non-options are at the end. This allows options to be given in any order, even with programs that were not written to expect this. RETURN_IN_ORDER is an option available to programs that were written to expect options and other ARGV-elements in any order and that care about the ordering of the two. We describe each non-option ARGV-element as if it were the argument of an option with character code 1. Using `-' as the first character of the list of option characters selects this mode of operation. The special argument `--' forces an end of option-scanning regardless of the value of `ordering'. In the case of RETURN_IN_ORDER, only `--' can cause `getopt' to return EOF with `optind' != ARGC. */ static enum { REQUIRE_ORDER, PERMUTE, RETURN_IN_ORDER } ordering; /* Value of POSIXLY_CORRECT environment variable. */ static char *posixly_correct; #ifdef __GNU_LIBRARY__ /* We want to avoid inclusion of string.h with non-GNU libraries because there are many ways it can cause trouble. On some systems, it contains special magic mac
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [fetchmail]Domino IMAP and missing Content-Transfer-Encoding
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:Anthony.Kim%40walgreens.com">
   <META NAME="robots" CONTENT="index,nofollow">
   
   
   <LINK REL="Next"  HREF="010016.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
   </H1>
    <B>Anthony Kim
    </B> 
    <A HREF="mailto:Anthony.Kim%40walgreens.com"
       TITLE="[fetchmail]Domino IMAP and missing Content-Transfer-Encoding">Anthony.Kim@walgreens.com
       </A><BR>
    <I>Wed, 1 Mar 2006 23:02:52 -0600</I>
    <P><UL>
        
        <LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#10015">[ date ]</a>
              <a href="thread.html#10015">[ thread ]</a>
              <a href="subject.html#10015">[ subject ]</a>
              <a href="author.html#10015">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Summary: fetchmail was not retrieving Content-Transfer-Encoding
header via Domino IMAP.

As it turns out, it was the Domino IMAP server that wasn't offering
up the header.

On Fri, Feb 17, 2006, Matthias Andree wrote:

&gt;<i> In 6.4.X, we might implement an option so that fetchmail does not
</I>&gt;<i> split header/body fetch but get the whole message including
</I>&gt;<i> header in one huge piece as POP3 does which makes undeliverable
</I>&gt;<i> mail more expensive though.
</I>
Thankfully, I won't have to wait for this.

Much of Domino's IMAP behavior depends on the mail storage format
specified in the Person document in the Public Name and Address
Book.

There are three options for mail storage for incoming mail:

1. Keep in Sender's format
2. Prefers MIME
3. Prefers Notes Rich Text

My setting was &quot;Prefers MIME&quot;.  Switching to &quot;Keep in Sender's
format&quot; solved the missing encoding header problem.

According to IBM, &quot;Prefers MIME&quot; offers the best IMAP performance
in Domino &quot;When you choose this option, the router converts all
incoming messages to the MIME storage format at delivery time. The
messages are therefore stored in your mail file in MIME format.
This lets the IMAP server quickly serve all information about the
document (such as size) as well as the body of the document to an
IMAP client because the document is already stored in the necessary
MIME format for the client to read.&quot; [0]

I can only surmise this MIME storage results in some rather
non-standard IMAP behavior.

So long my goofy procmail hacks.

Thanks to Matthias Andress and Rob Funk for helping me troubleshoot.

Anthony

[0] <A HREF="http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument">http://www-128.ibm.com/developerworks/lotus/library/ls-D6_IMAP_Perf/?OpenDocument</A>



</PRE>
<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	
	<LI> Next message: <A HREF="010016.html">[fetchmail]Domino IMAP and missing Content-Transfer-Encoding
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#10015">[ date ]</a>
              <a href="thread.html#10015">[ thread ]</a>
              <a href="subject.html#10015">[ subject ]</