https://issues.apache.org/jira/browse/JAMES-1030



--------------------------------------------------
From: "Norman Maurer" <[email protected]>
Sent: Monday, July 26, 2010 5:26 PM
To: "James Users List" <[email protected]>
Subject: Re: email sending status

Good point,

could you create a jira issue for it ?

Bye,
Norman

2010/7/26 冉兵 <[email protected]>:
one more thing:

The error code returned from the ValidEcptHandler is 554 for invalid local
user. Should it be 550 to be more specific?


--------------------------------------------------
From: "冉兵" <[email protected]>
Sent: Monday, July 26, 2010 5:11 PM
To: "James Users List" <[email protected]>
Subject: Re: email sending status

Hi Norman,

I just noticed the smtp handler chain config file and realized that I have
been using James SMTP without much protection from spamming.

I see the ValidRcptHandler sample config and I'll try enabling that.

But in larger picture, what are the recommended handlers one should be
using in a production server?

Help is appreciated!

Bing



--------------------------------------------------
From: "Norman Maurer" <[email protected]>
Sent: Sunday, July 25, 2010 1:28 AM
To: "James Users List" <[email protected]>
Subject: Re: email sending status

Hi Bing,

the RemoteDelivery idea is good. Maybe we could even add some kind of
listener to RemoteDelivery which will get triggered on success,perm
errror and temp error. WDYT ?

About the recipient check, In current trunk there is the
ValidRcptHandler which will take care of rejecting non existing users
in the smtp dialog. We made it configurable because sometimes you want
to really accept every email ( for example when building a spamtrap).

Bye,
Norman


2010/7/24 冉兵 <[email protected]>:

Exactly.

I am thinking embedding some code similar to RemoteDelivery in my web
app to
talk to remote SMTP server responsible for the customer's . Would it be
a
viable approach?

BTW, I just found that James did not verify the existence of the local
accounts in the SMTP service until later in the delivery pipe. The
result is
that the SMTP always takes any incoming emails. It seems to better "fail
right away". What do you think?


Thanks

Bing

--------------------------------------------------
From: "Norman Maurer" <[email protected]>
Sent: Saturday, July 24, 2010 2:01 AM
To: "James Users List" <[email protected]>
Subject: Re: email sending status

Hi Bing,

could you explain in bit more ? You need to tell your clients if the
email is still in the queue,bounced or sent ?

Bye,
Norman


2010/7/23 冉兵 <[email protected]>:

Hi again,

My hacking with James continues.

This time I'd like to build a service to James for SMTP clients to
query
for the status of previous SMTP requests. The use case is email
verification
at customer registration. I'd like to give customer concrete feedback
as to
the status of sending the verification email: sent successfully, bad
domain,
bad account, etc. Since SMTP is a asynchronous process, I'm thinking
building a service that the sender side can poll for the status of
previous
jobs.

Anything already built in? Any ideas how to implement this? Always
appreciate it!

Bing






---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to