You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Mike Dougherty <mi...@mogiv.com> on 2010/04/06 21:48:46 UTC

Configuration questions

Hey all,

I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.

The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this.

1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application.
2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit.
3. If James can be configured to use wildcards (i.e. accept *@mydomain.com) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository).

#3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet.

The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter?

The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution.


Thanks for you thoughts or comments.
Mike



**********************************
 Mike Dougherty
 858.232.3635
 miked@mogiv.com
 Mogiv, Inc.
 http://www.mogiv.com
**********************************




---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: Configuration questions

Posted by Mike Dougherty <mi...@mogiv.com>.
Hey Norman, 

Thanks again for your response. We are suppose to start accepting incoming email later this month. But are not due to be in production for a few more months. 

I'll take a look at your options and ideas and see what I can come up with. 

Thanks,
Mike


On Apr 7, 2010, at 9:54 PM, Norman Maurer wrote:

> Hi Mike,
> 
> chaining UsersRepositories is not supported out of the box. But it
> should be easy to implement it by yourself with a UserRepository
> implementation which acts as "proxy" and just "query" the
> implementions you want to use..
> 
> About the error processing, it depends..
> 
> First off, when do you expect to complete your app (when it goes to
> production) ? I think I would use james trunk in any case but your
> view might be a bit different. Current trunk uses camel for calling
> the actual Mailets so its a bit more flexible in terms of Exception
> handling etc.
> 
> A solution which should work with both james version is to set the
> "state" of the Mail object to an extra processor. In the processor
> your put the Mail in some kind of MailRepository (or something else
> which is developed by you). Then you write a RetryMailDelivery Service
> which will fire of the Mails (which was stored before) again.
> 
> If you want some more details on how things could work out, just ask..
> 
> Bye,
> Norman
> 
> 2010/4/7 Mike Dougherty <mi...@mogiv.com>:
>> Hey Norman,
>> 
>> Thanks for your response. Yeah, I think a UsersRepository would be a good way to go. Can I chain repositories? For example, first check the VirtualUsersRepository then check MyCustomUsersRepository, if both fail to find user, bounce message?
>> 
>> My application is just using the MimeMessage for its processing. I've built a quick and dirty Mailet, which seems to be getting the job done. However, one thing I have yet to figure out is how to handle error conditions. Most notable, if the Mailet cannot access my apps web service, I would like to queue the message for later processing (when the service becomes available again). I'm digging into the docs on how to accomplish this, but if you have some pointers I am open to suggestions.
>> 
>> 
>> Thanks,
>> Mike
>> 
>> 
>> On Apr 7, 2010, at 12:30 AM, Norman Maurer wrote:
>> 
>>> Hi Mike,
>>> 
>>> comments are inside..
>>> 
>>> 2010/4/6 Mike Dougherty <mi...@mogiv.com>:
>>>> Hey all,
>>>> 
>>>> I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.
>>>> 
>>>> The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this.
>>>> 
>>>> 1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application.
>>>> 2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit.
>>> 
>>> What about writing a custom UsersRepository implementation ? So JAMES
>>> would lookup users directly "via your app" ?
>>> 
>>>> 3. If James can be configured to use wildcards (i.e. accept *@mydomain.com) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository).
>>> 
>>> Possible without problems
>>> 
>>>> 
>>>> #3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet.
>>>> 
>>> 
>>> See comments on 2, 3 ;)
>>> 
>>>> The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter?
>>> 
>>> This depends a bit on your need. What kind of stuff you need to
>>> forward to your app ? The Mail object, the MimeMessage or just some
>>> meta info ?
>>> 
>>>> 
>>>> The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution.
>>>> 
>>>> 
>>>> Thanks for you thoughts or comments.
>>>> Mike
>>>> 
>>>> 
>>>> 
>>>> **********************************
>>>>  Mike Dougherty
>>>>  858.232.3635
>>>>  miked@mogiv.com
>>>>  Mogiv, Inc.
>>>>  http://www.mogiv.com
>>>> **********************************
>>>> 
>>>> 
>>>> 
>>> 
>>> Bye,
>>> Norman
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>> 
>> 
>> **********************************
>>  Mike Dougherty
>>  858.232.3635
>>  miked@mogiv.com
>>  Mogiv, Inc.
>>  http://www.mogiv.com
>> **********************************
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 

**********************************
 Mike Dougherty
 858.232.3635
 miked@mogiv.com
 Mogiv, Inc.
 http://www.mogiv.com
**********************************




---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: Configuration questions

Posted by Norman Maurer <no...@googlemail.com>.
Hi Mike,

chaining UsersRepositories is not supported out of the box. But it
should be easy to implement it by yourself with a UserRepository
implementation which acts as "proxy" and just "query" the
implementions you want to use..

About the error processing, it depends..

First off, when do you expect to complete your app (when it goes to
production) ? I think I would use james trunk in any case but your
view might be a bit different. Current trunk uses camel for calling
the actual Mailets so its a bit more flexible in terms of Exception
handling etc.

A solution which should work with both james version is to set the
"state" of the Mail object to an extra processor. In the processor
your put the Mail in some kind of MailRepository (or something else
which is developed by you). Then you write a RetryMailDelivery Service
which will fire of the Mails (which was stored before) again.

If you want some more details on how things could work out, just ask..

Bye,
Norman

