There isn't enough information to say what could be wrong. From what you write it seems that the message is received by MercuryS but not sent on to the destination. Start by verifying that the local domains section of core configuration is correct (read the Mercury help for that section). Using the word "localhost" here is only likely to confuse you, so avoid that. Then send another test message and check Mercury core log and the log of the delivering module (MercuryE or MercuryC) to get more information, switching on session logging temporarily if necessary.
If it after that still isn't obvious what the problem is please post the contents of the mercury.ini file and relevant parts of the logs here, and we might be able to help you figure it out.
Here's a session log showing a valid SMTP sending process. I've highlighted the connecting string with a valid domain name and the SMTP address strings. When your application can do this it's putting out a valid message.
Connect to 'scruznet.com', timeout 300. 15:04:13 >> 220 scruz.net ESMTP Sendmail 8.8.5/1.34 ready at Sat, 20 Jun 1998 15:04:14 -0700 (PDT)\0D\0A 15:04:13 << HELO thomas.lmms.lmco.com\0D\0A 15:04:13 >> 250 scruz.net Hello stephens.sj.scruznet.com [165.227.102.91], pleased to meet you\0D\0A 15:04:13 << MAIL FROM:<stephens@scruznet.com>\0D\0A 15:04:14 >> 250 <stephens@scruznet.com>... Sender ok\0D\0A 15:04:14 << RCPT TO:<stephens@scruznet.com>\0D\0A 15:04:14 >> 250 <stephens@scruznet.com>... Recipient ok\0D\0A 15:04:14 << DATA\0D\0A 15:04:14 >> 354 Enter mail, end with "." on a line by itself\0D\0A 15:04:14 << From: "Thomas Stephenson" <stephens@scruznet.com>\0D\0A 15:04:14 << To: stephens@scruznet.com\0D\0A 15:04:14 << Date: Sat, 20 Jun 1998 15:04:12 -0700\0D\0A 15:04:14 << MIME-Version: 1.0\0D\0A 15:04:14 << Content-type: text/plain; charset=US-ASCII\0D\0A 15:04:14 << Content-transfer-encoding: 7BIT\0D\0A 15:04:14 << Subject: test\0D\0A 15:04:14 << Priority: normal\0D\0A 15:04:14 << X-mailer: Pegasus Mail for Win32 (v3.01b)\0D\0A 15:04:14 << \0D\0A 15:04:14 << test message body\0D\0A 15:04:14 << \0D\0A 15:04:14 << .\0D\0A 15:04:15 >> 250 PAA08117 Message accepted for delivery\0D\0A 15:04:15 << QUIT\0D\0A 15:04:15 >> 221 scruz.net closing connection\0D\0A
That is completely true and can be implemented easily to POP3 and IMAP4 the issue appears when the client try to use smtp ssl/tls and invoke the STARTTLS command. then the STunnel can not be used but only the mercury ssl/tls native mode with all the the actual constraints.
And you might not want to just start the GUI while the service is running. Use the Interactive Service Detection window and click on "View the message" to open the GUI. Or stop the service prior to opening the GUI manually (desktop icon).
Surely the most efficient answer is to forward the mail to a public folder. Only one copy of the message and everyone can see if it has been replied-to or not? Or they can grab it from there and move it into their own folder to "take ownership".
I think Thomas has pretty much answered everything! The main thing is to make sure that your Internet provider allows incoming access to port 25 on 86.95.162.33. If so computers around the world will be able to send you messages using the domain MX (pointing to mail.3d-printers.eu).
Mercury help recommends using 60 minutes between retries, or 15 minutes with progressive backoff. As Thomas already pointed out it defaults to 30 minutes. With so many servers using greywalling as there presently is I'll have to agree that this recommendation is starting to feel outdated.
A suitable solution should probably retry quickly a few times to get through greywalling and then increase the intervals to handle offline or overloaded servers in a suitable way, keeping on retrying for at least 48 hours.
How are you receiving your mail? If it is by POP3 through MercuryD you could start by increasing the download timeout considerably. To find out exactly what is stopping transfer switch on session logging for the next download session (but please remember to switch it off again).
I'm confused. Why would your ISP block INBOUND port 25? Most ISPs block OUTBOUND port 25 for customers with dynamic IP address - they don't want their customers sending spam. But if you are paying for a static IP address - and I assume you are if you are trying to run an email server - then you should be entitled to receive inbound on any port (perhaps subject to limitations on volume). Otherwise what's the point of paying them extra for your static IP?
As for outbound port 25, I would also question the value of a static IP address if they block it.
Encoding of mail messages is done using the MIME standard, in Mercury as well as in other mail server programs. It should make no difference what language is used as long as the right charset is specified; the mail server just forwards whatever it has received to its destination. It's then up to the receiving mail client to interpret and display the message correctly.
During transfer some content transfer encoding is applied to the contents of the message, like quoted-printable or base64. If you try to read the raw message before it has been decoded it's likely to look rather messy.
If you want all the details the rules for MIME messages can be found here:
Sounds like a good idea to make a collection of useful rule samples. There has of course been various examples here in the forum and in the Mercury mailing list over the years, but they haven't been collected anywhere. The wiki would perhaps be the best place for it.