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 "Noel J. Bergman" <no...@devtech.com> on 2002/12/31 21:05:19 UTC
[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>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Serge,
In our previous discussion about this with Noel and Danny you can see that
we came to the same conclusion with regards to the "for" parameter in the
Recived header. It does not and is not always present.
So currently I have added a config option to FetchPOP with which you can
turn intelligent guessing on or off and specify an address to use in the
case where the guessing fails or guessing is turned off.
I am testing at the moment and will release when its been tested.
Thanks,
Sergei
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, January 07, 2003 5:57 AM
Subject: Re: [Proposal] FetchPOP configuration change
> ----- Original Message -----
> From: "Noel J. Bergman" <no...@devtech.com>
>
>
> > 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.
>
> Couple of things...
> 1. Received header does not require RCPT TO. You'll notice in James we
> include the RCPT TO address if only 1 address was specified, but not if
> multiple addresses are specified.
> 2. In terms of recreating the transport data (the Mail data that's not in
> the message), here's what the fetchmail home page says:
> "Fetchmail can be used as a POP/IMAP-to-SMTP gateway for an entire DNS
> domain, collecting mail from a single drop box on an ISP and
SMTP-forwarding
> it based on header addresses. (We don't really recommend this, though, as
it
> may lose important envelope-header information. ETRN or a UUCP connection
is
> better.)"
> So I don't think there's much you can do aside from intelligently guessing
> at this.
> 3. What I was hoping we could do with James is have fetchpop3 get
> re-architected so it worked like this...
> a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail
> repository virtual file system.
> b. there is a service running that periodically moves messages from one
> virtual file system to the other.
> This way you can dump those messages into a given spool or another mailbox
> or whatever you want to do. I already plan to let us mount pop3 and imap
> mailboxes in the virtual file system (assuming everyone likes this), and
> periodic services would be great to purge old spam or move messages from
one
> place to another.
>
> Anyway, just some thoughts I thought I'd throw out there.
>
> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
>
>
> --
> 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 Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Serge,
>
> I agree with your concern regarding whether Received includes the RCPT TO
> info. Please note that I had originally proposed specifying the address
> that would be used for the new Mail. Danny wanted more automatic support
> and mentioned Received. I think that Received is good, but raised the
> question regarding the fragility of that contract, and so we've gone circle
> and come back to Received providing a default, and a configuration item
> providing a fallback.
>
> Personally, I'd like to eventually have much more of fetchmail's range of
> configuration items, where it makes sense, but Danny is right to push for
> simplicity in terms of what is required.
>
> If someone (e.g., Serge Sozonoff) is really interested in enhancing
> FetchPOP, I am fairly sure that Eric would be happy to explain any design
> rationale behind things that don't appear documented on the fetchmail web
> site (http://www.tuxedo.org/~esr/fetchmail/index.html).
>
> Personally, I'm not interested in demuxing enterprise e-mail from a single
> mailbox, but I can see how one might want to recreate RCPT TO addresses such
> as mailing lists or other. If I were to use FetchPOP to migrate e-mail from
> my personal main mailbox to James, I believe that I'd have a lot to do to
> recreate the information that I currently use for client filtering.
>
>
>>a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail
>> repository virtual file system.
>
>
> Interesting idea. Can't JavaMail do that for us, since we'd be using it as
> a client talking to a server?
Yeah exactly, this gets back to my big mounting strategy... it allows to
configure repositories more flexibly, so it's easier to wrap JavaMail
(POP3, IMAP) with a Mail repository implementation.
I think once I get the time I'll probably create a branch to show how
this would work since there seems resistance mainly because of the
newness of the idea. Or maybe just some conf file and related java code
to explain it better.
>>I already plan to let us mount pop3 and imap mailboxes in the
>>virtual file system (assuming everyone likes this)
>
>
> I think that now that Danny has started pushing the Mailet API v3
> interfaces, the main things that need immediate attention are the Mail and
> User repository models. I am not sure that everyone sees things the same
> way, yet.
Judging from the CVS commits, I think the Mail Repository is already
moved over to the mailet API, and I don't really expect to make many
changes. I actually think it works just fine with the children support
and storing/getting Mail objects. We might separate spool repository,
but I'm not too worried about that. We'll potentially have to change
the implementations depending on what we do with Mail objects (namely
adding attributes), and my mounting change would only really change how
lookups function (I believe).
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] FetchPOP changes
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi,
As discussed in the "FetchPOP configuration change" thread, here is patch
which adds an additional config parameter to the FetchPOP block.
The config parameter looks like this:
<recipient ignorercpt-header="false">user@mydomain.com</recipient>
If ignorercpt-header = true then fetched mail will always be re-spooled with
the specified address as the envelope recipient.
If ignorercpt-header = false, the header is parsed as follows to try and
determine the envelope recipient to use when the mail is spooled
in James.
First the Received: header is parsed to try and find the "for" parameter, if
this fails the To: header is checked and if it contains only one recipient
then this is used as the new envelope recipient for the newly spooled mail.
If both of these fail, the specified recipient from the configuration
parameter is used.
It is possible to do additional checks to try and find who the original
recipient is and if I am going in the right direction with this I will look
at
maybe adding a few more possibilities. I have been reading about Fetchmail.
I have also added a failsafe to avoid mail loops, I simply count the number
of times the X-fetched-from header occurs and if it is more than three I
change the mail state to ERROR before spooling.
I welcome any feedback.
Thanks,
Sergei
RE: [Proposal] FetchPOP configuration change
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
I agree with your concern regarding whether Received includes the RCPT TO
info. Please note that I had originally proposed specifying the address
that would be used for the new Mail. Danny wanted more automatic support
and mentioned Received. I think that Received is good, but raised the
question regarding the fragility of that contract, and so we've gone circle
and come back to Received providing a default, and a configuration item
providing a fallback.
Personally, I'd like to eventually have much more of fetchmail's range of
configuration items, where it makes sense, but Danny is right to push for
simplicity in terms of what is required.
If someone (e.g., Serge Sozonoff) is really interested in enhancing
FetchPOP, I am fairly sure that Eric would be happy to explain any design
rationale behind things that don't appear documented on the fetchmail web
site (http://www.tuxedo.org/~esr/fetchmail/index.html).
Personally, I'm not interested in demuxing enterprise e-mail from a single
mailbox, but I can see how one might want to recreate RCPT TO addresses such
as mailing lists or other. If I were to use FetchPOP to migrate e-mail from
my personal main mailbox to James, I believe that I'd have a lot to do to
recreate the information that I currently use for client filtering.
> a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail
> repository virtual file system.
Interesting idea. Can't JavaMail do that for us, since we'd be using it as
a client talking to a server?
> I already plan to let us mount pop3 and imap mailboxes in the
> virtual file system (assuming everyone likes this)
I think that now that Danny has started pushing the Mailet API v3
interfaces, the main things that need immediate attention are the Mail and
User repository models. I am not sure that everyone sees things the same
way, yet.
--- 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 Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> 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.
Couple of things...
1. Received header does not require RCPT TO. You'll notice in James we
include the RCPT TO address if only 1 address was specified, but not if
multiple addresses are specified.
2. In terms of recreating the transport data (the Mail data that's not in
the message), here's what the fetchmail home page says:
"Fetchmail can be used as a POP/IMAP-to-SMTP gateway for an entire DNS
domain, collecting mail from a single drop box on an ISP and SMTP-forwarding
it based on header addresses. (We don't really recommend this, though, as it
may lose important envelope-header information. ETRN or a UUCP connection is
better.)"
So I don't think there's much you can do aside from intelligently guessing
at this.
3. What I was hoping we could do with James is have fetchpop3 get
re-architected so it worked like this...
a. the remote mailbox (pop3 or imap4) is mounted somewhere on the mail
repository virtual file system.
b. there is a service running that periodically moves messages from one
virtual file system to the other.
This way you can dump those messages into a given spool or another mailbox
or whatever you want to do. I already plan to let us mount pop3 and imap
mailboxes in the virtual file system (assuming everyone likes this), and
periodic services would be great to purge old spam or move messages from one
place to another.
Anyway, just some thoughts I thought I'd throw out there.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
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>
Re: [Proposal] FetchPOP configuration change
Posted by Serge Sozonoff <se...@globalbeach.com>.
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>.
Oh ok I get it then!
d.
> Well, obviously, you knew quite well what I was on about.
--
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>.
> > The primary change is to add the SMTP address to the configuration, so
that
> > FetchPOP knows to what address to send the mail.
> Not quite sure what you're on about Noel.. what we need to do is to parse
> the Received header to get the FOR address from the envelope.
Well, obviously, you knew quite well what I was on about. You just had a
less brain-addled way of doing it. :-)
And, as for the rest of it, the answer is quite simple. All that one would
need to do is use the FetchFrom matcher and do whatever if I wanted to do
any redirection, same as for any other e-mail.
Which means that I suppose the real proposal is what you said: we need to do
is to parse the Received header to get the FOR address from the envelope,
and use that as the mail object's recipient address.
--- 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>.
> 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.
Not quite sure what you're on about Noel.. what we need to do is to parse
the Received header to get the FOR address from the envelope.
Thereafter the mail will simply be processed by the normal spool.
d.
> 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.
Unless we do this for incoming SMTP messages (which we don't) why would we
do it for fetched messages?
>
> 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>