You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/11/14 20:41:28 UTC

RE: JDBCVirtualUser for multiple users

Craig,

I'd like to see this added to the VirtualUserTable code.  Better still, I'd
like to see the code refactored into AbstractVirtualUserTable, having the
code for virtual user table behavior, and JDBCVirtualUserTable, having the
code for fetching the virtual user table map from the database.  That will
allow someone to write a file-based virtual user table, too.

Robert Cadena had done similar code, but it was only on his site, and he
seems to have disappeared along with the site contents.

Please do submit the patch.  :-)  Please note that we should not assume that
the mapping will contain a list of addresses.  It could include something
else, e.g., a DSN error code and message.  There are a few people, including
yourself, who've talked about submitting an RFC 1894 contribution, so
hopefully we'll have one soon.

	--- Noel

-----Original Message-----
From: Craig Raw [mailto:craig@quirk.co.za]
Sent: Monday, October 20, 2003 8:29
To: James Developers List
Subject: JDBCVirtualUser for multiple users


Hi,

This is a proposal on the same topic as the mailing list entry from 1 back,
'Multiple Recipient Aliases'
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-user@jakarta.apac
he.org&msgNo=3594). It concerns using the JDBCVirtualUserTable to forward an
incoming email to more than one user. Of course, this is already possible
with the Redirect mailet, but keeping all these details in the
VirtualUserTable is cleaner IMO.

I'd like to propose that the target_address column of VirtualUserTable be
allowed to contain users or email addresses separated by commas. The mailet
simply spilts this column up into its constituents and redirects to all of
them. I've already written such a mailet and got it working, and I think
this might be a nice standard feature of the JDBCVirtualUserTable, as it is
backwards compatible. Of course, I may have missed a better solution in the
intervening year.

I can get a patch together if necessary.

Craig





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


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


Re: JDBCVirtualUser for multiple users

Posted by Craig Raw <cr...@quirk.co.za>.
Hi Noel,

Thanks for your reply :) I'll be happy to submit the patch, with all 
your good ideas in mind.

Regarding RFC 1894, the last time we discussed it Serge pointed out the 
problems with extracting error messages from the Javamail API (more 
specifically MessagingException). As you point out though, in the case 
of the VirtualUserTable, we have a chance to do it reliably. I'd suggest 
a class with the responsibility to produce a RFC 1894 formatted message 
given a DSN code and message. That way, it could be used again when more 
standardised error reporting comes to Javamail (or its replacement). I'd 
appreciate some input on the soundness of this idea, and where it might 
fit into the codebase.

Craig

Noel J. Bergman wrote:
> Craig,
> 
> I'd like to see this added to the VirtualUserTable code.  Better still, I'd
> like to see the code refactored into AbstractVirtualUserTable, having the
> code for virtual user table behavior, and JDBCVirtualUserTable, having the
> code for fetching the virtual user table map from the database.  That will
> allow someone to write a file-based virtual user table, too.
> 
> Robert Cadena had done similar code, but it was only on his site, and he
> seems to have disappeared along with the site contents.
> 
> Please do submit the patch.  :-)  Please note that we should not assume that
> the mapping will contain a list of addresses.  It could include something
> else, e.g., a DSN error code and message.  There are a few people, including
> yourself, who've talked about submitting an RFC 1894 contribution, so
> hopefully we'll have one soon.
> 
> 	--- Noel
> 
> -----Original Message-----
> From: Craig Raw [mailto:craig@quirk.co.za]
> Sent: Monday, October 20, 2003 8:29
> To: James Developers List
> Subject: JDBCVirtualUser for multiple users
> 
> 
> Hi,
> 
> This is a proposal on the same topic as the mailing list entry from 1 back,
> 'Multiple Recipient Aliases'
> (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-user@jakarta.apac
> he.org&msgNo=3594). It concerns using the JDBCVirtualUserTable to forward an
> incoming email to more than one user. Of course, this is already possible
> with the Redirect mailet, but keeping all these details in the
> VirtualUserTable is cleaner IMO.
> 
> I'd like to propose that the target_address column of VirtualUserTable be
> allowed to contain users or email addresses separated by commas. The mailet
> simply spilts this column up into its constituents and redirects to all of
> them. I've already written such a mailet and got it working, and I think
> this might be a nice standard feature of the JDBCVirtualUserTable, as it is
> backwards compatible. Of course, I may have missed a better solution in the
> intervening year.
> 
> I can get a patch together if necessary.
> 
> Craig
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 
> 



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