Community Discussions and Support

The perfect forum for general discussions or technical questions about Mercury Mail Server.

0
-1
closed
tBB posted Feb 7 '08 at 10:57 am

[quote user="harkyman"]

looking into the default configuration of clamd.conf in the ./etc folder in the clamd installation, I saw that on Windows, clamd defaults to not using tcp/ip port for communication: it uses a socket instead.

[/quote]
This setting is actually the default for Linux systems. Sounds as if you're using the SOSDG distribution which still uses the Cygwin emulation layer.

Best regards

Nico
0
-1
closed
David Harris posted Jun 16 '07 at 3:45 am

Mercury/32 v4.51 is now publicly available.

Although on

the surface v4.5 will not appear markedly different from v4.01, "under

the hood" it's quite a different story. The code has been heavily

reworked in almost every area, focusing heavily on robustness,

reliability and performance.

A download link and list of new features in v4.5 is available at

    http://www.pmail.com/m32_451.htm

Starting

with this release of Mercury, the licensing model for the program has

changed. Mercury remains completely free for non-commercial use, but

commercial users will need to purchase a license if they wish to

continue using it after a 60-day evaluation period. We have attempted

to produce a licensing program that is both very inexpensive, and

completely non-intrusive. Details and pricing can be found here:

   http://community.pmail.com/pmail/MercuryPricing.aspx

Please

note that if you have a current support subscription at any level under

the old Pegasus Mail Support Consortium arrangement, you are

automatically entitled to a Mercury site license at no charge - please

contact me directly to arrange this.

A personal note: I'm

acutely conscious that it has taken an abnormally long time to get this

release done. One of the lessons I have learned from the problems in

getting v4.5 complete is that I need to open up the beta testing

process so that more people have greater access to betas and patches

more often. I will be developing a strategy for this over the next

couple of weeks.

Any problems or issues arising from this

release can be raised either on the public mailing list at bama.ua.edu,

or in the Community forums at our community web site,

http://community.pmail.com.

Cheers!

-- David --
 

0
-1

Hi i'm trying to set up squirrel and Mercury, the SMTP seams to receive mail okay but the mails stay trapped in mercury smtp queues they never get deposited/deleivered to individual mail boxes - so when a user logs onto the Squirrel system they do not see any mails - any ideas what this might be it's beeen driving me nuts !!

You really have not provided enough info. 

Does the MercuryS log show the mail has been received?

Does the mercury core screen show the mail being processed?

 

0
-1
closed
David Harris posted Jun 14 '07 at 6:31 am

[quote user="Graham"]Is there a way to leave mail on the ISP pop server after checking  with Mercury.[/quote]

It's on my to-do list, but it hasn't made it into the v4.5 release.

Cheers!

-- David --

0
-1
closed
axel posted Jun 13 '07 at 5:41 pm

Besides our normal SMTP server we get mails from a POP3 account and I wanted to install a content filtering rule which reacts on wrong HELO/ELHO when the mail arrives at the POP3 account.

I tried following rule:

if Header "Received" matches "*helo=*by server*"
ANDNOT Header "Received" matches "*helo=*.*by server*" weight 51 tag "wrong HELO"

but it is no working. If HELO is OK it produces "X-CC-Diagnostic: Header Received contains "helo=" (0)", but if HELO is wrong it does nothing.

As a workaround I am now using:
if Header "Received" matches "*helo=*by server*" weight 51 tag "received by server"
if Header "Received" matches "*helo=*.*by server*" weight -51 tag "HELO OK"

My question is, what is wrong with the first rule?

0
-1
closed
chriscw posted Jun 20 '07 at 2:11 pm

If its failover you want how about using VMWARE,  that would let you run Mercury in a virtual machine and set up another virtual machine, hosted on a different physical server, to take over if the first one stopped working for some reason.   Both servers could obviously use the same queue hosted on a NAS device somewhere.

 As soon as I can get my lot to part with £1200 for two sets of bundled virtual OS and utilities thats where all or servers hosting databases, email etc are going.   Licensing is per CPU not per core so we can have two systems running virtual server for that price plus most of the monitoring and failover utilities we could need.   This seems much cheaper than other automatic failover systems I have looked at in the past.

