Jimmy - lightweight email proxy using subset of James code

[Nitin Borwankar <ni...@borwankar.com>]

Hello James users and Gurus,

I am the owner of the JXTA p2p-email project on www.jxta.org.
I intend to use a subset of James' code ("Jimmy") to create a
redirecting, e-mail proxy and email<->JXTA gateway.
I need help in identifying the relevant files as I don't want a full
fledged SMTP server installation especially
not - message storage, user management ... 

It will work by intercepting all outgoing email from a client.
(The client will be fooled into thinking the proxy is the MTA and the
proxy will forward regular email to the actual MTA.)
Messages meant for transport via JXTA pipes to JXTA endpoints will have
a "jxta:" prefix in the "rfc822-proper" email address.
A mailet will match the prefix and collect all such addresses and hand
off a copy of the msg with JXTA addresses to a JXTA service which will
take it from there.  The mailet will also create another copy of the
message with smtp-based destinations and  
forward to the regular MTA.

Complementary things will happen for incoming messages which will end up
as regular MIME (multipart) documents in the inbox.
The assumption is that they have been sent by a similar facility to the
one described above, and are well formed MIME (multipart) docs, the only
distinguishing factor being that the from: address has a "jxta:" prefix.
They can seamlessly be forwarded to regular email destinations with NO
transformations.

The idea is to leverage existing email client facilities for msg
composition, folder management, directory and addressbook management
(LDAP etc.), account and profile management ... and only plug-in the 5%
of code that is relevant to a new transport, by extending the proxy.
Aside from that 5%, the typical email client is basically a
MIME-document/user account/address book  management facility which
doesn't need to be re-invented.  The mailet scheme could also be
generalized to other protocols than the JXTA re-direction, via
appropriate matching tags.  This will work for async/store and forward
msg-ing but probably unwieldy for things like IM etc.

I have installed the full fledged James and played with it, have read
the user/developer docs especially the mailet stuff, but could use
pointers on how to draw the line between what Java files to keep and
what to leave out so that James may give birth to Jimmy.

So where do I begin ? I am hoping to save some time and pain by using
the collective wisdom on the list.( I know,  get a CVS tree, then what
?)  I am looking for non-obvious dependencies and hidden gotchas,
mostly.

Thanks for taking the time,
 
--
Nitin Borwankar

nitin@borwankar.com
jxnbor@jxta.org

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

Re: Jimmy - lightweight email proxy using subset of James code

[Nitin Borwankar <ni...@borwankar.com>]

Oki DZ wrote:
> 
> On Tue, 2 Oct 2001, Nitin Borwankar wrote:
> > Hello James users and Gurus,
> 
[...] 
> > Complementary things will happen for incoming messages which will end up
> > as regular MIME (multipart) documents in the inbox.
> > The assumption is that they have been sent by a similar facility to the
> > one described above, and are well formed MIME (multipart) docs, the only
> > distinguishing factor being that the from: address has a "jxta:" prefix.
> > They can seamlessly be forwarded to regular email destinations with NO
> > transformations.
> 
> I guess you'd need quite a lot of work here. You can take a look at the
> ToPostmaster mailet I just posted in this list.
> 
> I think James needs a class that can generate mime messages easily; ie:
> create the String for the message texts, have some binary files for
> attachments, and voila, the messages get sent.


Hi Oki,

Thanks for the response.
This above part (MIME message composition) will be done by the email
CLIENT on the sending end, so the James part is only again matching and
re-direction (this time of incoming messages) based on header values.

> 
> ...
> > I have installed the full fledged James and played with it, have read
> > the user/developer docs especially the mailet stuff, but could use
> > pointers on how to draw the line between what Java files to keep and
> > what to leave out so that James may give birth to Jimmy.
> 
> I think what you can keep is the SMTP server.
> 
> > So where do I begin ? I am hoping to save some time and pain by using
> > the collective wisdom on the list.( I know,  get a CVS tree, then what
> > ?)  I am looking for non-obvious dependencies and hidden gotchas,
> > mostly.
> 
> Making sure that you need much more than rinetd (a port forwarder daemon).


Definitely do need the jxta: matcher and as you point out, I do need to
keep the message queue, neither of which I get with a port forwarder,
right ?  Thanks again for the response.

Nitin Borwankar.

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

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

Re: Jimmy - lightweight email proxy using subset of James code

[Oki DZ <ok...@pindad.com>]

On Tue, 2 Oct 2001, Nitin Borwankar wrote:
> Hello James users and Gurus,

Hi,
(but Serge is the Guru)
 
> I am the owner of the JXTA p2p-email project on www.jxta.org.
> I intend to use a subset of James' code ("Jimmy") to create a
> redirecting, e-mail proxy and email<->JXTA gateway.
> I need help in identifying the relevant files as I don't want a full
> fledged SMTP server installation especially
> not - message storage, user management ... 

I think you'd need the message storage.
 
> It will work by intercepting all outgoing email from a client.
> (The client will be fooled into thinking the proxy is the MTA and the
> proxy will forward regular email to the actual MTA.)
> Messages meant for transport via JXTA pipes to JXTA endpoints will have
> a "jxta:" prefix in the "rfc822-proper" email address.
> A mailet will match the prefix and collect all such addresses and hand
> off a copy of the msg with JXTA addresses to a JXTA service which will
> take it from there.  The mailet will also create another copy of the
> message with smtp-based destinations and  
> forward to the regular MTA.

This could be accomplished by using a matcher (for "intercepting") that
detects the "jxta:", and then a mailet for handling what to do with the
messages.

> Complementary things will happen for incoming messages which will end up
> as regular MIME (multipart) documents in the inbox.
> The assumption is that they have been sent by a similar facility to the
> one described above, and are well formed MIME (multipart) docs, the only
> distinguishing factor being that the from: address has a "jxta:" prefix.
> They can seamlessly be forwarded to regular email destinations with NO
> transformations.

I guess you'd need quite a lot of work here. You can take a look at the
ToPostmaster mailet I just posted in this list.

I think James needs a class that can generate mime messages easily; ie:
create the String for the message texts, have some binary files for
attachments, and voila, the messages get sent.
 
...
> I have installed the full fledged James and played with it, have read
> the user/developer docs especially the mailet stuff, but could use
> pointers on how to draw the line between what Java files to keep and
> what to leave out so that James may give birth to Jimmy.

I think what you can keep is the SMTP server.
 
> So where do I begin ? I am hoping to save some time and pain by using
> the collective wisdom on the list.( I know,  get a CVS tree, then what
> ?)  I am looking for non-obvious dependencies and hidden gotchas,
> mostly.

Making sure that you need much more than rinetd (a port forwarder daemon).

Oki



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