From: Matthias A. <mat...@gm...> - 2009-08-27 19:17:52
|
Hi Mojmir, and thanks for your continued care of the MAPI function. > hello again, > i have few things on my mind: > > 1. portability of fetchmail > - what all platforms do you support/want to support? > (i've seen some linuxes, bsds, are there more?) I usually care about Linux (Debian, Fedora, openSUSE), FreeBSD and Solaris. Not breaking Cygwin and the other mainstream BSDs would be nice. I don't care if you break BeOS or EMX or if Red Hat Linux 5.2 won't work. I think current versions of Linux, BSD, Solaris/openSolaris (as representative for the SysV systems), Cygwin. That should cover the important ones. If obscure or obsolete OSes break with MAPI support, never mind. > - same about compilers? > (gcc.. what about the bunch of others?) GCC 3.4 and 4.3 are a must, 3.3 - 4.4 would be nice. In doubt, try "-pedantic" :) > - are there any restrictions about C language used in fetchmail? > (variadic macros for example etc) I'm undecided, I don't want to break older systems deliberately, so avoid if you can for now. If it's used only for MAPI, use whatever suits your purpose. Note that macros defeat type checking, so use functions if you can. > - any crucial advice concerning fetchmail development? * Don't introduce security holes, avoid static buffers, and avoid unbounded access (array subscripts/indexes, non-length-limiting string functions) at all cost, particularly for statically sized buffers these are a must. * Where it makes sense to translate strings, please mark them translatable, and - I probably don't need to tell you - if there are various plural forms, please use the NGT_() macro, not just GT_(). Please don't assemble translated strings with fragments of English phrases. > 2. mapi > i have found the problem with the overwrite of address, but > have no fix yet. the problem occurs when value of tag > PR_SENT_REPRESENTING_NAME does not contain FQDN (fully qualified > domain name... is that the name?), because it gets scrambled > by the reply_hack function from transact.c > > this can be fixed by using PR_SENDER_EMAIL_ADDRESS, but it's > not perfect, since it contains weird stuff like > > From: > /O=TAKE-TWOINTERACTIVE/OU=2KGB/CN=RECIPIENTS/CN=AA...@2k...rp Looks like ITU-T X.500 series stuff, which isn't overly weird, it's just that you're usually interested in the CN field (common name). Depending on how openMAPI gets this information to you, take care of escaping and continuation lines. LDIF for instance has rather unusual (in my personal perspetion) line continuation format... just chop, insert LF and blank... > 3. documentation for mapi... > ...would be great. do you have any, please? I don't - OpenChange perhaps? Otherwise ask Jelmer Vernooi if he wants to help (he mentored Yang-Yan Li last year) or the openchange lists. > 4. mapi todo > - the problem above > - AND the same problem applying to To: and Cc: fields > - threading of messages does not work Is the cause known yet? Incomplete headers, such as In-Reply-To: or References:? > - valgrind reporting some memory stuff (reads beyond etc) If they're in OpenSSL, disregard. If they're in OpenChange, they'll probably want to know... > - fetching messages is quite slow Too bad. I'd say postpone this. If it works slowly, than that's better than "not at all" :) > - when > 1000 messages, fetchmail says it cannot open MDA > with some IO error. it fails in sink.c:open_mda_sink after > the popen. > report(stderr, GT_("MDA open failed\n")); > perhaps some descriptor leak? do you have any ideas, please? Try running with -vvv and see if you still get the "about to deliver with:" message, and please show it to me. Can I also see your mda option's argument? In doubt, report the usual stuff I ask users to report, http://www.fetchmail.info/fetchmail-FAQ.html#G3 WRT descriptor leaks: Try "lsof -c fetchmail" in a separate console while fetchmail is fetching and short before it fails, i. e. after say 500 or 700 messages. If it's a descriptor leak, you'll get to know. Otherwise, strace or truss could help. You could also grep "ps ax" or "ps -ef" output for hints of process table exhaustion (grep for your MDA software). > - flushing messages is also quite slow > - messages like: > - xxx:54 was not the expected length (1032 actual != 4863 expected) Probably similar artifacts to <http://www.fetchmail.info/fetchmail-FAQ.html#S2> - does it help to fiddle with the Exchange registry? HTH Best regards Matthias -- Matthias Andree |