Hi

So the pdf file for mercury mail says that if you use the run a program option for a filter..

"The Run Program rule action will start the specified program, passing a temporary copy of the message on the commandline"

Well it's not working! I thought i was imagining it so i used a small test program i have for displaying parameters that are passed via the command line... no parameters are passed to it from mercury mail.

It does indeed start the program but it does not pass any parameters containing the email.

I really need this as i need to run a second mail server on the same machine on a different port (it's custom for another website and sends email via http to a url). If mercury can call another program and pass the email then the second program can simply pass the email via tcp connection to my other mail server.

Without the email being passed though, i'm unable to get this working.

Any ideas?

I'll have a look what's happening with the parameter for this action, but in the meantime you could perhaps try using a pre-filter policy instead. We use that to create archive copies of messages, and that definitely works.

pre filter policy...

I just need the thing to run - asap and reliably.

So far google can't connect via pop3... outgoing mail is pending.. i'm fed up with this software already.

Pre-configured it is designed to get a servers IP blacklisted for spamming. I came home to find over 15k emails have gone through it in just 1 day.

How is that possible with only users created on the system? - Oh.. you have to create an authenticated users file.. and duplicate the users names and passwords there too right... Now my server is blacklisted. Nice one.

This is badly designed, badly supported and badly implemented. I have no idea why xampp bother distributing it.

Sending email to google results in
TCP/IP error during processing.

DOES THIS SOFTWARE WORK AT ALL?????

If you are referring to the Mercury Mail Transport System software, it works great. It is very capable and flexible, which makes it a bit complicated to configure. Proper configuration is the key.

It is a shame that you had it configured as an open relay. It is quite surprising how quickly the spam bots can find open relay IP addresses.

You used the term "pre-configured". There is no such thing for Mercury. It is up to you to determine which modules you need, and then to configure each of those according to your needs.

Mercury works fine connecting to Google via POP3. The following configurations on the Google side are required.

• POP3 must be enabled.
• You must authenticate with a Google assigned app password.

I agree that support is limited. You are dependent on the Help files and the manual. This support forum is by volunteers. Forum members need a thorough explanation of what you are trying to accomplish, the specific problem you need help resolving, and what you have done so far to troubleshoot it.

We have no control of the preconfigured settings that comes with the xampp distribution. I'm afraid they may be severely flawed.

Well it doesn't connect well via SMTP! I keep getting TCP/IP errors.

Secondly when GOOGLE tries to connect to MERCURY (not the other way round as you suggest) their gmail web interface complains that it cannot establish a connection - even though my outlook (2003) can. But my friends device couldn't connect with a newer outlook and neither could his gmail. Very odd.

As for having to configure users twice - once for a mailbox and then again for relaying, that's just backwards. Not wanting to offend anyone but its true. The whole idea in programming is to avoid data duplication. A simple checkbox on the user editor allowing them to relay mail would have been great.

The manual is also confusing - authenticated connections can relay... but then only authenticated users can relay... so.. what does that mean? authenticated users can relay if its checked but otherwise only spammers can? lol. So not only does the manual need to be a bit clearer, it also needs to be shorter.

The interface is odd too. Quit it and you can run it as a service.. but to make changes you need to stop the service (thus no mail transfer) and run it as a GUI. That's old-skool! It needs to run as a service 24/7 and have a TCP admin program that connects to it instead.

Of course it doesn't help that the help files don't work on anything past WinXP.

Think I'll differ on your view with all respect. It may work great in your eyes but to me it doesn't. I wrote my own SMTP server a while back, it didn't have all the bells and whistles and is nowhere near being ready for a live environment but it worked out of the box with minimal fuss. What i do like about Mercury though is the extensive list of rules / actions. Even though the one this topic is about doesn't work, it's better than those on hmailserver.

From the XAMPP website's FAQs

Is XAMPP production ready?

XAMPP is not meant for production use but only for development environments. XAMPP is configured to be open as possible to allow the developer anything he/she wants. For development environments, this is great but in a production environment, it could be fatal.

I think, that says it all.

Any news on this command line feature not working? - Any messed up configuration files, or a bug fix?

Could it be that the version of Mercury in your XAMPP distribution is quite old? The Help system in Mercury has been updated to work in newer Windows version for many years now.

Well I've just tried the latest version of Mercury with the Run a program option..

Still no email transferred to my chosen program. It's quite a simple program in delphi, it simply parses the command line options and displays them in a TListBox.

Or am I looking at this a borked way? - maybe the email is transferred using stdin/out or something but not actually as a commandline option as the pdf help file suggests?

It would be superbly handy to actually have a little more information on this option provided.

So just to recap with what I want to do..
Mercury accepts email, parses rules, triggers my program and passes the email to it. My program then opens that email, parses it and forwards it via SMTP connection to my custom mail server on a different port where my mail server can then process it, stash a copy in the database and then forward it via http to a website url using the _POST method. It's all perfectly plausible too except that mercury isn't doing what it's being told via the global rules. It triggers my program but nothing is passed to it.

It would be really really really nice if someone could explain how this feature is supposed to actually work because from my mind it should be something like "project1.exe -email=<tons_of_email_text_here>" but then again if its working using stdin (which is not mentioned in any way shape or form anywhere in the documentation) then that would explain why it's not working.

Further update, I've now tried using

• mailtodisk
• mailcatcher
• sendmail

All of which use stdin to accept mail directly from the php executable. None of these acted on anything from Mercury.

My own program sees zero parameters passed to it on the commandline.

I genuinely believe that this option is completely broken or never finished.

Well as suggested by Rolf ages ago, I've kinda got it working via the policy tab instead.. but this then rules out any rules to be used which means it would generate extra CPU usage as my external program will be checking EVERY single email. If I have say 5 domains and only want to activate my email port-forwarding program on just a couple of addresses on one of those domains, I'm potentially scanning thousands of other emails for aboslutely no reason. Bonkers!

The policy tab isn't particularly helpful if i'm honest. To me it's a very basic "pass it to another program" feature.. but it's a feature that needs to be made available via a filter rule set so that it can be executed on demand instead of against everything.

I'll mull over whether I actually use this or not, it seems like a bad idea to me for the reaons stated above however given that Rolf and David do not seem at all interested in supporting the "Run a program" option and actually helping to make it work, I may well have no choice but to use this.

The documentation for the "Run a program" feature is terrible:

Running programs The Run Program rule action will start the specified program, passing a
temporary copy of the message on the commandline. Mercury will continue running after it
has run the program - it will not wait for the program to terminate. If you want to suspend
rule processing until the program has completed, you should create a second rule with the rule
action Wait until a file exists: when it encounters this rule, Mercury will wait a maximum of
two minutes for the filename you specify to appear on the system. When the file appears,
Mercury will delete it and continue. The intention here is that your program or batch file will
create a 0-length file as a semaphore to indicate that it has completed. Remember! Mercury
will delete the file before continuing – do not store any information you wish to keep in this
file.

Does this mention any parameters? No (not that there are any)
Does it mention stdin? No (not that it uses it)
Does it mention that it's completely broken and passes no email information via the commandline? Absolutely not!

I guess that you could pass a hard-coded parameter (eg save the email to a hard coded file name and then pass that in the "Run a program" action with the hard coded paramter) however if you're getting multiple emails at once all fighting for that one file name... you're stuffed. For the record, I tried all of the ~X, ~Y etc paramters mentioned in the policy instructions in the global rules but all that I saw posted as a parameter to my app was the path to the mercury folder. As a policy, these paramaters work well but in the global filters they are useless. Again, that's no use if i only want to run a program against emails that meet certain criteria.

That incomplete error logging that is being ignored is also not a good sign. I certainly could not justify purchasing a licence based on the glaringly obvious bugs in this software that go uncared about.

Over a year and still no news? - still no real progress?