Thank

you for response.

my

problem was solved by your advice.

>I think you are asking how to stop certain headers being added by

Mercury - is that correct?

Yes.Your

understand is right.

>Try turning off the Content Control (CC) filtering which adds most of

the headers you give.

I tried

to it. below message is disappear. thank you.

 X-UC-Weight: [# ] 51

 X-CC-Diagnostic: Not

Header "Date" Exists (51)

I was

able to delete below message.

 Message-body

 Message-ID:

<F099047AF2@localhost>

It was

miss type in my code of X-Port Control.

miss

type in create DATA information part.

 char

txbuf[1024];

 sprintf(txbuf,"Message-body\r\n\r\n");    ← : is none.bad.

 sprintf(txbuf,"Message-body: \r\n\r\n");  ← : is added.correct.

I find

above miss code,because there was your advice.

in

Forder \xampp\MercuryMail\QUEUE.

in File MG0000003.QDF  this file is not processing.

Return-path:

<es@example.com>

Received: from

example.com (192.168.16.175) by localhost (Mercury/32 v4.01b) ID MG000003;

   8 May 2011 14:07:06 +0900

From:<es@example.com>

To:<arx@yahoo.co.jp>

Subject: SUBJECT

Message-body

my

name is smtp.

in File MO0000004.QDF  this file was processed

for relay.

Received: from

spooler by localhost (Mercury/32 v4.01b); 8 May 2011 14:10:12 +0900

Received: from

example.com (192.168.16.175) by localhost (Mercury/32 v4.01b) ID MG000003;

   8 May 2011 14:07:06 +0900

From:<es@example.com>

To:<arx@yahoo.co.jp>

Subject: SUBJECT

Message-body  ← i find miss type.

Message-ID:

<F099047AF2@localhost>

my name is smtp.

> We use MercuryD to collect the mail. It is a domain type mailbox.
>
>  I don't know what you mean be the 'original RCPT TO address for delivery', how do I tell?

There is one added by Mercury just before putting the mail into a users mailbox that is the X-Envelope-To: header.  You cannot use this one but there my be one showing one of the following or similar.

X-Rcpt-To: <email@address>
X-Recipient: <email@address>
X-Deliver-To: <email@address>

It's what the original receiving SMTP server writes to the message to show the original RCPT TO address of the message before it writes it to a POP3 mailbox just like Mercury does with the X-Envelope-To: header.

If there is not then you do have some problems and the postmaster is going to spend a lot of time forwarding mail when there is no local address in the message.

Have you got a real-time virus scanner running?  If so, exclude all of the Mercury directories as it needs exclusive access to its own files.

If that doesn't sort the problem turn on session logging and trace a message through Mercury.  Post anything relevant here, but leave out any passwords.

> I've been using Mercury for a couple years now, without much trouble.  A few weeks ago, without changing any settings, thunderbird started
> complaining that the password was wrong and mercury started complaining about multiple failed log ins.  I reinstalled to get
> around this but now nothing is coming through.  I'm pretty sure it's all set up like I had it on the last installation but sending emails
> to my own address just bounce back (eventually).  Any ideas?

1.    Turn on session logging in MercuryS to see if the mail is getting into Mercury core without error.

2.    Check the Mercury system log for errors.

3.    Post an unmodified copy of you Mercury.ini file for analysis.

4.    Provide copies of the text of the error messages.

No, we are not at the EXPUNGE stage yet.

Before an e-mail can be expunged, it has to be flagged as DELETED first. For most imap clients this means the mail is no longer displayed in the mailfolder (or it appears as "striked through"). This flag disappears, i.e. the e-mail appears again in my inbox, as if I had only read it, not deleted it.

Initial testing suggests, the Marking of the e-mail is lost, if the client connection is lost without EXPUNGE. This would be really bad, since up to Mercury 4.72, disconnecting your imap client was the only way to assure such flags where saved to disk.

I had to switch back to 4.72 on our user servers.

Greetings

Markus Borst

It's not running in program mode that slows Mercury down, and it's not the Windows Server environment as such either. Obviously we need more information to figure out what the problem could be, though. If you can give specifications about the hardware used, other software running on the server, number of mail accounts, Mercury settings and things like that we can see if anything obvious comes to mind.

One thing that always is important is that there must be no antivirus software or similar that interferes with Mercury's access to queue, scratch or mailbox directories.

/Rolf 

File-based forwarding using FORWARD files can be switched on in Core configuration / Advanced. There will then be a forwarding button available when you edit user details in Manage local users. The syntax for the FORWARD file is explained in the edit dialog (and in Mercury help).

/Rolf

> On a small mercury mail server we see quite some message in the map \mercury\mail\user
>
> Opening these files with notepad we see the are all the messages (.NCM) from a 10 day period the user received and misses in his POP
> e-mail client.
>
> Telnet with the list command shows 0 messages for the user.
>
> Any ideas how to get them into the "proper" inbox folder of the user ?

Make sure the POP3 server is configured to offer read mail.  From the MercuryP help:

Mark retrieved mail as "read"  When this control is checked, MercuryP will change the status of all messages downloaded by POP3 clients to "read". This can be used in conjunction with the "offer only unread mail" option to allow users to leave copies of all their mail on the server, but be offered only mail they have not seen.

Offer only unread mail  If this control is checked, Mercury will list only messages whose status is "unread" - mail marked as read will be invisible to POP3 clients. This option is very convenient, but is also not a part of the POP3 standard.

> I can see that doing thinks Mercury doesn't allow could lead to

unexpected results, but it wasn't the mail cache that
> was messed up, it

was the PMM file - verified by reading it on the server. I didn't

examine the cache but from the file
> size it appeared normal, it

certainly wasn't anywhere near the size of the PMM.

> gusq, in

theory the situation you describe can result in conflicts, but as noted

above, my experience has been that
> problems were very rare up to and

including 4.72.

Did you run the MBXMAINT.exe from v4.73 on all of the PMM files?  In v4.72 and earlier there are problems with duplicate message identifiers when using IMAP4 and these can cause all sorts of problems.

OK - sorry folks I think this was a red herring. I had a single Android phone with two mail clients polling simultaniously (Vanilla Android and K9) stopped one and crashing stopped now stable again

I'll run Mbxmaint and the  tip is useful thanks - I wondered before why mbxmaint could run with no apparent success

thanks

Ron

> When I choose the solution with "MercFwd daemon", can the Mercury server perform all the following
> tasks before the "MercFwd daemon" forwards all the emails to the Postfix server?
>
> the tasks would be as follows:
> - Graywall,
> - Spamhalter,
> - SMTP transaction filtering,
> - Content Control/Filtering rules,
> - and virus checking

 Yes, since all you are doing here is using a daemon in the domains section to change the RCPT TO address and core uses this to send the mail off to the other server after all receipt processing is completed.

.

The detailed logged revealed it was an SSL error which I fixed. Thank you for your help.

> If someone knows the answer to the does Auth or DNSBL happen first, I would still be interested to have the answer to that question.

Blacklisting happens upon connection by the sending system when MercuryS checks to see of the connecting IP address is blacklisted. Authentication happens much later in the process after the receipt of the EHLO string.  If you do a session log from a blacklisted address it becomes readily apparent when the blacklisted connection is rejected.

What you can do though is tag using the blacklist instead of rejecting and then later in the receipt process done by the core module setup some sort of filter based the header added to the message.

Thanks for your help Thomas.

It turned out that the problem was with the firewall protecting the Mercury server.

I'd not allowed traffic to port 993 and of the various mail clients I was testing IMAP SSL connections with, only Outlook used that port.

Regards

Richard

Thanks Rolf, that is very helpful.  This is the behaviour I expected to see, and think I did initially.  I will check on the settings you suggest!

Thanks again for your time
Ormo 

Hi Theresa,

I've upgraded Mercury a few times and I've never had a problem with configs or other settings so I can't see it being a problem for you. Just make a sideways copy of your mail folder before you do.

However, have a look through the forum at the issues raised by poeple since they've upgraded! We've been running 4.72 with no problmes for ages and have recently upgraded - I'm now looking at rolling back to 4.72 as I'm unhappy with a particular issue I have.

Regards

Dave.

Thanks for the reply. Much appreciated.

 Duncan

OK, I think I'm done now, executed the following steps;

1. stopped Mercury
2. created RAR archive of Mercury directory in Program Files
3. created RAR archive of Mercury directory in VirtualStore
4. deleted Mercury directory in VirtualStore
5. created C:\Mercury and moved all contents of C:\Program Files\Mercury over
6. extracted the RAR archive of the VirtualStore into C:\Mercury, overwriting existing files (assuming that the last files written would always be in VirtualStore, so these should be the correct ones)
7. Modify C:\Mercury\Mercury.INI and change all filepaths to point to the new files/folders in C:\Mercury
8. Assumed ownership off C:\Mercury including all underlying files and folders
9. Modified rights so regular users have full control over C:\Mercury and all underlying files and folders
10. Modified all links in the startmenu to point to the new location in C:\Mercury
11. Disconnected network
12. Started Mercury and paused POP3 retrieval (to prevent loss of newly retrieved emails in case of a restore)
13. Reconnected network
14. Started mail clients and verified everything working fine (duplicate issue and deleting old messages)
15. un-paused POP3 retrieval (to restart processing incoming mail)

The tricky part was merging the users folders, as a lot of files where overwritten. In the other folders it were merely settings, logs, or empty folders. All in all it seems to have worked out fine, though I probably won't be sure about that for at least a couple of days.

Just posting this as it might help someone else out.

[quote user="royhink"]

I would really appreciate some configuration pointers as I am a non-IT Tech trying to install Mercury32 on my Win2003 server.

This install only needs to handle outgoing email thru our smtp host, Rackspace, which requires authentication. Plus, there is only 3 'users', the three ShopSite eCommerce platforms on the server. ShopSite sends out a confirmation email after the purchase.[/quote]
Before going any further, I want to be absolutely clear on something...  Those "ShopSite eCommerce platforms" are running on the same server that you have installed Mercury on, right?  I'm going to continue based on that assumption; but if it's wrong, PLEASE say so ASAP.

[quote]ShopSite simply asks for a smtp host name.[/quote]
That should be OK -- i.e., not a problem.

[quote]I've installed Mercury32 with  MercuryS, MercuryC and MercuryX,[/quote]
I agree with "dilberts_left_nut" on this one -- you do not need the MercuryX module for this application; and in the interest of simplicity, you probably ought to disable it.

[quote]and configured MercuryC with the host name and credentials, and get the following:

Sendmail failed; SMTP server error: 553 We do not relay non-local mail, sorry.[/quote]
This is of course the critical part; but here, I'm not nearly so certain that "dilberts_left_nut" was correct.  The mention of Sendmail implies that it may be your smarthosting provider (i.e., Rackspace) which is generating that error message.  If that is correct, then it would seem that MercuryC is failing to properly authenticate itself with Rackspace's SMTP server.  I suggest that you double-check the MercC configuration settings, especially make sure that "Authenticate via prior POP3 connection" is NOT checked, and that you have correctly entered the username and password that Rackspace gave you in the appropriate fields (yes, upper/lower case counts!).

[quote]I also want to be sure that it is restricted to only sending from the ShopSite stores.[/quote]
Way back when I first set up Mercury (v3.01, IIRC), I needed to do something similar because the server itself was co-located some 3,000 miles away, and effectively open to the general internet (hence, proper authentication and strict relaying control was absolutely required); but the mail client (a very old version of Eudora) that I was loathe to abandon (and still am, mostly -- at least to the degree that I still use Windows at all, which is waning steadily) did not support SMTP AUTH.  My solution was to run two copies of Mercury...  One on a local box to which my desktop system(s) could connect to directly via the LAN, which in turn relayed to the "real" mail server at the co-lo site.  This scenario largely mimics your situation; where the "local copy" is analogous to your Merc install, and my co-located and remotely administered Merc server corresponds to your smarthosting provider's (i.e. Rackspace's) SMTP server.  The key to making it all work, while still keeping it secure, was to create two specific entries in the "Connection Control" pane of the (local) MercS configuration screen:  Namely, a general "Refuse" definition for the entire IPv4 netspace (0.0.0.0 - 255.255.255.255), followed by an "Allow" entry for just the local LAN segment (192.168.0.0 - 192.168.0.255), then UNcheck all four checkboxes under "Relaying control".  With this setup, any workstation on my local network could connect to the local copy of Merc and relay mail through it, without needing to use SMTP AUTH (or any authentication at all, for that matter); but since ONLY clients on my local network could connect to it at all, it was still protected against unauthorized relaying (such as by spammers).

