[quote user="TheJJ"]

 My Spamhalter.ini:

[SpamHalter]<br><snip>

<br><b>TrainAlways=1</b><br>IgnoreWhite=0<br>ImageParser=1<br><br>[bayDynamic]<br>bayForcedWrites=1<br><b>bayNoSpamBoost=3</b><br>bayClasifyMaxTokens=20<br>bayUnknownProb=40<br>baySpamProb=80<br>bayMaxCorrCnt=10<br>bayOldDays=100<br>bayExpire=365<br>bayWhiteOldDays=100<br>CustomHeaders=<br><br>[bayStatic]<br>bayMaxLength=8192<br>bayMinTokenLength=3<br>bayMaxTokenLength=25<br><br>

Thanks for help,

 JJ

[/quote]

Spammers have got a bit smarter wrt bayseian filters by including more "good" and "random" words.

I recall the docs implying that the "bayNoSpamBoost=3" setting is to err

on the side of caution in a fresh install and should be modified to

suit after a bit of training. 

The 'bayNoSpamBoost=3' setting means that "good" words have 3 x the 'weight' of "bad" words, so spam with sufficient "good" words is passed as 'nospam'.

This, combined with "train always" means that your database is constantly updated with incorrectly classified spam mails, which adds the included "bad" words to it's "good" list and the effect snowballs.

To combat this I have adjusted my settings as below.

Part of my Spamhalter.ini

TrainAlways=1
ImageParser=1
IgnoreWhite=0

[bayDynamic]
bayNoSpamBoost=1
bayClasifyMaxTokens=30
bayUnknownProb=90
baySpamProb=40
bayMaxCorrCnt=50
bayOldDays=30
bayExpire=180
bayWhiteOldDays=365
CustomHeaders=

[bayStatic]
bayMaxLength=8192
bayMinTokenLength=3
bayMaxTokenLength=25

 

These settings work very well for our mail but may not necessarily work for you, YMMV. :)

Hi,

we run Mercury32 4.72 in NDS Mode on Windows Server 2008 with Novell Client 2 SP1 IR3. After some run time, the IMAP server seems to take very long to process new logins. It takes often 30 seconds, sometimes many minutes for a new imap login. Since most IMAP client regularly create new login connections during normal work, this has a serious impact on users. We use stunnel for ssl offloading and especially to use a correct ssl certificate, but the problem persists whether the stunnel runs on the same machine or on another.

Furhter things we see: Since login requests are not processed, the Mercury screen shows dozens of [Not logged in] connections, they often pile up faster than old ones are processed.

Any ideas? How can I check what takes Mercury so long?

Greetings

Markus Borst

Hi -

Sorry to re-open an old thread, but I'm having a similar issue with auto-replies, and changing ISP's isn't an option...

I've been using the same ISP for 14 yrs, and it does relay as long as "any" validly formatted e-mail address is in the MAIL FROM field when sending an outgoing message - just apparently not when the MAIL FROM field is empty (<>) as I've found out recently when attempting to use auto-reply.

Hoping to get more insight into why the MAIL FROM <> response doesn't contain a valid user.

Based on  the help file info - MercuryC / Forced SMTP sender  - it sounds like we should be able to always have a valid MAIL FROM user sent to the outgoing server for validation.

I've tried changing various settings, including adding various headers via outgoing rules for the AutoReply message that don't appear to be included by default in auto-replies ( Return-Path:, From:, Resent-from:, X-AutoForwarded: ) as well as adding the forced smtp sender, etc.

I guess my expected behavior, for auto-replies, would be for MercuryC to use either the "receiving" mail account name as the "MAIL FROM<>" account when sending the auto-reply, or use the postmaster / forced smtp sender account in the MAIL FROM<> field.

Is there something I am missing / some way to cause MercuryC to always populate the MAIL FROM, and / or any way to add the MAIL FROM user via outgoing rules (it's not a header, but is typically taken from the Return-Path or From field I believe).

Oh - and i can include a full connection log from my server to my ISP for an auto-reply if needed, but the relevant issue field is the same as Dave shows above - the empty MAIL FROM:<> response

22:25:28.265: << MAIL FROM:<> SIZE=676<cr><lf>

Thanks for any help anyone can give.

Chad

That works great, just what i was after. :)

