[quote user="briankelly63"]

Is this limitation still exist with the 4.62 release. ie: do you still need two entries?

 Yes, you still need two entries

Thank You,

Brian

[/quote]

Hmm probably an oversight during testing. I have this too in my logs during the beta periods in may. It shouldn't be reported as abnormal.

However after David fixed the last memory issues with his memory tracer we haven't had any reason to automatically restart Mercury each night.
After having shut down this feature we have no abnormal terminations in the logs.

Also, if all your users are all on a local network (or known ip addresses) you can set up a mercS transaction filter to reject (& blacklist) MAIL FROM local users.

e.g.

 M, "*@your.domain*", BS, "554 Fraudulent MAIL FROM"

Just make sure to exempt your local ip's from the transfilter in the SMTP - Connection Control tab

I have a couple of users outside on dynamic ip's so have put exceptions for them BEFORE the reject rule

 M, "*dyn.user@your.domain*", X, "MAIL FROM accepted"

This leaves a hole in this method but these particular users don't get hit much and Spamhalter has cleaned up any that did get through like this. 

In this case it appears to be Mercury answering on port 110, though. As Thomas said the best thing to do is to check the logs.

/Rolf 

[quote user="PaulW"]

[quote user="Thomas R. Stephenson"] I'm not saying that Graywall does not affect the level of spam received via SMTP, it does.  However it's getting less effective based on my data.[/quote]

How effective it is surely must be to do with how the spam is being sent.  For me greylisting is still very useful against botnets of compromised user machines, but it has never been much good at stopping open relays or compromised servers.  I get quite a bit of that type and since they *are* proper servers, they will retry and get around any greylisting software.  For that sort of spam, you have to trust in DNSBL or other methods.

[/quote]

Looking at the connecting IP addresses of the sending systems it is apparent to me that many of these are coming from a botnet machine.  Based on the IP address I would probably would be able to block many of these if I were to use a blacklist listing the randomly assigned IP addresses but that would block many SMTP servers as well sending good mail. 

Like I say it has reduced my level of spam coming in directly but there are more and more spam systems that retries as required by the RFC.  Also it appears that the spammers are sending their spam through the infected systems SMTP host as well and these systems always retry.

This is all pretty academic anyway, 99.8% of the spam never gets to the user mailboxes anyway since it's blocked by POPFileD. 

Hello Thomas,

 using LDAP synony doesn't mean to implement LDAP on your Server. David calld it (I think so) that way, because the attribute was introduced with the LDAP Support of NDS. Pmail / Mercury use native NDS call to access that attributes. My tests also show, that both programs use the same Attribute: Internet EMAil Address in NDS Schema, which is mapped to the LDAP interface of NDS to the Ldap Attribute mail.

I recommend to either not load NLDAP.NLM if you don't use it (no Imanager, no Ldap contextless Login, no ....) or to configure your Firewall (FILTCFG.NLM) to not allow Ldap from outside. The last is what I do.

 Klaus

Great! [:)]

[quote user="Moshe"]

Hi Thomas,

I did enable the password feature and am using the correct syntax in the "to" field ( where "spam" is the account, "password" is replaced by a real password and the "site" is replaced by the site name).

 The thing is, the spamhalter config page says "password for offsite corrections" and I do specify the password...

 I am sending the correction mails using an authenticated (password on SMTP) account.  I'm using the same domain for both the server and the mail account.

I'm still confused as to what's wrong.

[/quote]

As am I.  I do exactly what you are doing when sending the mail to Spamhalter.  The logs show that the correction is being made using the password.

D 20071116 110119.824 MG000004 Mercury version >= 4.1
D 20071116 110119.824 MG000004 jobfile: C:\MERCURY\QUEUE\MG000004.QDF
D 20071116 110119.824 MG000004 spamdir: \\THOMAS\SYS\MAIL\6000001
D 20071116 110119.824 MG000004 nospamdir: \\THOMAS\SYS\MAIL\7000001
D 20071116 110119.840 MG000004 origin by MercuryD
  20071116 110119.840 MG000004 from: support@tstephenson.com
D 20071116 110119.840 MG000004 > Internet sender
D 20071116 110119.840 MG000004 > Need to test
P 20071116 110119.840 MG000004 Correction enabled by password
_ 20071116 110119.840 MG000004 Correction request saved as: \\THOMAS\SYS\MAIL\7000001\AAB85WGU.CNM

