Re: [fetchmail-devel] Add MAPI support to fetchmail

[Matthias A. <mat...@gm...>]

"Yangyan Li" <yan...@gm...> writes:

> Hi Matthias,
>  
> http://lwn.net/Articles/192409/ tells us why it's useful for FLOSS to
> talk with MAPI, and OpenChange are working on two different aspects:
> provide interoperability with Exchange protocols and provide a
> transparent replacement to Microsoft Exchange Server with native
> Exchange protocols support and direct communication with Microsoft
> Outlook.
>  
> Fetchmail will be able to pull mail from Exchange, as well as push
> mail to Exhange, if MAPI support is added. It seems that there are few
> software under linux platform which support MAPI. One I know is
> Evolution, which provides MAPI support with a plugin developed by
> OpenChange. So it will be useful to add MAPI support to Fetchmail.
>  
> It's not decided whether I am the chosen one of this GSoC project, and
> this will be decided before April 21, 2008. However, I'd like to
> contribute to this project even if I'm not the chosen one.

Yangyan, back to technical issues, I think there are two places that
need to be changed.

For pulling mail, a new protocol ("MAPI" or "MSMAPI") would have to be
added, fetchmail's internal interface has a sort-of poor man's
object-oriented interface in C as there's a struct containing a set of
function pointers (look for struct method, for instance at the end of
imap.c).

For pushing mail over MAPI, sink.c would have to be amended to, and I'm
not so happy with the current shape of sink.c since it uses lots of
"if"s and indirections to determine if it's supposed to talk SMTP
(default), LMTP, or to an MDA.

I would very much like to see sink.c sort of "disentangled" first. There
is a reason why it is the way it's now, because it used to support (and
technically still does) "fallback", i. e. if the SMTP server goes down,
retry through an MDA, however I convinced Eric to switch this off by
default long ago, and before I slipped into becoming the de-facto
fetchmail maintainer. If we lose this "fallback" functionality along the
way of cleaning up sink.c, I don't mind.

Relevant parts to look at are said sink.c, driver.c, transact.c, and
possibly a few of the fetching protocols (imap.c, pop3.c), and a second
thought needs to be spent on the issue on who (server vs. computer
running fetchmail) will track what messages have been downloaded
yet. For POP3, both modes are possible (LAST vs. UIDL), but I do
recommend UIDL. IMAP does not yet support fetchmail-side tracking
(UID/UIDVALIDITY); while there's a patch on the BerliOS patch tracker,
it does not comprise UIDVALIDITY, so I haven't merged it yet.

Be sure to check todo.html and TODO.txt (these are not identical!) so
you know which context you're working in and what my short- and
long-term ideas are (I would not call them "plans" yet).

Feel free to ask further questions or describe how you'd like to
contribute. I think we can then branch fetchmail and negotiate
Subversion (SVN) access for you with Graham.

The final issue I'd like to raise for this mail is that of licensing,
any third-party libraries should be GPLv2-compatible and
GPLv3-compatible and also AGPL-(Affero GPL) compatible so that I can
keep your parts should I rewrite major other parts of fetchmail and
maybe put them under the AGPL later on.

Hope that helps as an early starting point.

Best regards,

-- 
Matthias Andree