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 Sat, 04 Jan 2003 19:13:07 GMT
OK, I will do it.

Sergei
----- Original Message -----
From: "Danny Angus" <danny@apache.org>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Saturday, January 04, 2003 8:02 PM
Subject: RE: [Proposal] FetchPOP configuration change


> Feel free to, I have almost no time free at the moment.
> I didn't "want to" do it but felt I should, as I am the perpetrator of the
> bug :-)
>
> d.
>
> > -----Original Message-----
> > From: Serge Sozonoff [mailto:serge@globalbeach.com]
> > Sent: 04 January 2003 16:32
> > To: James Developers List
> > Subject: Re: [Proposal] FetchPOP configuration change
> >
> >
> > Danny,
> >
> > My understanding is that you wanted to make these changes. If that is
not
> > the case, I will be happy to do it.
> > Please confirm.
> >
> > Sergei
> >
> >
> > ----- Original Message -----
> > From: "Noel J. Bergman" <noel@devtech.com>
> > To: "James Developers List" <james-dev@jakarta.apache.org>
> > Sent: Saturday, January 04, 2003 2:44 PM
> > Subject: RE: [Proposal] FetchPOP configuration change
> >
> >
> > > Sergei,
> > >
> > > Document the behavior.  If you want to say that there is an optional
> > > <ignoreRCPT-TO> parameter, I don't see it as a problem, but document
the
> > > entire behavior of how FetchPOP decides to what address an
> > fetched e-mail
> > > should go.
> > >
> > > --- Noel
> > >
> > > -----Original Message-----
> > > From: Serge Sozonoff [mailto:serge@globalbeach.com]
> > > Sent: Saturday, January 04, 2003 5:56
> > > To: James Developers List
> > > Subject: Re: [Proposal] FetchPOP configuration change
> > >
> > >
> > > Hi Noel,
> > >
> > > >   1. Enhance FetchPOP to use the Received header.
> > > >   2. Add an address field to the configuration to
> > > >      be used if the Received header does not have
> > > >      a valid address.
> > >
> > > Sorry to drag this on a bit, I agree with the above but I also see a
> > benefit
> > > in being able to override point 1. so that the address field
> > from point 2.
> > > is always used. In my mind this make the behavior very clear
> > and specific.
> > > Get mail using POP from account X and put it into account Y.
> > >
> > > Isn't this a one to one mapping. i.e. We are fetching mail from
> > a specific
> > > user account using POP and injecting into another user account in
JAMES.
> > >
> > > I guess I can think of a scenario which makes sense for point 1.
> > > If a single remote account is gathering mail for several users
> > and we want
> > > to FetchPOP from that account and have those emails re-distributed in
> > James
> > > to there respective recipients. Does anyone actually do this?
> > >
> > > My 2 cents,
> > > Sergei
> > >
> > >
> > > ----- Original Message -----
> > > From: "Noel J. Bergman" <noel@devtech.com>
> > > To: "James Developers List" <james-dev@jakarta.apache.org>
> > > Sent: Friday, January 03, 2003 8:06 PM
> > > Subject: RE: [Proposal] FetchPOP configuration change
> > >
> > >
> > > > Sergei,
> > > >
> > > > That is what I asked about the Received header.  It didn't
> > appear to be
> > a
> > > > guarantee, and relying upon the other address headers looks like an
> > > > opportunity for addressing errors.
> > > >
> > > > It sounds as if the current proposal becomes:
> > > >
> > > >   1. Enhance FetchPOP to use the Received header.
> > > >   2. Add an address field to the configuration to
> > > >      be used if the Received header does not have
> > > >      a valid address.
> > > >
> > > > Is that your understanding?
> > > >
> > > > --- Noel
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:james-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:james-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:james-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<mailto:james-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:james-dev-help@jakarta.apache.org>
>
>


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


Mime
View raw message