My only guess is the password is wrong on your setup..

You're right, I put a wrong CIDR notation for my own local network in SpamHalter config!

Now everything is working as expected. Thank you for your help !!

 Thanks I'll add that rule !

[quote user="tkoppy"]

Is there a way to increase the limit of out going emails to more than 100?

I'm using  Pegasus 4.41 and Mercury 4.52

Distribution lists in Pegasus will not work if over 100 names

I get 550 5.5.3 Too many recipients.

Thanks

 [/quote]

This error message is coming from the receiving host, there is no limit in Mercury/32.  You might want to try using the explode (fanout) option though to break the list into a number of messages.

 Explode submissions  For large lists, it can be significantly more efficient to send the message out to several chunks of the subscription list instead of simply generating one large message, since doing so allows multiple SMTP processes to handle the mail at the same time. If you enter a value here, Mercury will "explode" messages sent to the list into that number of outgoing jobs. This setting can have a dramatic impact on list delivery if you are using the MercuryE SMTP end-to-end delivery protocol module. You cannot explode a submission into more than 20 jobs.

Archive viewing for mailing lists is definitely on the to-do list.

Cheers!

-- David --

I remember screwing around with something about time in the Core config box.  I just reinstalled the mail server, which I can do because I'm the only one using it so far, and was able to send and receive email.  So, between this and the open relay problem I had, everything appears to be working and in fine shape (cross your fingers). 

Thank you so much!

I haven't seen this error message with any version of Mercury, so I don't think it's version related. The message indicates that some file I/O operation caused an unhandled error in the program, which made the program close down.

Run Chkdsk or similar tool to make sure there are no filesystem errors on the disk, and check that there is no other process running that might interfere with Mercury's file access (for instance an anti-virus program).

/Rolf 

Hi David,

in case you can't change it (I understand your reasons but somewhen you will have to make the switch) how about mentioning it in the very top of the example TRANSFLTR.MER and the help (and of course in the KB article [;)])?
It saved people a lot time. Especially the ones giving your server a first shot (which led to a broader user base and hopefully more revenue).

Thank you, Rainer

The bug in TRANSFLTR.MER is still here in Sept. 2014.

I try

to run webmail Roundcube as a client (SMTP, IMAP) of Mercury, on the

same machine as Mercury: so the connections of Roundcube come from

127.0.0.1. The filter described above, in TRANSFLTR.MER, blocked

Roundcube from talking with MercuryS, so I simply removed it and the

problem was gone.

Thanks, Thomas. After experimenting with a mailing list it's not going to do what I would like, so I'll stick with forwarding and the SPF users will have to remember it doesn't work for them. 

SPF seems fundamentally flawed in matching the original sender's address with the latest server to handle it, which breaks forwarding. I could see the point of matching the original sender with the original server but I suspect it would be more complex to implement.

> Thank you for your large effort in investigating my problem.
>
> I have no idea about your low level tcp-ip-solution.
> I access the mail directly on the computer where mercury sits (XP Home SP2)!
> I use Imap just to access the mail sometimes on a laptop, normally I work directly on the mail server.
>
> The next thing what I do not understand: If I move the mail to another
> Imap-Folder, I can watch the jpg with no problem!

This is what I find strange.  I can view these message attachments you forwarded to me without problems with WinPMail, OE, Outlook and Eudora via IMAP4 but I cannot do this with Thunderbird.  WinPMail in direct access can view the attachments also without problems.  Apparently there is something about this message that is causing a problem with Thunderbird.

All the clients, even Thunderbird, can view the attachments in the message you sent me via the ZIP file.

>
> Maybe I will compare the Imap-Log-files for this behaviour and tell you some results.

Not sure this will help at all since all of the other clients do not have a problem viewing this message via IMAP4.

>
> Best regards again, Walter

If the installation is correct ClamD and FreshClam should be started once (with Mercury), not for every message. FreshClam will then get new virus definitions regularly.

Try updating to the current version of ClamAV (http://hideout.ath.cx/clamav/), and verify that you have the right paths in conf files and in ClamWall.

/Rolf 

Thanks David.
The email does eventually go.. But normally it takes 3 or 4 retries.

A couple have gone out first time this morning.. !! Maybe they've sorted it ?

 Thanks again.