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? > 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. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
