fetchmail-devel

[fetchmail-devel] Add MAPI support to fetchmail

[Yangyan L. <yan...@gm...>]

Hi all,

I am a student attended to join in GSoC 2008 (
http://code.google.com/soc/2008), and I am going join one project of
OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail,
perhaps as a plugin.

Now, I am puzzled how to add MAPI support to Fetchmail. I've found that in
Fetchmail there is a plugin option which allows users to use an external
program to establish the TCP connection. If I add MAPI support in this way,
I have to write an adapter to translate between MAPI and one of the
protocols Fetchmail supports. These is no need to change Fetchmail code in
this approach. However, seems the plugin option is incompatible with -f
option and mda option in Fetchmail.

Are there any other approaches to add MAPI support to Fetchmail?

Thanks!
Yangyan

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

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

Yangyan Li schrieb:
> Hi all,
> 
> I am a student attended to join in GSoC 2008 
> (http://code.google.com/soc/2008), and I am going join one project of 
> OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail, 
> perhaps as a plugin.
> 
> Now, I am puzzled how to add MAPI support to Fetchmail. I've found that 
> in Fetchmail there is a plugin option which allows users to use an 
> external program to establish the TCP connection. If I add MAPI support 
> in this way, I have to write an adapter to translate between MAPI and 
> one of the protocols Fetchmail supports. These is no need to change 
> Fetchmail code in this approach. However, seems the plugin option is 
> incompatible with -f option and mda option in Fetchmail.
> 
> Are there any other approaches to add MAPI support to Fetchmail?

Hi Yangyan,

In order to answer that question, I'd need to know which protocols, or 
directions, would MAPI support address? I'm pretty much agnostic of the 
Windows internals... So is MAPI good for:

- fetchmail pulling mail from some server, as alternative to IMAP, POP3 and 
thereabouts?

- fetchmail pushing mail locally to some other server, as alternative to 
SMTP/LMTP or MDA?

- both?

I think we should then fork a branch in the repository, as a side branch 
off of BRANCH_6-3, so that the support can later be merged into a 
to-be-created 6-4 branch or onto the trunk.

Best regards

-- 
Matthias Andree

Life is what happens to you while you're busy making other plans.
   						-- John Lennon, 1980

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

[Yangyan L. <yan...@gm...>]

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.

Best regards

2008/4/2, Matthias Andree <mat...@gm...>:
>
> Yangyan Li schrieb:
>
> > Hi all,
> >
> > I am a student attended to join in GSoC 2008 (
> > http://code.google.com/soc/2008), and I am going join one project of
> > OpenChange (http://www.openchange.org) to add MAPI support to Fetchmail,
> > perhaps as a plugin.
> >
> > Now, I am puzzled how to add MAPI support to Fetchmail. I've found that
> > in Fetchmail there is a plugin option which allows users to use an external
> > program to establish the TCP connection. If I add MAPI support in this way,
> > I have to write an adapter to translate between MAPI and one of the
> > protocols Fetchmail supports. These is no need to change Fetchmail code in
> > this approach. However, seems the plugin option is incompatible with -f
> > option and mda option in Fetchmail.
> >
> > Are there any other approaches to add MAPI support to Fetchmail?
> >
>
> Hi Yangyan,
>
> In order to answer that question, I'd need to know which protocols, or
> directions, would MAPI support address? I'm pretty much agnostic of the
> Windows internals... So is MAPI good for:
>
> - fetchmail pulling mail from some server, as alternative to IMAP, POP3
> and thereabouts?
>
> - fetchmail pushing mail locally to some other server, as alternative to
> SMTP/LMTP or MDA?
>
> - both?
>
> I think we should then fork a branch in the repository, as a side branch
> off of BRANCH_6-3, so that the support can later be merged into a
> to-be-created 6-4 branch or onto the trunk.
>
> Best regards
>
> --
> Matthias Andree
>
> Life is what happens to you while you're busy making other plans.
>                                                -- John Lennon, 1980
>

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

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

[Jelmer V. <je...@op...>]

Hi Matthias,

To quickly introduce myself: I'm one of the OpenChange developers and am
mentoring Yangyan for the Summer of Code. 

Am Freitag, den 18.04.2008, 09:51 +0200 schrieb matthias.andreea:
> 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.
OpenChange is licensed under GPLv3 or later; in other words,
incompatible with GPLv2-only licensed code but compatible with "GPLv2 or
later" licensed code. Is this a problem?

If it is, would it be acceptable if Yangyan's contributions were under
these three licenses but not OpenChange? I imagine the support for MAPI
would be a compile-time option anyway. Changing the OpenChange license
is not really an option since it relies on Samba, which is GPLv3 or
later as well.

Cheers,

Jelmer

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

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

Jelmer Vernooij schrieb am 2008-04-30:

> Hi Matthias,
> 
> To quickly introduce myself: I'm one of the OpenChange developers and am
> mentoring Yangyan for the Summer of Code. 
> 
> Am Freitag, den 18.04.2008, 09:51 +0200 schrieb matthias.andreea:
> > 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.
> OpenChange is licensed under GPLv3 or later; in other words,
> incompatible with GPLv2-only licensed code but compatible with "GPLv2 or
> later" licensed code. Is this a problem?
> 
> If it is, would it be acceptable if Yangyan's contributions were under
> these three licenses but not OpenChange? I imagine the support for MAPI
> would be a compile-time option anyway. Changing the OpenChange license
> is not really an option since it relies on Samba, which is GPLv3 or
> later as well.

Hi Jelmer, Yangyan, *,

I have contacted Carl Harris Jr (the popclient author, popclient is
fetchmail's predecessor, some lines of code remain in fetchmail) and
Eric S. Raymond (who extended and maintained fetchmail for a long time)
yesterday.

Carl considers GPLv3 compatible with his original distribution terms.

Eric lets me choose what suits the project best from "any version of
GPL", "GPL v2 or later", and "GPL v2 only", so I guess I'll turn it into
a "GPL v2, or, at your option, any later version of the GPL" for the
nonce, and later review if fetchmail as a whole should move on to GPL v3
or perhaps AGPL v3 - that would require a new license review.

I'll have to check if any code pieces remain that are GPLv2 only or
otherwise incompatible, or require consent of the authors to change to
"any later version" or similar; however, as I expect these to be minor,
I'm ready to drop or rewrite them if need be.

I expect the MAPI support to become part of a later fetchmail version
I'll dub 6.4 or 7.0 depending on the extent of other changes, so we have
the opportunity for a bigger cleanup anyways, and we should take it (for
instance, drop POP2 support).

WRT the MAPI code itself, I'd very much appreciate if it could be kept
in separate .c/.h/... files with as little changes to other files as
possible (for instance, don't hack too much on sink.c, but add a
sink-mapi.c file and just add the hooks to sink.c you need while
testing, and we'll in a team effort then split sink.c into sink.c,
sink-smtp.c (perhaps sink-lmtp.c), and sink-mda.c, and add your
sink-mapi.c.

HTH,

-- 
Matthias Andree