james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [Proposal] FetchPOP configuration change
Date Tue, 07 Jan 2003 18:30:27 GMT
Noel J. Bergman wrote:
> Serge,
> I agree with your concern regarding whether Received includes the RCPT TO
> info.  Please note that I had originally proposed specifying the address
> that would be used for the new Mail.  Danny wanted more automatic support
> and mentioned Received.  I think that Received is good, but raised the
> question regarding the fragility of that contract, and so we've gone circle
> and come back to Received providing a default, and a configuration item
> providing a fallback.
> Personally, I'd like to eventually have much more of fetchmail's range of
> configuration items, where it makes sense, but Danny is right to push for
> simplicity in terms of what is required.
> If someone (e.g., Serge Sozonoff) is really interested in enhancing
> FetchPOP, I am fairly sure that Eric would be happy to explain any design
> rationale behind things that don't appear documented on the fetchmail web
> site (http://www.tuxedo.org/~esr/fetchmail/index.html).
> Personally, I'm not interested in demuxing enterprise e-mail from a single
> mailbox, but I can see how one might want to recreate RCPT TO addresses such
> as mailing lists or other.  If I were to use FetchPOP to migrate e-mail from
> my personal main mailbox to James, I believe that I'd have a lot to do to
> recreate the information that I currently use for client filtering.
>>a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail
>>   repository virtual file system.
> Interesting idea.  Can't JavaMail do that for us, since we'd be using it as
> a client talking to a server?

Yeah exactly, this gets back to my big mounting strategy... it allows to 
configure repositories more flexibly, so it's easier to wrap JavaMail 
(POP3, IMAP) with a Mail repository implementation.

I think once I get the time I'll probably create a branch to show how 
this would work since there seems resistance mainly because of the 
newness of the idea.  Or maybe just some conf file and related java code 
to explain it better.

>>I already plan to let us mount pop3 and imap mailboxes in the
>>virtual file system (assuming everyone likes this)
> I think that now that Danny has started pushing the Mailet API v3
> interfaces, the main things that need immediate attention are the Mail and
> User repository models.  I am not sure that everyone sees things the same
> way, yet.

Judging from the CVS commits, I think the Mail Repository is already 
moved over to the mailet API, and I don't really expect to make many 
changes.  I actually think it works just fine with the children support 
and storing/getting Mail objects.  We might separate spool repository, 
but I'm not too worried about that.  We'll potentially have to change 
the implementations depending on what we do with Mail objects (namely 
adding attributes), and my mounting change would only really change how 
lookups function (I believe).

Serge Knystautas
Loki Technologies

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message