Reasonable questions all, but I don't have old Mercury logs - I only turned on that particular logging when it became an issue. I've checked Received headers in a current message and one received six months ago, and Mercury is declaring v4.74 in both.

It's possible that it's the level of problem that has changed. I've had the odd message before come to me, but I'm postmaster, so I just assumed an unknown problem and forwarded it. Now it's probably running at 20% or more of my wife's messages (haven't counted properly).

Another (possibly related) problem we have is spurious suppression of duplicate messages by Mercury. Since, in reality, we're both using the same mailbox on a given ISP, and the Envelope-to: headers are distinguishing which of us should get the mail, then if, say, we're both on the same mailing list, Mercury will suppress one copy of the message, which is infuriating, because you cannot easily work out what you've missed, or even which user missed it. At least if there were an option to turn duplicate suppression off, or even redirect duplicates for the postmaster's attention, there would be some control. I'm aware that the "Look only in these headers" setting should prevent this, but it does not appear to do so. I haven't even found a log where I can check what duplicates were suppressed. In at least one case, I'm having to use a rule in Pegasus Mail to autoforward the messages to the other account(s) and thus work around the issue, but I can only do that for mailing lists that I know are affected. I've also tried arranging for us to use different ISPs when registering on such lists, but not necessarily with great success. I'm not clear that I wouldn't even get spurious suppression sometimes if a friend included both of us in the addressees for the same message.

I'll try removing X-Envelope-to from the rules, because it seems to be irrelevant. As you say, it shouldn't make any difference, but who knows?

Happy to pass on logs and headers - should I PM you?

To state the obvious, I also have logs for messages that were delivered, including one where "duplicate" messages (from a Yahoo Group to which we both belong) were delivered properly to each of us, which is the result required. No real idea why it worked in that case and not in others.

Regards

I've been using Mercury for years in a home network. Suddenly, it's misdirecting a minority of mail to me as default user that should go to other family members. I can't see why, and I don't know whether it's a change at my ISP, some new mail sources with configurations different from anything we have received before, or something in my configuration. I have not changed anything in months.

We have free email on two ISPs. In each case, the ISP is configured to deliver mail regardless of local address @ our domain, and Mercury does the sorting. I get anything left over that was sent to a local account that doesn't exist, which is pretty rare (probably, ISP spam measures block most of it). Suddenly, I'm getting a minority of mail for a valid local account, but only via one of the ISPs.

I turned on logging on MercuryD, and I can see that messages come in with Envelope-to: user@ourdomain.com and yet (a minority) still end up getting delivered to me.

By the time I look at them in raw view in Pegasus, misdirected messages have gained an X-Envelope-to: me@ourdomain.com, which is consistent with their being delivered to me.

Mercury was previously set to look at Envelope-to: and X-envelope-to: I'm now trying telling it to look exclusively at those, since it seems that the ISP in question always adds Envelope-to:

However, again, there have been no changes on my end.

Any suggestions of a likely cause for this happening suddenly?

Unless you have made any changes in your local environment MercuryD should behave exactly the same way as before (try to find the local mailbox from headers according to your settings, and if no such mailbox is found deliver to the default mailbox). It might be a good idea to ask the helpdesk of the ISP in question if they have made any changes regarding what headers they add to messages for domain mailboxes.

Yes, I did that at the same time as starting this thread. They have now confirmed that there have been no changes.

Again, messages are coming in with Envelope-to: addresses for the correct local accounts. However, a minority are being assigned additional X-Envelope-to: addresses for my account (the default account) by Mercury, and then being delivered to me. I can tell this because the Mercury logs show the incoming message without the X-Envelope-to: address, but I can see that address in the raw view in Pegasus Mail. The version in Pegasus Mail still has the Envelope-to: address for the local account to which the message should have been delivered, as did the version in the Mercury log.

The reality is a "catch-all" mailbox ourdomain@ourisp.com to which mail for anyaddress@ourdomain.ourisp.com is delivered. Hence, Mercury is collecting mail from a single mailbox (at this ISP) and (should be) sorting it on the basis of To: and Envelope-to: addresses in individual messages.

It works most of the time, but not for some messages.

If MercuryD can't find the first X-Envelope-To header it would seem that there is something in the message that breaks header parsing before the line containing that header, like an extra linebreak, a line that is too long, or something else that isn't expected to be there. Examining the original message as received from the domain mailbox could reveal what the problem is, and might make it possible to make adjustments in MercuryD to handle it - if within reasonable RFC compliance.

Sorry for the slow reply - I've just realised that notifications were off by default.

It's now happening with two ISPs, so probably isn't anything that the ISP has done.

Contrary to your message, I normally get just an Envelope-to header. The X-Envelope-to header is added by Mercury. For example (email addresses and machine names disguised to protect the guilty), a Mercury log:

15:49:50.997: << RETR 12<cr><lf>
15:49:50.029: >> +OK 6718 octets follow.<cr><lf>
15:49:50.029: >> Return-path: <our.friend@herdomain.com><cr><lf>
15:49:50.029: >> Envelope-to: mywife@ourdomain.com<cr><lf>
15:49:50.029: >> Delivery-date: Thu, 26 Jun 2014 13:56:08 +0100<cr><lf>
.................

In Pegasus Mail, the same message looks like this:

Received: from spooler by mypc.ourdomain.com (Mercury/32 v4.74); 26 Jun 2014 15:50:00 +0100
X-Envelope-To: drossall
Received: from POP3D by mypc.ourdomain.com with MercuryD (v4.74); 26 Jun 2014 15:49:54 +0100
Return-path: <our.friend@herdomain.com>
Envelope-to: mywife@ourdomain.com
Delivery-date: Thu, 26 Jun 2014 13:56:08 +0100
................

and it gets delivered to me, not to my wife. mypc is running both Mercury and my copy of Pegasus Mail.

Take your point on long lines, etc., but there's nothing that I can see. In fact, as above, the lines are quite short. I even looked at the spaces etc. with a hex editor. The previous message was delivered just fine.

To confirm, Mercury has special headers:

Envelope-to;X-Envelope-to

and is set to look only in these.

Regards

If your ISPs always add Envelope-to headers it will be enough to look for those. The current rule should work too, though.

I can't see anything out of the ordinary in the log quote, but then again I would need to see the real message as it was received by Mercury to know for sure.

You are running the same version of Mercury now as you did before, right? If so we know that the program hasn't changed and will behave exactly as it always have. So what may have changed? Settings for MercuryD or for instance in rules can of course lead to different delivery behavior. Major changes on the computer (like OS updates, new antivirus software) can certainly have unwanted side effects, but I can't really see how it could mess up address parsing. Software updates or changes in settings for the ISP's mail server can make a difference as well. "Received" headers will often reveal what program and what version that was used to receive and pass on the message, so if they have changed that could be a clue.