It's Daniel, sorry for this funny address (Exchange at work), but
my web-based mail just won't do here ...
Comments inline ...
> > This is just an example, because I think that Store above
> > Repository is useless and SMTPServer should not talk directly
> > to the repositories, but through some "Spooler" block, that
> > should also handle the relay and final delivery, and should
> > reference in configuration to the repositories blocks that it
> > should use and to the "FinalMessageStore" block for final delivery.
> >
> 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.
> > 2) SMTPHandler+commands. I know, it is tempting to put
> > every command in a separate class, but in reality it only
> > breaks state encapsulation of SMTPHandler and does not really
> > add to the flexibility. I tried this also and realized that
> > while i am adding a new command, the meaning of the most of
> > other commands changes dramatically, i.e. if I add "SEND",
> > then "RCPT" should not only store the recipient forward path,
> > but should also connect to the recipient's SMTP server and
> > try to issue "SEND" and "RCPT" there. As well changes "DATA"
> > command's meaning: store-n-forward becomes forward-immediately.
> >
> Well, the idea was we would be adding some "session handling" to the
> connection. I.E., when you did MAIL FROM, you would put in some
> connection's hashtable a key/value pair, much like how http servlets
> give you a generic session handling ability. I don't think that's
> implemented right now, but this gives you a very flexible approach to
> passing data along to the next command.
>
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.
> I actually think the current architecture would let you very
> easily let
> you build what you talk about. You could write your own RCPTAndChat
> class that handles RCPT TO... if it's a case where it's chat,
> you can do
> whatever else you might want to, but if it's email you can
> just call the
> parent method. So, maybe something like this... RCPTAndChat opens a
> connection, adds it as a session variable, and then calls
> RCPT's method
> to do the regular address grabbing thing. Then SEND is a new command
> and you do whatever you need to with that. Finally, DATAAndChat can
> check to see whether this is supposed to be a chat message
> (and use the
> outside connection available from the session object), or if
> it's email,
> just call DATA's method to handle the email.
>
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.
> However, I actually would disagree with how you're having the
> RCTP/SEND
> opening connections and doing immediate delivery. I think
> you want the
> chat messages to be queued in some repository just like email
> and have a
> separate thread send the message out. I don't know how SEND
> is supposed
> to work, but with the scenario you're suggesting, you get a
> huge series
> of open connections that must be opened... sender's client -> sender's
> mail/chat server, gets the RCPT TO -> some ISP's mail/chat
> server, gets
> RCPT TO -> recipient's mail/chat server, get RCPT TO -> recipient's
> client. I don't think this is how it was meant to be. Yes, the mail
> forwarding and delivering right now is a thread that checks each X
> seconds to see if there's a message, but what we plan to do
> is have the
> delivery thread instead wait () for a message to arrive, and
> then notify
> () that thread (or multiple instances of it), which will make mail
> forwarding/relaying effectively instant, and more robust.
>
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."
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
