> > The idea behind the repositories (as I understand it), is that the
> > SMTPServer does talk directly to the repository, and another thread
> > watches that repository and handles relay and final delivery. I don't
> > know if abstracting a "Spooler" block really helps. What does that
> > accomplish that just accessing the repository directly
> > doesn't give you?
> >
> In your next message, Serge, you write about specialized mail
> repositories, and this is exactly what I am talking about here. Still,
> there is a point of Store above Repository being useless. What's your
> opinion on that? Also you did not comment on the current block
> nesting/dependency.
Well, I'm not really sure about the difference between a Store and a
Repository. I'll have to look over the code again to see the
difference. Also, I didn't comment on the block nesting/dependency as
I've touched none of the Avalon code and don't really know the design
objectives, plans, etc...
> For me, SMTP commands are something very standard and therefore should
> not be very customizable by the user(sysadmin). You, as I understand,
> see in them a kind of "Servlets" - flexible and user-created by
> definition.
Well, the SMTP commands themselves are well defined, but how they are
implemented is where we want the flexibility. For instance, we were
thinking that RCPT TO or VRFY could check against 1) unix users, 2)
relational database set of email addresses, 3) an exchange server, 4)
notes server, 5) file based repository... however you intend to restrict
mail delivery. So the commands stay relatively flexible for various
implementations, and the approach we took allows you to more easily add
support for commands like SEND and Extended SMTP commands (or so that
was the goal).
> Even if I do all that, ignorant user can just add my SEND command to the
> configuration without changing the implementation classes settings and
> by this breaking the SMTP server. Isn't it ugly? My point is that the
> "dissection" of the SMTP functionality should not be by command (horizontal)
> but by extention (vertical). The latter is harder to implement correctly
> though, and I haven't figured out how to do it exactly yet, but I think
> that "non-dissected" implementation would be sufficient for now.
I think your vertical design approach might be easier if we standardized
how SMTP commands work and then clearly define an approach for adding
implementation layers on top of this. However, you'll lose the ability
to easily add delivery status notification, or whatever other commands
you want to use to extend SMTP. What if you wanted to add your own
customized SMTP commands between the James server installed as the
gateway, and then multiple James mailbox servers? Granted SMTP has been
around for forever, but I think we wanted to keep it flexible so that
you COULD take SMTP in new directions if you wanted it. Otherwise with
the vertical design, the whole architecture gets cemented and it becomes
extremely difficult to implement new approaches.
> Unfortunately, the spec says that delivery should be immediate and the
> response code on RCPT command depends on the response code received from
> the recipient's SMTP server. Well, it does not explicitly say that, but
> it is clearly implied by:
> "The SEND command requires that the mail data be delivered to
> the user's terminal. If the user is not active (or not
> accepting terminal messages) on the host a 450 reply may
> returned to a RCPT command. The mail transaction is
> successful if the message is delivered [to] the terminal."
Ok, got it. That seems like a bit of a kludge, but understandably
necessary. So this basically means you should keep an open connection
for a chat conversation between two users. Between the instant delivery
of SEND and then the SMTP command to reverse who the client and server
are (I forget off hand what this is), you allow a 2-way communication
over this one TCP/IP interface. Very interesting... hmmm... this does
all seem radically different than email... but it would be a nice
integration for the user if it was the same client (I think this is what
Mozilla is going to try to do... integrate email and IM).
Anyway... sounds like you have your work cut out for you. What are you
planning to use for the client? Are you creating your own custom one,
or building code to integrate with the other mainstream instant
messaging packages?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
