> -----Original Message----- > From: tobe [mailto:[EMAIL PROTECTED] > Sent: 15 June 2003 12:27 > To: James Users List > Subject: Fetchmail (was Re: Is this a valid From: address?) > > Steve Brewin wrote: > > Tobe,
> I am a bit concerned about "will only deliver locally". How do you > ensure that? My musings have moved on to a new version of fetchmail that has been submitted, but not as yet accepted. In the submitted code, for each of the mail filter conditions, such as rejecting remote mail, rejection is now optional and the status of the rejected mail on the POP3 server can be deleted, marked as seen or left asis. The main reasons for rejecting mail at the fetchmail stage are to avoid the overhead of fetching mail that is simply going to be junked and the extra work of defining matcher/mailets to weed out such fetched mail. If it is decided to accept mail for which a filter condition applies, this is indicated by an X-Header added to the mail which describes the filter match. This allows the injected message to be detected by a matcher and processed in a mailet as required. Tere are many possible fetch 'stories'. The intent is to provide the flexibility to accomodate as many as possible. > The first problem is that the account you fetch from is > usually never a > local account, and should not be set up as a handled domain else you > will get all sorts of other problems. Depends on the story. There are a several where *not* defining the domain locally causes all sorts of other problems. As described above, the rejection of remote mail is now optional and can be done at the fetch stage or during matcher/mailet processing. > I found that mail with multiple recipients caused problems when used > with fetchpop, either generating duplicates if I forwarded all to my > local account or risked being resent outwards if I tried to > be smarter. A key difference between fetchpop and fetchmail is that the latter injects mail for a sole intended recipient. This avoids the problems you had with fetchpop. There are circumstances when it is not possible to determine the sole intended recipient, in this case the released version of fetchmail uses a default recipient. The submitted version adds the option of leaving it on the POP3 server. The latter accomodates scenarios in which the default recipient can be determined by refetching with a different POP3 account. This is explained in the comments within the submitted config.xml. > So there seems to be a lot of reasons for not injecting fetched mail > into James's delivery chain. And yet the main reason for > using fetchmail > is to be able to use mailets on it. > > Let me try to invent some "user stories" for fetchmail: The beauty of James is that it is extremely flexible and can accomodate these and a huge number of 'stories'. I can't really see the motivation for delivering fetched mail to another spool in any of your 'stories'. If you want to do something special with all fetched mail, use a matcher that checks for the X-fetched-from header, such as "fetchedfrom". All mail injected into the spool by fetchpop and fetchmail has this header appended for just this purpose. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