2010/4/7 Mike Dougherty <mi...@mogiv.com>:
> Hey Norman,
>
> Thanks for your response. Yeah, I think a UsersRepository would be a good way to go. Can I chain repositories? For example, first check the VirtualUsersRepository then check MyCustomUsersRepository, if both fail to find user, bounce message?
>
> My application is just using the MimeMessage for its processing. I've built a quick and dirty Mailet, which seems to be getting the job done. However, one thing I have yet to figure out is how to handle error conditions. Most notable, if the Mailet cannot access my apps web service, I would like to queue the message for later processing (when the service becomes available again). I'm digging into the docs on how to accomplish this, but if you have some pointers I am open to suggestions.
>
>
> Thanks,
> Mike
>
>
> On Apr 7, 2010, at 12:30 AM, Norman Maurer wrote:
>
>> Hi Mike,
>>
>> comments are inside..
>>
>> 2010/4/6 Mike Dougherty <mi...@mogiv.com>:
>>> Hey all,
>>>
>>> I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.
>>>
>>> The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this.
>>>
>>> 1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application.
>>> 2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit.
>>
>> What about writing a custom UsersRepository implementation ? So JAMES
>> would lookup users directly "via your app" ?
>>
>>> 3. If James can be configured to use wildcards (i.e. accept *@mydomain.com) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository).
>>
>> Possible without problems
>>
>>>
>>> #3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet.
>>>
>>
>> See comments on 2, 3 ;)
>>
>>> The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter?
>>
>> This depends a bit on your need. What kind of stuff you need to
>> forward to your app ? The Mail object, the MimeMessage or just some
>> meta info ?
>>
>>>
>>> The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution.
>>>
>>>
>>> Thanks for you thoughts or comments.
>>> Mike
>>>
>>>
>>>
>>> **********************************
>>>  Mike Dougherty
>>>  858.232.3635
>>>  miked@mogiv.com
>>>  Mogiv, Inc.
>>>  http://www.mogiv.com
>>> **********************************
>>>
>>>
>>>
>>
>> Bye,
>> Norman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>
> **********************************
>  Mike Dougherty
>  858.232.3635
>  miked@mogiv.com
>  Mogiv, Inc.
>  http://www.mogiv.com
> **********************************
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: Configuration questions

Posted by Mike Dougherty <mi...@mogiv.com>.
Hey Norman,

Thanks for your response. Yeah, I think a UsersRepository would be a good way to go. Can I chain repositories? For example, first check the VirtualUsersRepository then check MyCustomUsersRepository, if both fail to find user, bounce message? 

My application is just using the MimeMessage for its processing. I've built a quick and dirty Mailet, which seems to be getting the job done. However, one thing I have yet to figure out is how to handle error conditions. Most notable, if the Mailet cannot access my apps web service, I would like to queue the message for later processing (when the service becomes available again). I'm digging into the docs on how to accomplish this, but if you have some pointers I am open to suggestions.


Thanks,
Mike


On Apr 7, 2010, at 12:30 AM, Norman Maurer wrote:

> Hi Mike,
> 
> comments are inside..
> 
> 2010/4/6 Mike Dougherty <mi...@mogiv.com>:
>> Hey all,
>> 
>> I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.
>> 
>> The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this.
>> 
>> 1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application.
>> 2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit.
> 
> What about writing a custom UsersRepository implementation ? So JAMES
> would lookup users directly "via your app" ?
> 
>> 3. If James can be configured to use wildcards (i.e. accept *@mydomain.com) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository).
> 
> Possible without problems
> 
>> 
>> #3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet.
>> 
> 
> See comments on 2, 3 ;)
> 
>> The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter?
> 
> This depends a bit on your need. What kind of stuff you need to
> forward to your app ? The Mail object, the MimeMessage or just some
> meta info ?
> 
>> 
>> The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution.
>> 
>> 
>> Thanks for you thoughts or comments.
>> Mike
>> 
>> 
>> 
>> **********************************
>>  Mike Dougherty
>>  858.232.3635
>>  miked@mogiv.com
>>  Mogiv, Inc.
>>  http://www.mogiv.com
>> **********************************
>> 
>> 
>> 
> 
> Bye,
> Norman
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
> 

**********************************
 Mike Dougherty
 858.232.3635
 miked@mogiv.com
 Mogiv, Inc.
 http://www.mogiv.com
**********************************




---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org


Re: Configuration questions

Posted by Norman Maurer <no...@googlemail.com>.
Hi Mike,

comments are inside..

2010/4/6 Mike Dougherty <mi...@mogiv.com>:
> Hey all,
>
> I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.
>
> The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this.
>
> 1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application.
> 2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit.

What about writing a custom UsersRepository implementation ? So JAMES
would lookup users directly "via your app" ?

> 3. If James can be configured to use wildcards (i.e. accept *@mydomain.com) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository).

Possible without problems

>
> #3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet.
>

See comments on 2, 3 ;)

> The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter?

This depends a bit on your need. What kind of stuff you need to
forward to your app ? The Mail object, the MimeMessage or just some
meta info ?

>
> The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution.
>
>
> Thanks for you thoughts or comments.
> Mike
>
>
>
> **********************************
>  Mike Dougherty
>  858.232.3635
>  miked@mogiv.com
>  Mogiv, Inc.
>  http://www.mogiv.com
> **********************************
>
>
>

Bye,
Norman

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org