Yeah, I put "admin" and it worked. As the next filter, I also told it: "delete the message" because I didn't want it to try to resolve the domains and relay it.

That should help me a lot.

Thanks,

421-4.7.0 [68.84.251.204] Our system has detected an unusual amount of<cr><lf>
15:46:41.741: >> 421-4.7.0 unsolicited mail originating from your IP address. To protect our<cr><lf>
15:46:41.741: >> 421-4.7.0 users from spam, mail sent from your IP address has been temporarily<cr><lf>
15:46:41.741: >> 421-4.7.0 blocked. Please visit >
15:46:41.741: >> 421 4.7.0 to review our Bulk Email Senders Guidelines. 16si20569308pzk.52<cr><lf>

 Ah ha!  So i'm guessing gmail is blocking my email thinking it's spam. 

You got it and you really need to check out your IP address on blacklists as well. I just did a check and it appears that your IP address is on a DUL blacklist so you'll never be able to use MercuryE successfully.  You should convert to MercuryC and send through your ISPs SMTP host.  You are also on the FIVETEN blacklists but nobody same ever would use any of the FIVETEN blacklists to block. ;-)

IVETENWEBFORM		LISTED	miscellaneous address blocks that have sent spam here Return codes were: 127.0.0.2	86400	109
SORBS-DUHL		LISTED	Dynamic IP Addresses See: Detail Return codes were: 127.0.0.10	3599	375
Spamhaus-ZEN		LISTED	Detail Return codes were: 127.0.0.10	900	391

And i'm guessing i cant receive email because of what my MX servers are set as?

This needs to be fixed, the MX host should be pointing to your host mileka.com.  If you remove them entirely it will work as well.  That said I cannot even ping mileka.com or 68.84.251.204 so there is some major problem with connecting to you host as well.

1. See main help index ("Using the Mercury/32 loader utility") for a detailed explaination

2. Don't know, sorry.

3. I only know the -P parameter in order to specify the physical processor to use for Mercury.

Sven

Thank you for the tip Thomas.

I did not think of going the policy route. I will dust off my Pascal routinges and set to work. Because all of the messages come from the same source and should be similarly structured, it should be a relatively straightforward operation.

If the backup is at cause, you should probably see a file conflict occur. Filemon from sysinternals will show this for you.

Split the logs automatically into months in Mercury.ini with ~ 

like: logfile: D:\mail\logs\sys~y~m.log # Traffic logging file

Makes it much easier to maintain and purge old stuff.

Thanks A Million,

My server board went Kaput today, Foxconn G31 Micro for the 2nd time,

I am ordering an Intel G41, I hope it works better. Untill then, See you later,

Again, Thanks for the help.. I look forward to working with Mercury.

The original idea with an alias should work as well. The alias should be:

alias - the sender address you use

real address - your local mailbox name (without any domain part) 

This will, however, make it impossible to send any messages to the real external "sender address" through the Mercury server, they will all be redirected to your local mailbox. 

/Rolf 

The larger the inbox the more impact there is on performance. 4.6x and later are much faster in regards to all protocols, but especially from 4.0 to 4.6 there are so many stability fixes and performance benfits that there is every point in upgrading and getting a license.

Ok, thanks very much Rolf.  I'll revert to clients tech support with your findings.

Ron

Peter,

As instructed, I changed the "Mercury.ini" entry to "# MercuryX" so that the module doesn't load when I start M/32, but how does that help..? I need the scheduler to be working.

So, I enabled the MercuryX module and restart M/32... Guess what..? Nothing works again.

M/32 is not loading in "Off-line mode". It is already in "On-line mode", so I selected "Off-line" and On-line", but it makes no difference.

I'm going back to v4.62... Sorry.

Regards. SJS. 

Restarted Mercury host computer. All mails now delivered.

I checked the port status both with Mercury running and shut down, using both TCPView (thanks, kwikzilver!) and Telnet, and can confirm that Mercury is the only program responding on port 25.

-=Glen

Thank you Chris. I rather suspect that it may be a client problem, give that I am seeing different issues, depending what computer I am using and which client.  All seems to be working fine at the moment, so I'll just keep an eye on it.

