> On Tue, 2005-05-10 at 16:37 +0200, [EMAIL PROTECTED] wrote:
> > I think that this check should be done on the MAIL FROM or
> > the RCPT TO and so not directly related to the STARTTLS and
> > AUTH.
> >
> > I would add to my list:
> > B2. "mail from" allowed only after AUTH/STARTTLS
> > C2. "r
> On Tue, 2005-05-10 at 16:37 +0200, [EMAIL PROTECTED] wrote:
> > I think that this check should be done on the MAIL FROM or
> > the RCPT TO and so not directly related to the STARTTLS and
> > AUTH.
> >
> > I would add to my list:
> > B2. "mail from" allowed only after AUTH/STARTTLS
> > C2. "r
On Tue, 2005-05-10 at 01:21 +0200, [EMAIL PROTECTED] wrote:
> I don't know MINA: is it useful only for server stuff or can it be used for
> client operations? We probably need to rewrite a javamail transport for SMTP
> (the one from sun is not so good and the gpl one from GNU is too limited).
> S
On Tue, 2005-05-10 at 16:37 +0200, [EMAIL PROTECTED] wrote:
> I think that this check should be done on the MAIL FROM or the RCPT TO and
> so not directly related to the STARTTLS and AUTH.
>
> I would add to my list:
> B2. "mail from" allowed only after AUTH/STARTTLS
> C2. "rcpt to" you can writ
> > > I believe that we should support fastfail for both
> STARTTLS and AUTH.
> >
> > Ok, but can you provide a real use case? What would you like to do
> > fast-failing there?
> > I mean that generic behaviours can be hardcoded, I want to
> know what
> > kind of fastfail you are imagining to b
> > > I believe that we should support fastfail for both
> STARTTLS and AUTH.
> >
> > Ok, but can you provide a real use case? What would you like to do
> > fast-failing there?
> > I mean that generic behaviours can be hardcoded, I want to
> know what
> > kind of fastfail you are imagining to b
On Tuesday 10 May 2005 15:34, [EMAIL PROTECTED] wrote:
> > > In order to continue the discussions about the possible
> >
> > solutions for
> >
> > > this list I would like to know if you can provide more fast-failing
> > > scenarios (probably due to SMTP extensions like AUTH,
> >
> > STARTTLS, etc)
> > In order to continue the discussions about the possible
> solutions for
> > this list I would like to know if you can provide more fast-failing
> > scenarios (probably due to SMTP extensions like AUTH,
> STARTTLS, etc).
>
> I believe that we should support fastfail for both STARTTLS and AU
> > In order to continue the discussions about the possible
> solutions for
> > this list I would like to know if you can provide more fast-failing
> > scenarios (probably due to SMTP extensions like AUTH,
> STARTTLS, etc).
>
> I believe that we should support fastfail for both STARTTLS and AU
> The power of mailets is that we do not have to come up with
> use-cases, but in this situation since there are so limited
> decisions/options at each command, I like breaking down the
> use cases as Stefano has done.
> [...]
> With A and B, we have two more interfaces, which the
> appropriate
> The power of mailets is that we do not have to come up with
> use-cases, but in this situation since there are so limited
> decisions/options at each command, I like breaking down the
> use cases as Stefano has done.
> [...]
> With A and B, we have two more interfaces, which the
> appropriate
>
> In order to continue the discussions about the possible solutions for this
> list I would like to know if you can provide more fast-failing scenarios
> (probably due to SMTP extensions like AUTH, STARTTLS, etc).
I believe that we should support fastfail for both STARTTLS and AUTH.
--Søren
--
>
> > D. SMTP "DATA": james currently reply "250 Message received" for each
> > message under the maximum size handled:
> > D1. add antivirus/antispam and other content filters and provide
> > dedicated failure feedback.
>
> I'm not a big fan of this step, since I don't see much benefit to
> fast-
[EMAIL PROTECTED] wrote:
I think fast-fail is a good thing but we need an abstract on what are the
problems we are trying to solve.
The power of mailets is that we do not have to come up with use-cases,
but in this situation since there are so limited decisions/options at
each command, I like bre
I think fast-fail is a good thing but we need an abstract on what are the
problems we are trying to solve.
Here is the list I have in my mind, please add more use cases if you find
them.
A. SMTP connection: james currently always reply "220 server ready", we
could fast-fail based on:
A1. remote
I think fast-fail is a good thing but we need an abstract on what are the
problems we are trying to solve.
Here is the list I have in my mind, please add more use cases if you find
them.
A. SMTP connection: james currently always reply "220 server ready", we
could fast-fail based on:
A1. remote
> Actually I was trying to say that I thought that a DSN
> listener could be attached to the Mail, this listener would
> be responsible for sending messages and could be invoked from
> any mailet.
> Remote delivery could respond to JavaMail events by
> triggering DSN events in the affected mess
> Actually I was trying to say that I thought that a DSN
> listener could be attached to the Mail, this listener would
> be responsible for sending messages and could be invoked from
> any mailet.
> Remote delivery could respond to JavaMail events by
> triggering DSN events in the affected mess
> "The *OTHER* of the *TWO* things I want to discuss is a
> change to how the SMTP handler is structured. I want to
> suggest a chained approach, although I'm not entirely sure of
> which of a couple directions would be best.
Let me try to do an example use-case and understand your solution:
> "The *OTHER* of the *TWO* things I want to discuss is a
> change to how the SMTP handler is structured. I want to
> suggest a chained approach, although I'm not entirely sure of
> which of a couple directions would be best.
Let me try to do an example use-case and understand your solution:
> so that we don't need to rely on each mailet behaviour for such tracking
I think that raising delivery status vents is very much part of the
responsibility of the mailets.
Events are triggered as a result of a change of state
Mailets responibility is to change the state, therefore they are
re
> A possible solution would be to have mailetcontext callbacks that are
called
> by the mailets to update the mail "delivery status" so that it can decide
> wethere to create DSNBounces (standard behaviour) or to inform the
> SMTPHandler of the status update ("in-protocol processor" behaviour).
Ac
> I think IIRC that JavaMail provides an event model for
> transport events which could reasonably be used to trigger
> DSN bounces, particularly in response to delayed. But that
> will require an implementation of JavaMail as the reference
> implementation doesn't initiate any events.
Ok but
> I think IIRC that JavaMail provides an event model for
> transport events which could reasonably be used to trigger
> DSN bounces, particularly in response to delayed. But that
> will require an implementation of JavaMail as the reference
> implementation doesn't initiate any events.
Ok but
> > I think that we should first improve (add) delivery status
> tracking in
> every
> > james part, then we can simply add the "in-protocol"
> handler or make
> > the root processor synchronized with the smtphandler (so that it
> > returns SMTP errorcodes instead of bounces).
>
> I think you'
> > I think that we should first improve (add) delivery status
> tracking in
> every
> > james part, then we can simply add the "in-protocol"
> handler or make
> > the root processor synchronized with the smtphandler (so that it
> > returns SMTP errorcodes instead of bounces).
>
> I think you'
Stefano
> I think that we should first improve (add) delivery status tracking in
every
> james part, then we can simply add the "in-protocol" handler or make the
> root processor synchronized with the smtphandler (so that it returns SMTP
> errorcodes instead of bounces).
I think you're confusing
> > > In-Protocol processor for SMTP handler:
>
> > I don't like this, sorry mate, because (pls read all of this, it is
> > *constructive*):
>
> I am feeling a bit snarky at the moment, but did you and the
> others who replied, happen to read the REST of my e-mail, or
> just the first part?
Hi
> > > In-Protocol processor for SMTP handler:
>
> > I don't like this, sorry mate, because (pls read all of this, it is
> > *constructive*):
>
> I am feeling a bit snarky at the moment, but did you and the
> others who replied, happen to read the REST of my e-mail, or
> just the first part?
Hi
On 10/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Danny Angus wrote:
> > I would propose an alternative architecture for James (not the mailet
> > API yet) which looks like this..
>
> I am feeling a bit snarky at the moment, but did you and the others who
> replied, happen to read the RES
On 09/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> In a REAL SMTP environment I think we need to allow custom behaviour in
> reply to the "RCPT TO" (recipient not local, relay not allowed) and in reply
> to the "DATA" commands (this is spam, mail too big, no virus please, other
> content f
On 09/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > However, my primary interests in contributing to James have
> > been the POJOfication of James, which seams to have been
> > placed on the back burner, and MINA. I'm also not sure how
> > to proceed with using MINA within James since do
32 matches
Mail list logo
