First off - thanks to both of you for really helpful replies. Let me see if I can clarify some things...

ASSP is basically a proxy server that filters incoming mail for spam and receives all outgoing so it can whitelist all addresses mails are being sent to. This has the big advantage that addresses users send mails to are automatically whitelisted for a year. As for the configuration - I'm aware that it is somewhat complicated, but this is the official configuration recommended by the ASSP documentation when ASSP and Exchange are running on the same machine, which they do in my case.

@dilberts_left_nut: I'm currently only worried about Mercury as a possible cause for an open relay. Yet I see your point that Mercury itself cannot actually be the problem.

@Thomas R. Stephenson: Thanks for the advice - I'll add the refuse entry. From your recommendation I take it that entries that are higher up supersede ones below, right?

Taken together, I take your two posts to say that Mercury probably is not the cause of my problem. That means I'll turn to the Exchange server and recheck that one...

Thank you so much!

Cheers,
Stefan.

Good point!  I hadn't thought of that :-)  I wondered why the reports had stopped!  So, I will have to reduce the reporting period, if I do a daily restart.  I have now set it to 23 hours, which will lose some of the count.  I wonder if it will handle reporting periods that include fractional hours.

Gordon

For maintenance of aliases I need to run sometimes the Mercury Nsynonym.exe tool.

This works fine on the Win2000-client, but is not working on the WinXP-client.

Any suggestions ?

Upgrade the client to v4.91??

To make this work you need to have MercuryE running in the domain1.com instance of Mercury to perform the delivery to the anotherdomain.com instance. If you are using MercuryC to send via an external server the local 192.168.1.100 address will not be found.

You should perhaps have a look at the WSMTPEx.exe program instead? See this thread:

/Rolf 

[quote user="Alar.Pandis@mtk.ut.ee"]

Forgot. ASSP is working together with Mercury/32.
Alar.

[/quote]

And against you, it would seem.

Mercury will not change the headers, only add a Recieved: line.

ASSP is my prime suspect, you should turn off ASSP and see if that solves the problem (of growing Ref header).

A valid message body must not have any single line greater than 1000 characters, so once the line exceeds this, it is no longer a valid message, which would explain why Merc can not process it correctly.

Sorry,

As Chris Bolton said, my  "myinternaldomain.com" is an internal domain that I had made up myself, not  a real "from" adress. So I use my external domain with the parameters of my ISP .

[quote user="GordonM"]A message was recently generated/received that had 80 characters in the local part, which is longer than the RFC seems to suggest.[/quote]

Well that's fine.  Although it says the local part should not exceed 64 characters, it also says  [quote]Every implementation MUST be able to receive objects of at least these sizes.[/quote]

It seems to me that Mercury is adhering to the standards.

Hello,

I have a user that wants to forward his incoming mail to multiple addresses.

Since this is not possible in Pegasus, I have created a mailing list in Mercury allowing posts from non members, created the subscribers, and in Pegasus set both local and Internet mail forwarding to this mailing list.

However, I can see in Mercury (version 4.52) that although the mail is forwarded to the mailing list, it is never sent to the subscribers.

If mail is sent directly to the mailing list, the mail is sent to the subscribers.

Am I missing something here, or is my set-up not possible?

I think I have found the option.  Checking "Suppress validation of "From" field when processing mail" in Mercury Core/General seems to allow any (invalid) "From:" address.

Gordon

If you're using popfile, either delete the user at the incoming server (which isn't Mercury) or continue to pop the incoming server, but direct the particular users e-mail to an account with filtering rule, that deletes any inbound messages.

Clearing the queue is the proper thing to do in a case like this. You can check the removed files in Notepad to see if there is any real message or just looping notifictions If there is any real message just put the QDF/QCF pair back into the queue folder. Then just delete the rest.

It's impossible to say what started the loop from just seeing that notification. If you check the MercuryE log you could perhaps find out what started it there.

/Rolf 

The username and password from the session are just Base64 encoded, not encrypted, so anyone using a Base64 decoder can read it...

Good to hear it worked with msendto.exe! 

/Rolf 

A session log will show you why - my guess is that your dynamic IP is refused, and you have to use MercuryC to relay via AT&T

An autoreply generated by Mercury should have a subject starting with [Autoreply], so this is presumably something else. Furthermore autoreplies are local to each mailbox, postmaster is not involved. Check the core log for clues, and switch on session logging briefly in MercuryE/MercuryC to find out what is happening.

/Rolf 

Han is correct. This part differs Mercury from some other products, that in my view have misunderstood the negative impact a direct association with a maildrop and just one e-mail address. Defining the maildrops apart from the addresses has the following benefits out of a server standpoint:

• makes it much harder to try and harvest maildrop/password pairs as the maildrop name isn't public
• eases the teaching that a maildrop is a "box" that can be associated with more than just one address
• is syntactically correct in correlation to most e-mail clients, that state Username as the equivalent for a maildrop, and hold separate settings for name and address.

The only thing I think is missing, is, that since the association with an alias and a maildrop is possible, it would have been nice to, via a setting, allow or disallow authentication in all modules between aliases and their direct associated maildrop passwords - as well as a setting enforcing strong maildrop passwords. Hopefully that will come true some day for both NetWare, Windows integrated and stand alone operations of Mercury.

Hello all,

Has any one successfully integrated Round Cubes plug-in managesieve into Mercury mail?

Is there a stand along windows server and/or script  I can use if it is not possible ?

Thanks for your time.

I sent numerous test messages and examined the logs and the headers without finding anything. Then I fell back on that old standby and reinstalled Mercury.

It all seems to be working fine now, whatever the problem was.

 Thanks Rolf for your suggestions, at least I understand a bit more about how it is supposed to work now.

Mercury in local mode can be started at Windows Server 2008 (32 bit tested) with the following variants.

A) Mercury as its own service with approved account
B) As a "Scheduled Task" after the System start
C) With NT Wrapper (Local system for Service, Login from Wrapper configuration, Best for Server 2003)

The GUI is in Server 2008 available through the Windows message "Interactive Services" or by Login with the special account, console 0 - see other posts in this forum.

Automatic login via the Netware client works no longer with Windows 2008, unfortunately also not with NT Wrapper,
although the Netware login is possible within the Interactive Service screen when accessing appropriate files.

Anyone who operates a Netware server, can use the tool Autologon from Sysinternals with a special Mercury user account.
This only works as expected if in the Netware client options in "Advanced Login" the Novell login is disabled .
The Mercury loader can be started with a scheduled task for the account after the Autologon.

Regards, Torsten

You should complete the domains section as well. IP addresses need to be enclosed in brackets, you should enter the hostname of the server, and if you have other workstations in your LAN you should enter your local IP as well. You can call your server "localhost" but I would recommend against it as it will only confuse you. So:

mail: mail
mail: drewclardy.info
mail: [76.184.46.42]
mail: [192.168.1.100]

And you should at least turn on strict local relaying restrictions in MercuryS.

/Rolf 

Copy and Move actions in filters are for local users only. For external users you need to use Forward.

/Rolf