james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Sozonoff" <se...@globalbeach.com>
Subject Re: [Proposal] FetchPOP configuration change
Date Thu, 02 Jan 2003 18:44:35 GMT

OK, but I am not sure that what Danny has suggested is the best way to do it
or then I am just missing something all together here.

Do we agree that using the received address option you are discussing will
never work unless

a. The JAMES server is setup to handle the exact same email address as the
server we just FetchPop'ed the email from
b. The JAMES server has a matcher to catch emails for the original recipient
and then redirect/forward or whatever.

I can see two things here.

I am not sure why anyone would do case a. unless maybe they were doing some
fancy migration or something..

Assuming that a. is not fulfilled, it is a pain and bloats the config file
if for each FetchPOP block he also has to add a Matcher i.e. FetchFrom to
catch the recipient.
Why not just specify in the config block for FetchPOP what the new recipient
is and if someone wants to do something fancier they can still use a

Sorry if I am completely off here.


----- Original Message -----
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Thursday, January 02, 2003 6:56 PM
Subject: RE: [Proposal] FetchPOP configuration change

> > I could give this a go if you are able to clarify a little.
> Please don't.  LOL  Actually, look at the exchange between Danny and
> If you want to work on FetchPOP, look at parsing the Received header, and
> use that for the address.
> > The goal of this being so that you can "forward/send" this mail to a
> totally
> > different user under JAMES?
> No, the idea (as Danny picked up) was simply to be able to send to the
> used by the original SMTP transaction, not the name in the TO field.
> > Wrap a Mail object around the mimemessage?
> Mail objects are the transports we use internally.  The MimeMessage should
> be unchanged except fro the addition of the X- header already in the code,
> which could be replaced with a mail attribute in v3, unless the intent is

> for that to be sent on to other servers or the final client.
> --- Noel
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message