I don't think there is any option for this, Mercury will always minimize to system tray.

Hallo Rolf,

have to answer myself, because I should have known, there's a logical error:

[quote user="FJR"]If header "S" contains "Bounced Message (Was:" Copy "Postmaster@mydomain.de"[/quote]

"Copy" is only to local users ... so should be one of these:

• If header "S" contains "Bounced Message (Was:" Forward "Postmaster@mydomain.de"
• If header "S" contains "Bounced Message (Was:" Copy "admin"

The last one got the price [:)]

Thanks

    Olaf

I get these addresses as the 3 first mail handlers for gmail.com:

A-record for gmail-smtp-in.l.google.com:    IP address = 173.194.71.27

A-record for alt1.gmail-smtp-in.l.google.com:    IP address = 173.194.64.27

A-record for alt2.gmail-smtp-in.l.google.com:    IP address = 74.125.193.27 

Maybe one of your name servers has some old records cached that aren't valid any more? 

I have exactly the same problem, but not with GMail but one customer. We do not get mails from our customer (and that is very naughty).

As I have seen it will be fixed in Release 4.80. What can I do in the meantime?

Thank you in advance

Chris

A filter rule to catch the hotmail replies and MOVE the msg to the user folder will not trigger the FORWARD file.

Thank you.  I will try turning on the Session Logging and looking there.

The working solution

... FORWARD "spam%nb"

That was it.

In the Mercury D configuration the POP3 account information is set up with a default user set to junk. Which I am assuming anything that comes in that is not addressed to a local user then gets sent to the default user.

Thanks for all you help, Ron

Hi Rolf,

Yes did the trick for at least my testmessages. Will see how it holds for real mailing list stuff but if your analysis is 100% correct it should also solve it for those.

Tnx a lot, and happy 2014,

<Erik>

Thanks for all your help. The "Accept mail for invalid local addresses" is unchecked and after testing a second time does seem to be working. Not sure why my first test didn't get the failure notification but the second test did get the expected "Delivery failure notification" message.

Ok, figured out my problem.

My handler was returning 1, instead of returning 0, which was why Mercury returned 235.
My handler should be returning 0, so that Mercury will return 334.

Issue resolved.

Hi Joerg,

I know about 4.8 and I can't wait to get it. My problem here is that I cannot switch back to a plain connection due to some dependencies on the provider side and also regarding security policies within our company. And a Mercury crash always causes unexpected behavior for regarding the users IMAP mailboxes and so on :-(

Konrad

Hallo Paul,

I'm afraid, Trevor doesn't use Mercury. His discription appears to me as if he simply uses the capability of Pegasus sending mails to local users directly to their mailbox. And these mailboxes seem to be local to the client PC or he hasn't created a mailbox for admin.

bye   Olaf

In the upcoming v5 of Mercury the UI will be separated from the background processes when running as a service.

Found.

The problem is when I attach a file either with -FB or -FT. It looks to forget that the body is an HTML.

Agreed... Solved!

Paul,

Thank you so much for your help! This fixed the issue that I was having and everything is working smoothly now.

Much Appreciation,

Ashley 

Yup the Users are there ...

Yes all is now working many thanks for both your responses!

I was looking at the wrong log file. The core module did not have log file turned on. I set this up for a test using ~D so I would get a daily log file. Since I most likely would not look back more than a week.

Thanks for your help, Ron