It would be the sender that gets the error message, actually.

/Rolf 

Thanks a lot, Rolf

I've changed the entry.

Cheers!

Did you try using WSMTPEx.exe together with a domain mailbox in Mercury?

/Rolf 

the messages can be opened

it happens on different messages

We want to keep staff and students separate, but that is excellent info if we want that in the future.

Thanks again for all the answers. Even though we wouldn't be using most of the features Mercury looks like an excellent product.

Forward-To: user@hotmail.com

Delivery-Also: Y

Ok then it looks like the local user does not exist.  Possibly you did not restart Mercury or use the CTRL+Configuration+Manage local users when creating the new user.   

[quote user="u.becker"]

Hello,

we use Mercury/32 als Server for our domain. The MX points to our Mercury.

We have a branch office, which is connected via a vpn connection over DSL to our network. At the moment, all mail traffic goes to our Mercury, which delivers the mail. What we like to do is setting up an extra Mailserver in the branch office, so that they can use that 2nd server as a local server and any outgoing mails from the branch office should be forwarded by that 2nd server and the 2nd server should also pull incoming mail from server 1 and distribute that mail than in the branch office.

All users have the same domain part in their address, there should be no subdomain in the mail address.

How can we set this up, so that from both servers, all users of the domain can be reached?

1.  Set all users on the primary Mercury system and then have the secondary system pull the mail via MercuryD from the primary.  The secondary Mercury should setup a domain like sec.domain.com and alias all users to that domain so that the local mail stays local.  They still will use the when sending the mail.  MercuryD will use the address user@sec.domain.com when delivering the mail to the local user.

2.  Setup the Secondary Mercury so send using MercuryC and use the primary MercuryS as the relay host.

There are other methods that can be used as well but this is the simplest and most reliable since it is a pull system.  You might want to checkout the use of Petr Jaklin's daemon for redirecting mail if the secondary system is connected full time.

Thanks in advance for any hints

Regards Uwe [/quote]

There isn't enough information to say exactly what's wrong, but I could give you some pointers for you to start checking on.

- MX records are expected to contain an A record or a CNAME record, never an IP address. 

- Make sure there isn't a firewall blocking access to mail ports on the PC running Mercury.

- Make sure there is a port forward from your Internet modem/router/firewall to the Mercury PC for mail services that should be available from the Internet (SMTP and perhaps POP3 and/or IMAP).

- Verify that the Local domains section in Core configuration is properly filled in (see Mercury help about this).

- Check the console windows in Mercury for error messages.

/Rolf 

Hi again!
I tried and changed for Outlook SMTP server from Mercury.NLM (on NW 5.1) to Ipswitch IMail (all other route is same) and ... subject didn't disappear! See two part of headers, first sent via Ipswitch IMail and second one via MercuryS (NLM).
More thanks, Alar.

References: <> <Pine.SOC.4.64.0806250801001.17718@math.ut.ee> <009e01c99a62$8791c680$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011557450.27956@adalberg.ut.ee>  <00cb01c99a85$d355e740$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011803140.28033@adalberg.ut.ee> <00ed01c99a8a$90cd7c80$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011838280.28033@adalberg.ut.ee> <011e01c99b58$85c72ce0$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903030835080.2360@adalberg.ut.ee> 
Subject: RE: Mail1.mtk (SMTP mulk)
Date: Thu, 5 Mar 2009 15:39:29 +0200
Organization: Tartu University

References: <010601c8d3c6$42a93570$8800000a@infutiknt.mtk.ut.ee> <Pine.SOC.4.64.0806250801001.17718@math.ut.ee> <009e01c99a62$8791c680$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011557450.27956@adalberg.ut.ee>  <00cb01c99a85$d355e740$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011803140.28033@adalberg.ut.ee> <00ed01c99a8a$90cd7c80$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903011838280.28033@adalberg.ut.ee> <011e01c99b58$85c72ce0$8800000a@infutiknt.mtk.ut.ee> <Pine.GSO.4.61.0903030835080.23Subject: RE: Mail1.mtk (SMTP mulk)
Date: Thu, 5 Mar 2009 15:34:42 +0200
Organization: Tartu University

[quote user="tdawson"] We use SQL Server 2005 and are testing using Mercury to handle some simple mail lists for us.   It appears that Mercury (or maybe the MAISER component) is having trouble with the BASE64 encoded emails generated by SQL Server 2005. [/quote]

You need to write a CLR-routine to send the message as plain text, or process the database mail-queue from an external "maintenanceapp". We've internally taken the second path, since the sql-2005 built-in mailer non changeable base-64 encoding gives problems with f.ex. squirrel mail and other clients as well, plus we can combine other actions outside the db in a separate app.