Thanks again,

Troy

well thans for tryingto help me after 5 more hours of fiddlinh with it i used port 3476 on mercC and had it relay to my domain and it works now fully i can recieve and send mail to local and external thanks for the help and input though

Hey, Rolf, thanks a lot for answering.

I did not realise that the MX record order could be ignored.

We had locked down Mercury so that SMTP connections were only accepted from MessageLabs' IP addresses. However, because our staff use IMAP and they have dynamic addresses assigned by their ISP's for their home machines I opened it up again so they could authenticate and send mail. I'm going to lock it down again and update their IP addresses in Mercury as required.

This is the first email that has been delivered directly to our IP address. I guess we've been lucky that no more arrived.

Thanks again for the help.

Thank you, Rolf.  I had already tried putting in two forwarding rules and one of them didn't work.  However, after seeing your note, I tried again and the mail was forwarded to both locations.  Maybe I incorrectly typed something the first time.

Thank you

Gordon

Thanks for the reply.  I'll give these a try.

If it was me, I would delete the newly installed versions, drop the old versions into place, verify that they work as before, then run the upgrade over them to get the new versions.

Found out sumthin. There was a user that was draging and dropping received emails from there inbox to the spam Archive, and Drafts folder.Once i removed the emails from the spam account folders, the error went away.

Thanks,

Troy

Oh and I forgot to mention - no there's no real time av on either server

Sorry, found the issue.  When I had spoken with the admins at backscatterer, they said we were being blocked for backscatter, according to their info.  When I checked the configuration on our server and THEIR DATABASE, it looks more like the VRFY command was enabled (which it shouldn't).  I've got the system configured to not backscatter or send VRFY commands.  Thanks for your help and especially your patience.

I have quite a few IP access restrictions in MERCURY.ACL.  At times I'd like to temporarily remove some or all of the "denied" restrictions.  If I were to do a switch of MERCURY.ACL files, how can I get Mercury to re-read/apply the file without restarting it?  Thanks.

 - Vince

There isn't one.

Idiots should not run mail servers.

Read the help.

When you understand the concepts, you will know what to put in all the little boxes.

Thank you Thomas. I tried it with Pegasus as the IMAP client, and it worked immediately. Now I'll have to start tweaking with SSL etc, but the basics work.

 PS: Even SLL and configuring my cellphone was easy.

An entirely new mailstore is indeed in work for Mercury, but it's still some time until it's finished (it requires rewriting a very big portion of the code).

Would it be possible to use Thunderbird to first create the wanted folder structure and then transfer messages folder by folder, or is the structure too complex for that?

/Rolf 

This patch corrects a problem in the MercuryX Scheduling Module released with Mercury v4.72 which would prevent other modules from coming online at startup if the scheduling module was unconfigured. If you do not load the MercuryX module, you do not need to install this patch.

Go here to download:

http://community.pmail.com/files/folders/patches/entry24194.aspx 

It looks as if there was a problem with a .lnk file.  I had set up a link to Mercury's loader.exe in the system Startup folder and it was this .lnk file that was being flagged by HiJackThis.  I deleted the .lnk file and made a new one and all was well.  HiJackThis no longer complains.  What went wrong with the old file, I don't know.

Gordon

It's a very strange setup, but then again maybe that's what you want, I have no way of knowing. Anyway, disable the MercuryX module (it's broken in 4.72 and can disrupt other modules), If you actually want to send something from your very restricted localhost environment you should in Connection control check "Connections from this address range may relay mail through this server".

Does your ISP allow you to connect to an external SMTP server (mail.google.com) on port 25? If not you should probably use the SMTP server they provide for relaying. To get more information on what is happening you can specify a log file for MercuryC, and temporarily switch on session logging in MercuryC as well.

If you plan to run a mail server it actually a good idea to study the manual. 

/Rolf  

Sounds like the MercuryX bug as per this thread http://community.pmail.com/forums/thread/22605.aspx

Disable the MercuryX module.