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]>