[quote user="Thomas Fehr"]I search for a way to prevent, that popfiled check a message from a local sender with popfile. I know it exist the popfiled.rxp. But I search for a way where I not have to restart mercury everytime when a new domain was added.

The only thing I see on the command line is the

-l.

are all local is processed by POPFile. The default is to process all email.

Is there a possibility with the Mercury filters to add an header to a incoming mail from a authenticated user?

Not that I can find.  The authentication happens with MercuryS and there is nothing that is written to the RFC 2822 file that would give you any indication that the connection was authenticated.

Thanks :)[/quote]

We can't help much with XAMPP issues, but try starting Mercury separately (from the Start menu or the Mercury.exe file) and see what happens. If there are any error messages in the console windows take a note of them and post them here. Make sure the Windows firewall and any other firewall software you may have (perhaps in your anti-virus software) doesn't block mail ports. If after that there still is no success we will need to see your mercury.ini file to find out if there are any obvious problems there.

/Rolf 

We're now a few who run beta 4 of 4.7 in production as a native windows service.

The speed of Mercury/32 is now extremely fast, with the multithreading processing power and no gui-interaction 4.7 beats the ... out of any other direct tcp-server I've ever tested.

[quote user="mpaas"]We have an Email domain and now a new Telephone server with a fax function.

If a user wants to fax something, he has to send an email to .

Emails to this "domain" should use a special SMTP Client (it's a server in our internal network). All other outgoing emails should use the normal ISP Mailserver. 

So, is it possible to configure 2 SMTP clients in mercury.

Nope but if the fax.local domain is setup with an IP address and can accept mail to faxnumber@[<ip address>] the you can use the Petr Jaklin program WSENDEx.exe to send the mail to this account by using a domain account.   http://community.pmail.com/files/folders/mercadd/entry14131.aspx 

nice reagards

Marc

[/quote]

Rolf,

My problem appears to be solved.  Thanks for your suggestion to use Process Monitor.  That tool provided the clue needed to fix this.  

 For the benefit of others that may encounter a similar problem I am stating the cause and solution below.

Problem:

Temporary files were being orphaned in the SCRATCH directory at infrequent intervals.  On an even less frequent interval the result file returned from my policy program would not be included in the Policy Exception Notification email generated by Mercury in response to a non-zero return code.

Policy Program Design:

The policy program was using COUT to write to STDOUT.  The program issued a standard C call similar to this "freopen_s( &stream, argv[2], "w", stdout );" to reassign stdout to the file being returned to Mercury.  This mechanism worked about 99% of time.  When it failed it was because the return file was still busy even though the policy program had terminated.  It seems that there is a delay in Windows wrapping up the stdout file and if the delay was long enough Mercury would attempt to access the return file and be denied.  The end result was that the return file would be orphaned in the SCRATCH directory.

Policy Program Modification:

To fix the problem I modified the policy program to not use "freopen_s" but instead to use an ofstream definition of the return file and to redirect COUT to that file with this statement "cout.rdbuf(return_ot.rdbuf());"  Thus, the normal process of closing the return file prior to program exit ensured that the buffers were flushed and the file was no longer busy when Mercury resumed processing. No changes to any COUT statements had to be made.

Thanks the domain is now working fine :)

I think I might try the Linux route after I get everyone settled into the new system.  I'm on a deadline of getting this in place by the end of the day Tuesday.  I thought I had it squared away until I realized I had a mess with the 10 user limit.  I'm switching everyone to IMAP this weekend because I refuse to send more money to micro$oft.  The reason I asked about the shared folder in the earlier post is because I didn't need to log into the xp machine to view the archive folder over IMAP. 

For now it looks like I'm going to manually administer the individual addressbooks on a per client basis.  Being only 20 local users it won't be that bad.  Maybe this could be added to a future version.  When you create an address book, have the ability to browse to a shared version.  Luckly we don't have a heavy turnover.

Thomas, you fountain of widom you. YES, you have solved the problem.

I upped the MercuryE timeout to 300 seconds and it WORKED! My test message ot 1334 bytes took 203 seconds to be delivered, but delivered it was.

Many many thanks

Thank Peter. That was easy enough. I wish I would have done that a long time ago. lol

Could be some spambot trying to guess your SMTP AUTH passwords to be able to relay through your server. To find out for sure you would need a session log from when this happens. The IP address translates to 246.185.81.218.broad.xw.sh.dynamic.163data.com.cn, so unless you expect to get valid email from China that would support the spam theory.

If you use authenticated SMTP make sure your passwords are strong. If these attacks continue you may want to add the suspicious IP addresses to SMTP connection control  in Mercury (with refuse action), or block them in your firewall.

/Rolf