> > > 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...
>
Is I understand from the mailing list archives, the people working on
the framework are the same people that work on James, so if you don't care,
then nobody does :-(
> > 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.
Wrong, their implementation is well-defined also. There are so many RFCs
that do define them in details ...
> 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).
>
But you would never configure RCPT to look in 1) and in the same time
configure VRFY to look in 3), right? IMHO more command-independent
approach to configuration would work better
> > 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.
Not if we do it right. (Still, I have not figured out that one yet ...)
> 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.
>
Not if we do it right :-)
> > 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.
It's called "TURN", but there is no need in it - its initial purpose
(connection
reuse) became meaningless with time as TCP connections became cheaper, and
some
people even say it has security implications.
> 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).
They were, but it died out somehow. Anyway, it was very different from what
I'm
talking about - they still were about to use different protocols for IM and
email.
> 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?
If I find anything that supports SEND when sending and notifies about IMAP
EXISTS,
I will probably use it. And, it's for some small (in distibution size)
client app,
so it should be in C++ or the like.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
