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.

The Netware server NLM version doesn't, no.

But Mercury/32 running on a windows PC with the Netware Client works perfectly, you can even just use Mercury/32 for IMAP while still using the NLM version for everything else such as mail delivery, this was exactly how we were running things up till about a month ago.

David 

If you set up Spamhalter (or Popfile) you will be able to tell it what to inject in the Subject line of spams.

As a bonus you will also get MUCH less spam and MUCH less work trying to catch spam with CC rules [:)] 

I would try to see what happens.  It might have a problem with the ' in WHAT'S

if subject contains "can you tell me what*" weight 31

I think this incentive is good. There should be a difference between trial- or unlicensed installs vs. licensed. The licensing work in progress will most likely allow privatees to license.

A correction on MS is that you can download the patches manually and install them, Only a few require authentication to actually install, and there are ways to slipstream them onto a system as well.

Regarding a mailing list, for all unlicensed, the pm-news list and this community is still and most likely always around for announcements, but the latter is mainly a pull method, whereas a list is a push system. Now, email may not reach all, depending on content, format, sender hickups, receiver policies and other hickups that arise from time to time - therefore - a phone-home system within Mercury/32 that is allowed to contact and inform of new releases, then notifying locally that information exists is a very charming way to go. A such system must though be thoroughly tested due to its importance.

Many thanks... :) 

That seems to work well.

The rules look OK. Are you sure the message isn't whitelisted?

Cheers!

-- David --

Thank you, Thomas.

Hmmnn . . Maybe I've got it wrong, but it didn't find anything in my log files.

Like, everything zero.
I pointed it at the MERCyymm.LOG files in LOGS.

Maybe the logfile format changed in V4.51 ?

I have mailed robert, if no response, I will probably knock-up my own version.
As you mentioned, the log-file has the data I am needing, just gotta extract it.

No, you can't suppress these identification items. In actual fact, you wouldn't achieve much even if you could do this - all mail servers have "fingerprints" that are easy enough to track: variations in error strings, responses to different commands and so on.

The version information in the Received: header is very useful to me when doing support and maintenance, and I would be reluctant to remove it.

Cheers!

-- David --

Thanks I'm upgraded to 4.52 without any problems, thanx! mel.