You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Sozonoff <se...@globalbeach.com> on 2003/01/02 15:26:47 UTC
Re: [Proposal] FetchPOP configuration change
Hi Noel,
I could give this a go if you are able to clarify a little.
> primary change is to add the SMTP address to the configuration, so that
> FetchPOP knows to what address to send the mail.
The goal of this being so that you can "forward/send" this mail to a totally
different user under JAMES?
i.e. Wrap a Mail object around the mimemessage?
Serge
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James-Dev Mailing List" <ja...@jakarta.apache.org>
Sent: Tuesday, December 31, 2002 9:05 PM
Subject: [Proposal] FetchPOP configuration change
> I propose that we some changes to the configuration for FetchPOP. The
> primary change is to add the SMTP address to the configuration, so that
> FetchPOP knows to what address to send the mail.
>
> There is a bit more to this, actually. We want to set the Mail object
> recipient to the default address initially, but also want to be able to
run
> the message through a processor so that we can apply matchers and re-set
the
> recipient address according to message headers. The message itself
remains
> unchanged.
>
> Anyone feel like working on FetchPOP? For James v2 we can prototype in
> config.xml, but for James v3 we ought to have all of this in a repository.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by Danny Angus <da...@apache.org>.
Sergei,
> I am still wondering if it is not just easier to add the option in the
> FetchPOP block to say who the fetched mail is for.
As an option, yes I agree. It would simplify the situation in the majority
of cases.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
OK, I will do it.
Sergei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@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" <no...@devtech.com>
> > To: "James Developers List" <ja...@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" <no...@devtech.com>
> > > To: "James Developers List" <ja...@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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I didn't "want to" do it but felt I should, as I am the perpetrator of the
> bug :-)
Nice of you to (a) be willing to take responsibility, and even nicer that
you (b) are willing to let someone else who wants to take the ball and run
with it. :-) It really is vital that we encourage more and more people to
contribute.
When do you expect to have some time to upload your prototype code for v3?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by Danny Angus <da...@apache.org>.
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" <no...@devtech.com>
> To: "James Developers List" <ja...@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" <no...@devtech.com>
> > To: "James Developers List" <ja...@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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
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" <no...@devtech.com>
To: "James Developers List" <ja...@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" <no...@devtech.com>
> To: "James Developers List" <ja...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
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" <no...@devtech.com>
To: "James Developers List" <ja...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by Danny Angus <da...@apache.org>.
> 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.
No only in one use case.
> 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?
Yes its one of the designed aims to support this.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
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" <no...@devtech.com>
To: "James Developers List" <ja...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
-----Original Message-----
From: Serge Sozonoff [mailto:serge@globalbeach.com]
Sent: Friday, January 03, 2003 6:37
To: James Developers List
Subject: Re: [Proposal] FetchPOP configuration change
Hi Danny,
I agree here that information in the Received header is very ify.
The info can be wrong or possibly be missing all together (this breaks
RFC822 but still seems to be done by some firewalls and mail servers)
It also seems that sometimes Firewalls and Relays can remove/change portions
of the Received header to obscure certain information that could be used to
mount an attack.
I found nothing in RFC 822 that says RCPT TO: must be exposed, NOTE that
this translates to the "for" parameter
Quote from RFC 822: "the receiving host may wish to record the original
specification, using the "for" parameter."
The Received header appears once for each relay the mail goes through with
the most recent email server first, and the first mail server that relayed
this email last.
I am still wondering if it is not just easier to add the option in the
FetchPOP block to say who the fetched mail is for.
There seems to be a fair amount of "if's" which in my opinion don't make
things simple and could lead to strange results.
I can already see the questions coming when the FetchPOP behavior is not
understood by someone using JAMES and we
have to explain how we try and decide who the FetchPOP'd mail is for.
Thanks,
Serge or maybe Sergei and then I don't get mixed up with the other Serge :-)
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, January 03, 2003 11:50 AM
Subject: RE: [Proposal] FetchPOP configuration change
> > Is there any concern regarding whether or not the the Received
> > header might
> > not have the proper information?
>
> Yes some, I'm not 100% sure that a "Received" header MUST expose the "RCPT
> TO:" address in a "for" line, nor that this would necessarily be a
> legitimate mail address of any kind.
> Can we reasonably infer that SMTP headers exist simply because mail is
> available for download via POP3?
> If not, we can read the message "To" & "Cc" headers, if this fails to help
> (perhaps it was a bcc) we should catch this in FetchPOP and take some
> default action, perhaps indeed have a default alias for unidentifiable
> fetched mail.
>
> If, sorry _when_ we get mail parameters we can (possibly, if we can have a
> mail object without a recipient) set a parameter to indicate an
unsucessful
> attempt to parse a recipient address, this can be used in the general
> pipeline to filter this mail so that the user controls what happens,
rather
> than have us impose some arbitrary behaviour. I worry about null pointer
(to
> recipients) exceptions in this case though.
>
> d.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Danny,
I agree here that information in the Received header is very ify.
The info can be wrong or possibly be missing all together (this breaks
RFC822 but still seems to be done by some firewalls and mail servers)
It also seems that sometimes Firewalls and Relays can remove/change portions
of the Received header to obscure certain information that could be used to
mount an attack.
I found nothing in RFC 822 that says RCPT TO: must be exposed, NOTE that
this translates to the "for" parameter
Quote from RFC 822: "the receiving host may wish to record the original
specification, using the "for" parameter."
The Received header appears once for each relay the mail goes through with
the most recent email server first, and the first mail server that relayed
this email last.
I am still wondering if it is not just easier to add the option in the
FetchPOP block to say who the fetched mail is for.
There seems to be a fair amount of "if's" which in my opinion don't make
things simple and could lead to strange results.
I can already see the questions coming when the FetchPOP behavior is not
understood by someone using JAMES and we
have to explain how we try and decide who the FetchPOP'd mail is for.
Thanks,
Serge or maybe Sergei and then I don't get mixed up with the other Serge :-)
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, January 03, 2003 11:50 AM
Subject: RE: [Proposal] FetchPOP configuration change
> > Is there any concern regarding whether or not the the Received
> > header might
> > not have the proper information?
>
> Yes some, I'm not 100% sure that a "Received" header MUST expose the "RCPT
> TO:" address in a "for" line, nor that this would necessarily be a
> legitimate mail address of any kind.
> Can we reasonably infer that SMTP headers exist simply because mail is
> available for download via POP3?
> If not, we can read the message "To" & "Cc" headers, if this fails to help
> (perhaps it was a bcc) we should catch this in FetchPOP and take some
> default action, perhaps indeed have a default alias for unidentifiable
> fetched mail.
>
> If, sorry _when_ we get mail parameters we can (possibly, if we can have a
> mail object without a recipient) set a parameter to indicate an
unsucessful
> attempt to parse a recipient address, this can be used in the general
> pipeline to filter this mail so that the user controls what happens,
rather
> than have us impose some arbitrary behaviour. I worry about null pointer
(to
> recipients) exceptions in this case though.
>
> d.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by Danny Angus <da...@apache.org>.
> Is there any concern regarding whether or not the the Received
> header might
> not have the proper information?
Yes some, I'm not 100% sure that a "Received" header MUST expose the "RCPT
TO:" address in a "for" line, nor that this would necessarily be a
legitimate mail address of any kind.
Can we reasonably infer that SMTP headers exist simply because mail is
available for download via POP3?
If not, we can read the message "To" & "Cc" headers, if this fails to help
(perhaps it was a bcc) we should catch this in FetchPOP and take some
default action, perhaps indeed have a default alias for unidentifiable
fetched mail.
If, sorry _when_ we get mail parameters we can (possibly, if we can have a
mail object without a recipient) set a parameter to indicate an unsucessful
attempt to parse a recipient address, this can be used in the general
pipeline to filter this mail so that the user controls what happens, rather
than have us impose some arbitrary behaviour. I worry about null pointer (to
recipients) exceptions in this case though.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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.
That seems right, but the problem you have illustrated is easy to address.
For example, it is easy to handle as an entry in JDBCVirtualUserTable, along
with other aliases, without bloating the configuration. All things
considered, I'd rather have aliasing controlled in one place in my
configuration, rather than several.
Is there any concern regarding whether or not the the Received header might
not have the proper information?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi,
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
matcher.
Sorry if I am completely off here.
Serge
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@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
myself.
> 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
name
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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 myself.
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 name
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>