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 Tue, 07 Jan 2003 09:33:54 GMT
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.


----- Original Message -----
From: "Serge Knystautas" <sergek@lokitech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Tuesday, January 07, 2003 5:57 AM
Subject: Re: [Proposal] FetchPOP configuration change

> ----- Original Message -----
> From: "Noel J. Bergman" <noel@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
> it based on header addresses. (We don't really recommend this, though, as
> may lose important envelope-header information. ETRN or a UUCP connection
> 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
> 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:
> For additional commands, e-mail:

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

View raw message