Hi, Paul

Yes, this is all sorted now, thanks. The second domain went live last Monday and all mail is being handled from one server. You are right on the ball.

I realised that I would have issues with remote mail access and that, as you say, the name of the sending server does not matter. There are good reasons for separating the mail source for both domains, but I also decided that they were not important enough to warrant setting up what would be an overly complicated 'solution'.

I'm glad that I started on this as early as I did as it gave me enough time to realise this setup would require more effort to monitor and maintain than was really required.

Thanks a lot for replying - it's reassuring to read your response and to know that I got there in the end :)

Cheers!

I run Mercury on a dedicated Win7 PC, not as a service, logged in as a domain user (comparable to a standard local user with limited access to files on servers).  I manage it as the same user so thought the answer was "no" to your admin question but upon further investigation I see that I have granted full permissions to C:\Mercury by Authenticated Users.  So, admin equivalent permissions to Mercury without being a local admin.

This PC is not publicly accessible so granting full permissions to C:\Mercury by Authenticated Users was a lazy way of allowing access to whoever I might login as.

See if you can follow a submitted message in console windows (or log files) as it is received by MercuryS and picked up by Mercury core, there might be some useful information there.

Hi!

 So the problem was not in version 4.8, but previous version, and updating to version 4.8 fixed it? OK, thanks for the info.

:) 

 Jyrki 

I am having the same problem like you and I can't solved it. Did you solve your problem? Thanks

I don't know full details about error responses in Mercury during an SMTP AUTH exchange, but as far as I can see RFC 2554 gives no reason to only expect a 535 response in this case. RFC documents have their own definition of certain words, and RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) indicates that SHOULD is to be read as a recommendation rather than a requirement.

Thanks - indeed, I had missed that! The Mercury D setting is set to 60 seconds.

One thing I have noticed is that even when I configure outlook (or an android device) to leave a copy of the email on the server, it does not?

thank you

If the server supports "sieve", the mail client (also supporting this language/protocol) is able to control things like server side filters, auto reply for vacation and other useful stuff every user wants to control by himself without sending a mail to his mail admin ;-)

Konrad

Can you give us a little more detail about your configuration: what Mercury modules you are using and how the clients are communicating with Mercury.

There could be a problem connecting back to your public IP from inside the LAN, depending on router/firewall settings. Anyway, feel free to send connection details and we'll make some tests.

Try checking the log files for MercuryS (the SMTP server module) and Mercury core. You should be able to determine if the delay happens during the SMTP transfer or when the message is handled by the core process (where content control, SpamHalter and ClamWall are part of the equation). If we know it's in the SMTP transfer part you could then try temporarily switching on session logging while sending the same message one more time. If there are indications of problems in the log, like long delays at some point or error messages, that will show us where to look further. If not it's most likely a pure networking or antivirus software issue.

Thanks. Licence purchased!

Dear Rolf,

Many thanks for your answer, and for your help I am going to use this way (an alias with the IP)

Have a nice day

Thanks.

If you suspect that someone is using your server to distribute spam you should check relaying settings (Configuration/MercuryS SMTP Server/Connection control /Relaying control). At least "Use strict local relaying restrictions" should normally be checked. If on the other hand the empty message wasn't sent through your server it's obviously not something that you can block.

Additionally, there is an option in MercuryS configuration (Compliance/Restrictions to apply to message content) to refuse messages with no or empty Subject header.

Thank you very much

The FACT you sent solved totally our need and works just fine. It is perfect and just by adding one line in the Mercury.ini file

fantastic !

 Thanks again to you all 

David COHEN 

A public release of 4.80 is being prepared right now and should happen very soon.

Yes, I believe the "pre-release" is NOT the same beta "4.80" that was released in January.  At any rate, I think Rolf resolved a post or two ago..