Starting Mercury on a new system is a fairly trivial task for us at least all we need do is copy of move the disk with our mail on, change to the correct IP address and start the server.   We have done this a few times now when hardware fails, it takes about 2 minutes to be running with our more critical accounts already accessible, doing it manually.
 

0
-1
closed
Rolf Lindby posted Apr 27 '11 at 11:59 pm

[quote user="Markus"]

I think I remember David talking about dropping cryptlib and transferring to openssl, but couldn't give a definite estimate if and when this would happen.

[/quote]

This is planned for Mercury v. 5.

/Rolf  

0
-1
closed
Owen posted Jun 8 '07 at 7:39 am

Thanks! Looks a good idea. I presume that a welcome message isn't sent if there's a welcome file specified.

0
-1
closed
Thomas R. Stephenson posted Jun 12 '07 at 8:29 am

[quote user="KeithW"] 

Thanx for the reply !!

I am being beat up trying to get SPF implemented and cannot get email to the MSN / HotMAIL domains working.  I was working thru the MicroSoft SenderID Wizard and it asked if those RFC's were fully supported,  I could not find any references on the web site so I posed the question.

[/quote]

 

There is something else going on here that has nothing to do with SPF.  I'm sending to both MSN & Hotmail (same place) and i have no SPF record at all.  What error are you getting when sending to these addresses?  What are you using for sending?  MercuryE?  MercuryC  If you do not have a fixed IP address or if you do not have a PTR record at all then you can be rejected by these MS systems.  In any case a session log is in order to see why you can't send.

 


 

0
-1

> For some reason I can't send from tbird to a client setup on mercury.
>
>
> I have domains on mercury as follows
>
> gibberish    mydomain.local
>
> moregibberish    192.168.1.100
>

Check the domains setting in Mercury.ini.  The domains sections should look something like this.

[Domains]
;Server : Domain
Server : Server
Server : mydomain.local
Server : [192.168.1.100

This mail mail sent to user@mydomain.local and user@[192.168.1.100] will be treated as local mail.  If you want to use the user@mydomain.local from other systems on the local LAN you'll need to setup some sort of local DNS.


>  
>
> No aliass or any thing else set except usernames.
>
> user names are
>
> fred and wilma
>
> I can send an email from mercury to fred and tbird will get it.
>
> When I send to fred from tbird I get an unable to relay for fred@[192.168.1.100]


This means that you do not have [192.168.1.100] in the domains section.


>
>  Any ideas?
>
>  
>
> Thanks for your help.
>
> Chris
>


0
-1

Clever! I have to say that I probably wouldn't have thought of that solution, even though it's a good one.

Just goes to show - the fact that I wrote the program doesn't necessarily mean that I know the best ways of using it. It's nice to have a creative user community. [:)]

Cheers!

-- David --

0
-1
closed
johnl posted Jun 6 '07 at 8:02 am

I can appreciate the effort you've put in to maintaining the legacy of code while supporting the breadth of email technologies in Mercury.  I'll keep an eye out for the support of various IMAP extensions in the future.  Thanks again for putting forth the effort to maintain this type of technology.  It's not too common these days to have the primary developer of a product dedicate the time to respond to queries like this.

John

0
-1
closed
Kevin Hastings posted Jun 16 '12 at 11:56 am

Okay, I don't have a fantastic solution, but maybe you could run your pop3 server on a different port from the default port, so attackers that are just guessing you have pop3 because you SEND / ACCEPT mail will be thrown off the trail.  Of course it will mean informing all of your users ... which might be a major headache!

*that's what I did when I was just starting and people were trying to connect to my pop3 and I didn't even have any users yet ! ! !,  I changed port and now get no unwanted attention* 

2.3k
13.66k
7
Actions
Hide topic messages
Enable infinite scrolling
Previous
Next
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft