OK, I will do it. Sergei ----- Original Message ----- From: "Danny Angus" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > > 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" <[EMAIL PROTECTED]> > > To: "James Developers List" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]] > > > 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" <[EMAIL PROTECTED]> > > > To: "James Developers List" <[EMAIL PROTECTED]> > > > 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:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
