> Norman Maurer wrote:
> > BTW, after think a bit about this there is no need for implemt
> > ConnectionHandler on this type of check. Cause the "error code"
> > get returned on RCPT.. So it whould be enought to implement
> > CommandHandler.
> Right, I think that every autorization/relay check sho
JAMES-567:
Attachment: rbl.patch
Ok here is the patch to use the new api.. Let me know what you think about
Convert DNSRBLHandler to use the new smtp-fast-fail-api
---
Key: JAMES-567
URL: http://issues.apach
[ http://issues.apache.org/jira/browse/JAMES-567?page=all ]
Norman Maurer resolved JAMES-567.
-
Fix Version/s: 3.0
Resolution: Fixed
> Convert DNSRBLHandler to use the new smtp-fast-fail-
; > Convert DNSRBLHandler to use the new smtp-fast-fail-api
> > ---
> >
> > Key: JAMES-567
> > URL: http://issues.apache.org/jira/browse/JAMES-567
> > Project: James
&g
[ http://issues.apache.org/jira/browse/JAMES-567?page=all ]
Norman Maurer updated JAMES-567:
Attachment: rbl.patch
Ok here is the patch to use the new api.. Let me know what you think about
> Convert DNSRBLHandler to use the new smtp-fast-fail-
Convert DNSRBLHandler to use the new smtp-fast-fail-api
---
Key: JAMES-567
URL: http://issues.apache.org/jira/browse/JAMES-567
Project: James
Issue Type: Improvement
Reporter
Thx Noel,
so i remembered it right. I just did a commit in the sandbox to throw an
ConfigurationException on startup when an unimplemented command was used
to configure the command handler. I think thats a great improvment
( also to the current handler loading) to get sure that an admin can not
mi
Venkataraman, Narendra wrote:
I agree with you on the implicit dependencies on state hash map.
While you work on A, I propose to implement some useful message and
command handlers that we can ship with JAMES.
The experience in developing these handlers can provide inputs to long
term B approach.
?
Naren
-Original Message-
From: Stefano Bagnara [mailto:[EMAIL PROTECTED]
Sent: Friday, April 21, 2006 10:54 PM
To: James Developers List
Subject: Re: Fast-fail / Handlerchain change proposal
I would move the solution to this problem for a second refactoring, btw,
as we are here I try
I would move the solution to this problem for a second refactoring, btw,
as we are here I try to plot a solution:
1) events (extension points) can be published by every component
2) the default events connect and command are handled using the
ConnectHandler and CommandHandler, while the message
[mailto:[EMAIL PROTECTED]
Sent: Friday, April 21, 2006 10:11 PM
To: James Developers List
Subject: Re: Fast-fail / Handlerchain change proposal
Venkataraman, Narendra wrote:
> How would we configure a handler class that implements both
> CommandHandler and Message Handler?
>
Venkataraman, Narendra wrote:
How would we configure a handler class that implements both
CommandHandler and Message Handler?
Will the DataCommandHandler call all the commandhandlers to see if they
want add any header to final message?
You can specify the same class as commandHandler and as mes
: Friday, April 21, 2006 9:50 PM
To: James Developers List
Subject: Re: Fast-fail / Handlerchain change proposal
Venkataraman, Narendra wrote:
> With the design you are proposing, the protocol chain handler needs to
> be aware of a Command handler called DATACommandHandler since it has
Subject: Re: Fast-fail / Handlerchain change proposal
Venkataraman, Narendra wrote:
> Regarding moving message handler code to DATACmdHandler code would
> make the architecture inflexible, if somebody wants to develop their
> own Custom Datahandler and still reuse some of the message
Am Freitag, den 21.04.2006, 16:20 +0200 schrieb Stefano Bagnara:
> Norman Maurer wrote:
> >> 2) Split currently provided command handlers into multiple command
> >> handlers: the current handler already support multiple handlers per
> >> command, it simply stop after the first handler writing so
Norman Maurer wrote:
2) Split currently provided command handlers into multiple command
handlers: the current handler already support multiple handlers per
command, it simply stop after the first handler writing something as
response.
Yes that seems a good point. So we can write "diffrent Han
Venkataraman, Narendra wrote:
Regarding moving message handler code to DATACmdHandler code would make
the architecture inflexible, if somebody wants
to develop their own Custom Datahandler and still reuse some of the
message handlers.
Well, now you can overwrite the DataCmdHandler with a DataCm
: Friday, April 21, 2006 5:30 PM
To: James Developers List
Subject: Re: Fast-fail / Handlerchain change proposal
Am Freitag, den 21.04.2006, 13:27 +0200 schrieb Stefano Bagnara:
> Hi all,
>
> I would like to change something in the current handlerchain code
> (formerly known as fastfail c
Am Freitag, den 21.04.2006, 13:27 +0200 schrieb Stefano Bagnara:
> Hi all,
>
> I would like to change something in the current handlerchain code
> (formerly known as fastfail code).
>
> 1) Move some code from the SMTPHandler to the DataCmdHandler. I think
> that the MessageHandler stuff (onMess
On 8/18/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Hi Anagha,
>
> I thought about a MatcherMessageHandler.
> This handler would take a standard james matcher configuration as an
> argument and an additional configuration could say how to reply based on the
> result of the matcher.
> E.g:
>
Ahmed Mohombe wrote:
> Sent: 18 August 2005 09:03
> To: server-dev@james.apache.org
> Subject: Re: Status Update - James Fast Fail
>
>
> > Noel,
> > The reason I though of it was to let people get binaries
> with the SoC stuff
> > in it.
> > That might g
Hi Anagha,
I thought about a MatcherMessageHandler.
This handler would take a standard james matcher configuration as an
argument and an additional configuration could say how to reply based on the
result of the matcher.
E.g:
What do you think?
Could it be of any use?
Would it be be
> > > Does Gump publish "nightlies" for James?
>
> > it would be cool to have nighly published somewhere
> ? now that we have gump working again :-)
>
> Absolutely not! GUMP is explicitly an untrusted system that
> is not permitted to export artifacts other than text reports.
>
> We can, if th
Noel,
The reason I though of it was to let people get binaries with the SoC stuff
in it.
That might get us a bigger pool of testers than making people use svn
would.
+ 1.
And it will avoid the situation where what users check out, does not
compile. (I suppose the nightly builds should compile at
|
| To: "James Developers List"
|
| cc:
|
|
> > Does Gump publish "nightlies" for James?
> it would be cool to have nighly published somewhere
? now that we have gump working again :-)
Absolutely not! GUMP is explicitly an untrusted system that is not
permitted to export artifacts other than text reports.
We can, if there is sufficient r
On 8/17/05, Danny Angus <[EMAIL PROTECTED]> wrote:
>
> > I think it's better to have this committed and
> > changes between versions in svn
>
> +1 this is what we agreed with the students.
>
> Anagha:
> Now just submit incremental patches, you're doing a great job.
> Sorry I don't have time to p
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I think it's better to have this committed and changes between versions in
> svn than having only patches in JIRA so I merged and applied the patch. I
> tested the code and it seems to work: we could always revert later if
> needed.
>
> Anag
> Everyone:
> Does Gump publish "nightlies" for James?
I asked the same a few days ago: it would be cool to have nighly published
somewhere now that we have gump working again :-)
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTEC
> I think it's better to have this committed and
> changes between versions in svn
+1 this is what we agreed with the students.
Anagha:
Now just submit incremental patches, you're doing a great job.
Sorry I don't have time to pay closer attention!
If you want people to test it, post to this list
I think it's better to have this committed and changes between versions in
svn than having only patches in JIRA so I merged and applied the patch. I
tested the code and it seems to work: we could always revert later if
needed.
Anagha: can you add a check while loading the configuration that will a
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> My personal opinion about this security issue is that handler writers are
> developers. They got an interface and should use it. If they cast to the
> real class we can't grant them it will work but I don't see any problem in
> doing that.
>
> [..]
> None of the commandhandlers throw exception except doAuth().
> Even the doData also handles the exception internally I was
> also planning to make onCommand throw exception. If so should
> it should the generic Exception. Should I throw the base
> class Exception?
You are right.
Proba
stefano, thanks for the feedback. find my responses inline
-- Anagha
On 8/17/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> A few notes/questions from a first review:
>
> 1) Your tipical onCommand implementation is:
>
>public void onCommand(SMTPSession session) {
>//deviation from
A few notes/questions from a first review:
1) Your tipical onCommand implementation is:
public void onCommand(SMTPSession session) {
//deviation from the Main code
//Instead of throwing exception just end the session
try{
doAUTH(session, session.getCommandA
oops!
I have created a new patch that has all newly added the files
http://issues.apache.org/jira/secure/attachment/12311785/16Aug2005JAMESFastFail.patch
--anagha
On 8/16/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > I have submitted the patch to JIRA. This is initial version.
> > I hav
> I have submitted the patch to JIRA. This is initial version.
> I have done basic testing to check that code doesnot break anything.
> i will continue to test and will provide next version based
> on the comments from you guys.
>
> http://issues.apache.org/jira/browse/JAMES-407
>
> Download th
I have submitted the patch to JIRA. This is initial version.
I have done basic testing to check that code doesnot break anything.
i will continue to test and will provide next version based on the
comments from you guys.
http://issues.apache.org/jira/browse/JAMES-407
Download the patch from
http
Yes, official answer is to submit a patch, we'll review it and commit it.
On 10/08/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Right now I am testing thoroughly. I can provide this first
> > version of the code for review this weekend. How can I check
> > in the code as I dont have priveleg
thanks stefano.
also can you give me a quick feedback on the changes i mentioned.
--anagha
On 8/10/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > Right now I am testing thoroughly. I can provide this first
> > version of the code for review this weekend. How can I check
> > in the code as I d
> Right now I am testing thoroughly. I can provide this first
> version of the code for review this weekend. How can I check
> in the code as I dont have priveleges?
You should wait an "official" answer from Danny or Noel...
IMHO, the best thing you can do is to create a patch against the curr
I have checked out from the trunk and ported all the Commandhandlers.
There are calls mapping to old code so that latest code (changed since
i checked out) can be ported easily. By mappings what I mean is To
port 'state' variable, I added getSessionState() method to
SMTPSession.
This was not par
On 03/08/05, Anagha Mudigonda <[EMAIL PROTECTED]> wrote:
> Makes sense. Sounds a like better approach.
> Since CommandHandlers need to be thread safe, I will make the calls
> re-entrant by passing SMTPSession object with every call.
...
> Did I get it right?
Yeah, I think so.
d.
-
OK!
This is good for me.
Stefano
> The commandHandlers would not store any state and hence there
> is no need for synchronization.
>
> The logic would now be something like this.
>
> At startup, all CommandHandlers are loaded. The
> CommandHandler Map is filled with CommandName as key and
On 8/3/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > I am thinking of having one set of SMTPSession and all the
> > CommandHandler objects created and configured at the start up
> > in SMTPServer. These will cloned and handed over whenever
> > SMTP session objects are needed for the actual pro
> I am thinking of having one set of SMTPSession and all the
> CommandHandler objects created and configured at the start up
> in SMTPServer. These will cloned and handed over whenever
> SMTP session objects are needed for the actual protocol session.
>
> Would like to know if there is a better
While I was refactoring, I have encountered the following problem.
Every Commandhandler will have specific configuration. It is best parsed by
the Command handler implementation itself.
Since JAMES already uses the Avalon framework's configuration class
for XML parsing, I have used the same.
i
> > design I proposed.
>
> I think most of fast fail code should not *depend* on (the transport) MINA
> (while I would like to have a mina based smtp handler).
> But I'm for code reuse and for modularity, and Mike already started a good
> MINA based smtp implementation p
> Hi all,
>
> Since there is no clearly consensus as to whether JAMES
> should be rearchitected around MINA, I am implementing the
> design I proposed.
I think most of fast fail code should not *depend* on (the transport) MINA
(while I would like to have a mina based smtp handle
|
| cc:
|
| Subjec
Hi all,
Since there is no clearly consensus as to whether JAMES should be
rearchitected around MINA, I am implementing the design I proposed.
Currently I am working on the latest stable release 2.2.0. Do you
suggest I take a later release?
~Anagha
-
Hello,
I am Anagha Mudigonda, Graduate Student Polytechnic
University New York.
I shall be implementing In-Protocol framework and Fast
FAIL as a part of Google SOC and
subsequent to that I am willing to own the in-protocol
handler framework.
Here is the design I am convinced with after 3
Hi,
I have been actively following the Fast fail design
discussions.
I was wondering if it may be necessary to configure
rule as the following:
If MAIL FROM validation passed SPF then no need to
Validate RCPT TO
If MAIL FROM, RCPT TO Passed then no need to validate
DATA
We not only need session
olutions might favor
doing a simple check in-protocol, and then a more robust check for messages
that make it into pipeline. But either my or Danny's fast-fail proposal
should allow this to be administratively configured.
--- Noel
> > > D. SMTP "DATA":
> > > D1. add antivirus/antispam and other content filters and provide
> > > dedicated failure feedback.
>
> > I don't see much benefit to fast-failing after we've
> already accepted
> > the full message
>
> The big win here is not for us, but for the rest of the
> Inte
Serge observed:
> > D. SMTP "DATA":
> > D1. add antivirus/antispam and other content filters
> > and provide dedicated failure feedback.
> I don't see much benefit to fast-failing after we've already
> accepted the full message
The big win here is not for us, but for the rest of the Internet.
ol handling layer will be easier.
I will resubmit my proposal again later.
As I said in my proposal footnotes I don't have time to work on fast-fail
right now: I'm working on DSN and RemoteDelivery optimisations. I tried to
discuss with dev mailing list members about my DSN changes wit
more
hard-coding of behaviour.
I am interested in maintaining James' ability to evolve to cope with
changing requirements and changing standards.
To that end I am proposing that your SMTP rules be implemented in a
way that allows them to have only one responsibility.
> > > Ok, I think
> > I think the API you are suggesting (or better the pattern) is good but I
> > also think that Mike already got working code with a similar pattern: we
> > should wait for his code commit/proposal.
>
> Mike said:
>
> "in spite of the fact that I brought up a similar idea to Noel's on the
> lis
problem at an higher level.
> > Ok, I think your API proposal should not belong to the fast-fail
> > domain: the topic of this thread is Fast-fail proposal.
>
> Which is what I'm proposing. An Architecture for the
> implementation of fast-fail rules in James.
esigned
> protocol handler but we don't need an API: we just need to implement this
> pattern in our protocol handlers.
Without an API we limit ourselves to the issues currently under discussion.
>
> We were discussing about Fast-fail handling: IMHO fast-fail handling API is
>
be portable to other SMTP servers.
>
> I am proposing an API for extending James.
IMHO this is a good architecture to be used to have a better designed
protocol handler but we don't need an API: we just need to implement this
pattern in our protocol handlers.
We were discussing about
On 13/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 1/ *is* the API and 2/ is implementations used to satisfy
> > the use-cases.
>
> I don't agree on this. Most users will need to implement custom code on the
> real use-case (2/).
Actually most users won't.
Some users may want to.
Some
> > > 1/ modify the protocol handling architecture to provide the
> > > _generic_ ability to assemble command handlers
> > >
> > > 2/ develop specific deployments of handers to satisfy the
> use cases.
> > > (and tests of course, before anyone else says it).
>
> > I think that they are 2 needed
On 13/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 1/ modify the protocol handling architecture to provide the
> > _generic_ ability to assemble command handlers
> >
> > 2/ develop specific deployments of handers to satisfy the use
> > cases. (and tests of course, before anyone else say
> I understand why you are keen to work from use-cases.
> But I still strongly favour an approach which will..
>
> 1/ modify the protocol handling architecture to provide the
> _generic_ ability to assemble command handlers
>
> 2/ develop specific deployments of handers to satisfy the use
> cas
|
| cc:
I am totally swamped right now, which is why I had tried to get this kicked
off before getting on the road. I've continued to give a lot of thought to
fast-fail, and have read the messages. I just haven't had time to respond.
We're probably not really all that far apart. I&#x
--
Here is the updated list of useful fast-fail scenarios. In the bottom you
will find my first proposal.
--
A. SMTP connection: james currently always reply "220 server ready", we
could fast-fail based on:
A1. remote address
A2. cur
--
Here is the updated list of useful fast-fail scenarios. In the bottom you
will find my first proposal.
--
A. SMTP connection: james currently always reply "220 server ready", we
could fast-fail based on:
A1. remote address
A2. cur
> No,
> a) if you specify "required" the internal servers will also
> need to execute STARTTLS
> b) if you specify "enabled" the external servers can relay
> without doing STARTTLS
No,
If you specify "enabled" then a server is able to run STARTTLS.
Relay check can only be done after the RCPT TO
> No,
> a) if you specify "required" the internal servers will also
> need to execute STARTTLS
> b) if you specify "enabled" the external servers can relay
> without doing STARTTLS
No,
If you specify "enabled" then a server is able to run STARTTLS.
Relay check can only be done after the RCPT TO
On Wednesday 11 May 2005 09:49, [EMAIL PROTECTED] wrote:
> > Consider that some servers relay though James from an
> > internal trusted network, they do not need to issue STARTTLS,
> > others however are relaying through a public network an are
> > thus required to issue STARTTLS (perhaps even with
> Consider that some servers relay though James from an
> internal trusted network, they do not need to issue STARTTLS,
> others however are relaying through a public network an are
> thus required to issue STARTTLS (perhaps even with
> client-certificate authentication).
> So we do not disable
> Consider that some servers relay though James from an
> internal trusted network, they do not need to issue STARTTLS,
> others however are relaying through a public network an are
> thus required to issue STARTTLS (perhaps even with
> client-certificate authentication).
> So we do not disable
On Tuesday 10 May 2005 18:59, [EMAIL PROTECTED] wrote:
> > 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:
>
> 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 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
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:
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:
filters to the incoming mail. This is
currently done in an asynchronous way and someone would prefer to have an
immediate reply for a subset of problems.
When the SMTP handler receive the "\r\n.\r\n" after a DATA command then it
calls "theConfigData.getMailServer().sendMail(mail);&q
filters to the incoming mail. This is
currently done in an asynchronous way and someone would prefer to have an
immediate reply for a subset of problems.
When the SMTP handler receive the "\r\n.\r\n" after a DATA command then it
calls "theConfigData.getMailServer().sendMail(mail);&q
derstand your solution:
Let's say we have a james configured with many processors and many
matcher/mailets that provide specific
aliasing/forwarding/virtusertable/localdelivery. If we want to add fast-fail
per recipient then we need to create a tree of SMTPHandler plugins that
provides fun
derstand your solution:
Let's say we have a james configured with many processors and many
matcher/mailets that provide specific
aliasing/forwarding/virtusertable/localdelivery. If we want to add fast-fail
per recipient then we need to create a tree of SMTPHandler plugins that
provides fun
> 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
rrorcodes instead of bounces).
>
> I think you're confusing two things here.
>
> 1/ "fast fail" should examine the envelope and the messages
> as they are streamed and respon with an SMTP reponse code
>
> 2/ asynchronous message processing/routeing, which sho
1 - 100 of 117 matches
Mail list logo
