[fetchmail-devel] mapi again

[mojmir s. <moj...@2k...>]

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?)
- same about compilers?
	(gcc.. what about the bunch of others?)
- are there any restrictions about C language used in fetchmail?
	(variadic macros for example etc)
- any crucial advice concerning fetchmail development?

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

so ideally the solution would be like:
  if (PR_SENT_REPRESENTING_NAME is in form foo@FQDN)
	  use PR_SENT_REPRESENTING_NAME
  else
	  use PR_SENDER_EMAIL_ADDRESS;

perhaps there's some flag in the mapi protocol but i can only
guess... so:

3. documentation for mapi...
...would be great. do you have any, please?

4. mapi todo
- the problem above
- AND the same problem applying to To: and Cc: fields
- threading of messages does not work
- valgrind reporting some memory stuff (reads beyond etc)
- fetching messages is quite slow
- 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?
- flushing messages is also quite slow
- messages like:
	- xxx:54 was not the expected length (1032 actual != 4863 expected)


kind regards,
mojmir