Gordon

Thanks Peter.

It appeared that step 2) was not necessary, because during the upgrade Mercury had to be stopped again.

But for the rest the upgrade went smoothly.

You are running an open relay.  Use Configuration | MercuryS and turn off relaying and turn on strict.  Use the ESMTP Authorization to allow authorized user to relay.

Hi!

In the last few days a have had a new problem with Mercury v4.62. All my

LAN IMAP connections could not get through to Mercury. I saw the user

log-in try in the IMAP status window of Mercury but the connection

failed and the user did not appear in the upper section of the IMAP

window. The session log brought up the following problem:

...

11:54:11.187: >> 1 capability<cr><lf>

11:54:11.187: << * CAPABILITY IMAP4rev1 STARTTLS AUTH=PLAIN

X-MERCURY-1<cr><lf>

11:54:11.187: << 1 OK CAPABILITY complete.<cr><lf>

11:54:11.187: >> 2 STARTTLS<cr><lf>

11:54:11.187: << 2 OK Begin SSL/TLS negotiation now.<cr><lf>

11:54:11.265: 20: Error -3 creating CryptLib session.

...

This error does only appear within the LAN. All connections from the

Internet did not show this problem.

As mail client, we use TBird over SSL with stunnel for the IMAP

connections. So I use the setting "use ssl" but not "disable plain text

login".

After restarting mercury the problems disappears and that brings me to

my second question:

How can I safely restart mercury without any harm to the active user

accounts? Restarting Mercury with active IMAP connections always results

in damaged mail accounts (my users reported that everything gets mixed

up and that the mail subjects did not fit to the shown mail message text

anymore...)! How do you solve such problems and restart the system with

users all over the Internet?

Thanks,

Konrad

<cr><lf><cr><lf><cr><lf><cr><lf><cr><lf></lf></cr></lf></cr></lf></cr></lf></cr></lf></cr>

[quote user="Thomas R. Stephenson"]

......

> In the second step i cancel the mercury and restart the server.
> After this i must do the two steps again. Is that normal? The older
> versions don't need the procedure, to go online.

No this is not normal but for some reason it does this for some people when using MercuryX at least.

>
........
[/quote]

Thanks again Thomas,

after i have deactivate the MercuryX, the Moduls are going only directly on startup. 

[quote user="Rolf Lindby"]

Apparently the file ..\Mercury\Mail\PMAIL.USR had been damaged. It's difficult to say why but unless you had a Windows crash recently it might be good to run Chkdsk and to make sure there is no real-time antivirus program scanning the Mercury directories.

/Rolf 

[/quote]

Indeed!  I had trouble with that file disappearing a couple weeks ago when I installed Pmail 4.51.  I used Pmail to rebuild it but didn't add the user in question.  Mercury must have already had the user info and so didn't miss it.  Do both Mercury and Pegasus rely on that file?  That seems odd.

oh crap: I split the posts (can't undo) but somehow your last reply stayed here... - Glen could you re-post the above to the newly created thread?

If you have very heavy loads on your system, or you feel the need to upsize your solution you can consider to split your install. Either by dividing the users on two servers, or dividing the services on separate servers. By separating the services mx-inbound, and smtp-host for your users, you divide the traffic. By splitting the user base on two separate servers only half your user base will be impacted in the case of a failure. When putting the mail-directories on a share you get overhead that is unneccessary, plus the possibility of a single point of failure - which you also do not need.

Mercury is file based - by keeping a nightly copy of an empty Mercury configuration file/directory tree (meaning all config files, but not cnm files - ie the actual e-mails) you can jump start Mercury from last night onto another computer within 60-seconds in the event of a hardware failure. If you also use redundant MX-hosts, with Petr J.'s daemons, you will receive e-mails at all times.

Most important is the entire chain of dependencies, from actual cabling, power-supplies, grounding, cooling, IP-numbers, to DNS configurations, firewall rules, software setups, file placement etc that you need to analyze - any single point of failure that can occur is likely to occure one day. The only thing that counts is how long it takes to be back up and running again, and from that standpoint you should make your analysis and foundation for redundance decisions.

Good luck with your investigations, and please let us know your findings.