[quote]Any help greatly appreciated.[/quote]
You're quite welcome.  I hope this has been helpful.

[quote user="forum user"]
"mydomain" isnt mine. i have "oapplications" the domain name.[/quote]
Which means you should not use "mydomain" as an example.  There IS a domain which is maintained for precisely this purpose, and it is called (surprisingly enough...) "example.com".

[quote]i changed and now i have as bellow:

mailqueue:       C:\MERCURY\QUEUE    # Where mail should be put for delivery
smtpqueue:       C:\MERCURY\QUEUE    # Where the SMTP client should look for mail
newmail_path:    C:\MAIL\~n    # Where to find the users' WinPMail mailboxes.
[/quote]
So far, so good.

[quote]i added in Mercury at "Manage local users..." a user,"mail".[/quote]
Do you have something against using sensible user-account names?  How is "mail" supposed to distinguish between various users (or various role accounts, for that matter)?

[quote]i see in C:\MAIL\   the mail folder and PMAIL.USR file.[/quote]
Do you mean to say that the PMAIL.USR file is actually in ~/MERCURY/MAIL/ and not in ~/MERCURY/MAIL/MAIL/ ?  If so, that is potentially a problem, especially when you go to add additional user accounts.

[And as a side note...  Yes, you WILL need to add additional user accounts, even if for nothing else besides "postmaster@..." and "abuse@...", both of which are required by the relevant RFCs for any domain which sends or receives mail.  If you operate a web site, you probably also ought to have "webmaster@..."; but AFAIK this is not strictly required.]

[quote]the first three at "Relaying control" are checked.[/quote]
Good.

[quote]i tested again and i found the email in mail\mail folder (the other incoming strange mails from strange users seems to be refused fine).[/quote]
You can confirm that by reviewing the log files.

[quote] Thanks for your help.All the good things.[/quote]
You're welcome.  I'm glad that you (apparently) got it (at least partially)  working.