Chandru wrote:
Hi,
Took me a bit of time to figure out that I need to point James to the
apropriate dns server (default is localhost). The nameservers are set
correctly (I am using yahoo's namesservers currently).
The emails seem to be going out from James:
10/11/03 20:21:50 INFO James.Mailet: R
Hi,
Took me a bit of time to figure out that I need to point James to the
apropriate dns server (default is localhost). The nameservers are set
correctly (I am using yahoo's namesservers currently).
The emails seem to be going out from James:
10/11/03 20:21:50 INFO James.Mailet: RemoteDelivery:
Thank you, Bill.
Even though I raised this point, I doubt that I'm the best person from
the James Developers list to respond to your saying, "If you think
some great advantage could be had by splitting the APIs in this way,
tell me more."
I guess that Danny, Noel, Serge, or others, might be ab
Richard O. Hammer wrote:
Danny Angus wrote:
> ... JavaMail is explicitly and
> in its detail a mail client API, it lacks support in may areas for
the kind
> of server functionality James provides and it is not always easy, and
often
> impossible, to force James to use JavaMail interfaces and
Hi Danny,
On Nov 10, 2003, Danny Angus wrote:
Zoe, (Beware, long answer!)
Thanks for the explanations :)
Ist point.. James IMAP component is very much alpha status *still* .
Oh, well... that would make only three incomplete IMAP implementations
I know of: James, JimapD and Foedus. Do I see a tr
Rch,
> Reflecting upon what Danny wrote, I wonder if Sun ever considered the
> possibility of dividing the existing functionality in the JavaMail
> API. It would be great for us if this existing functionality were
> divided into a basic set, tools useful to both servers and clients,
> and an
Danny Angus wrote:
> ... JavaMail is explicitly and
> in its detail a mail client API, it lacks support in may areas for
the kind
> of server functionality James provides and it is not always easy,
and often
> impossible, to force James to use JavaMail interfaces and classes
for many
> of the ta
Zoe, (Beware, long answer!)
Ist point.. James IMAP component is very much alpha status *still* .
2nd point.. A James installation is an assembly of services in a container,
each of those services declares dependancies on other services, we use the
Avalon framework for managing this and distr
Hi Zoe (if that's your name and not your project's :) If it is,
apologies)
The IMAP part of James is not in step with the current James code for
one important reason:
You cannot persist messages in an IMAP store. This is because the
current implmentation of IMAP takes messages (from SMTP) and store
