> Okay, this IS going to take a few rounds but hopefully we're reaching the culprit.
>
> My (volunteer) ISP, for valid reasons, has decided to upgrade and this
> way invalidate my current setup. The setup has 2 duties:  
>
>
> *   POP3 domain mailbox splitting. 3 userid's are on my PC (all in
>     same Live Mail) and 1 is on the wife's. For this I use a filtering
>     rule, and if the header To contains her e-mail address I copy to
>     her mailbox.
>
> *   Forward to webmail (handy during daytime when I am not at home PC)
>
> What the ISP now has done is still receiving my e-mail but my subdomain
> avalokite.doge.nl now has become avalokite.cumail.nl through a Domain
> Alias. And my username/password towards the ISP changed, now the
> username is postmaster@avalokite.cumail.nl.

Did you add this domain to the Mercury domains list?  If this is the domain of the mail received into the POP3 mailbox and is not in the Mercury domains list then the mail will be considered non-local.  

> As far as I can see, nowhere in the Mercury files I have configured
> the domain name but it still might be somewhere...

Configuration | Mercury core | Local domains.

> Two scenarios tried uptilnow. First one: POP3D without 'default user'. Result
> 16:46:14 - Connecting to pop3.avalokite.cumail.nl:110 as 'postmaster@avalokite.cumail.nl'
>   - 6 messages successfully retrieved.
>   - 6 non-local messages ignored.

Domain of the received mail is not in the domains list and there is no default user.

>
> How the heck does it conclude that the messages are non-local? Does it
> make some assumption based on the fact that the polling address is
> cumail.nl?
>
> Anyhow, mail disappeared ;-) So I tried the next trick in the book,
> step by step debug: configured a 'local user' which basically disables
> all mail distributing rules. Still more interesting results:
>
>
> 17:00:27 - Connecting to pop3.avalokite.cumail.nl:110 as 'postmaster@avalokite.cumail.nl'
>   - 1 message successfully retrieved.
>   - 1 message delivered to 'lorderik@avalokite.doge.nl'.
>
> So far nice. BUT, what does Mercury do:
>
> *   Filtering rules executed normally, it forwards to the webmail
>
> *   However the mail for lorderik (Windows live mail client) is not
>     kept locally for the client, but sent over Internet to the ISP
>     again! Which cleverly enough decides this is a circular loup and
>     terminates.

Correct, you have set the local domain to a non-local domain so it is forwarded to the remote address which is of course puts is back into the same POP3 mailbox.

> So again, somewhere it seems that Mercury thinks it knows that all
> local mail clients should be configured with cumail addresses and
> anything received through a Domain Alias (the new scenario) does get
> through the filtering/forward rules but not in any decent way through
> the POP client. It is even very certain that any non-cumail address
> does not belong here...

A couple of ways.

1.    Create an alias for user@avalokite.cumail.nl to user@<a local domain> so the mail gets delivered to a local user.

2.    Not sure how to fix the webmail problem since that address is in fact the same address as the POP3 domain.  This means if lorderik@avalokite.doge.nl is the same as the POP3 address you will create a loop if forwarded back to the POP3 mailbox.  What you could do is forward this to a Yahoo or GMail account though.

> Who has an idea what goes wrong, and if fixable then how?
>  Tnx a lot,

Okay, this IS going to take a few rounds but hopefully we're reaching the culprit.

 My (volunteer) ISP, for valid reasons, has decided to upgrade and this way invalidate my current setup. The setup has 2 duties:

* POP3 domain mailbox splitting. 3 userid's are on my PC (all in same Live Mail) and 1 is on the wife's. For this I use a filtering rule, and if the header To contains her e-mail address I copy to her mailbox.

* Forward to webmail (handy during daytime when I am not at home PC)

What the ISP now has done is still receiving my e-mail but my subdomain avalokite.doge.nl now has become avalokite.cumail.nl through a Domain Alias. And my username/password towards the ISP changed, now the username is postmaster@avalokite.cumail.nl.

As far as I can see, nowhere in the Mercury files I have configured the domain name but it still might be somewhere...

Two scenarios tried uptilnow. First one: POP3D without 'default user'. Result

16:46:14 - Connecting to pop3.avalokite.cumail.nl:110 as 'postmaster@avalokite.cumail.nl'
  - 6 messages successfully retrieved.
  - 6 non-local messages ignored.

How the heck does it conclude that the messages are non-local? Does it make some assumption based on the fact that the polling address is cumail.nl?

Anyhow, mail disappeared ;-) So I tried the next trick in the book, step by step debug: configured a 'local user' which basically disables all mail distributing rules. Still more interesting results:

17:00:27 - Connecting to pop3.avalokite.cumail.nl:110 as 'postmaster@avalokite.cumail.nl'
  - 1 message successfully retrieved.
  - 1 message delivered to 'lorderik@avalokite.doge.nl'.

So far nice. BUT, what does Mercury do:

* Filtering rules executed normally, it forwards to the webmail

* However the mail for lorderik (Windows live mail client) is not  kept locally for the client, but sent over Internet to the ISP again! Which cleverly enough decides this is a circular loup and terminates.

So again, somewhere it seems that Mercury thinks it knows that all local mail clients should be configured with cumail addresses and anything received through a Domain Alias (the new scenario) does get through the filtering/forward rules but not in any decent way through the POP client. It is even very certain that any non-cumail address does not belong here...

Who has an idea what goes wrong, and if fixable then how?

 Tnx a lot,

<Erik>

Mercury will check if an address is local by examining the [Domains] section in mercury.ini. Start by having a look what is says there.

/Rolf 

Oops, that had info totally irrelevant for the old situation (just the local host name, not relevant for the ISP). But now in the new one indeed did do the job, I added the avalokite.doge.nl info there and now it likes resolving all rules again. So this was needed now that ISP name and login were using the domain alias trick.

Let's hope it's the solution for now, thanks a million!

<Erik>