In the MercuryS config, Compliance Tab, "Refuse mail with no date header"

I kinda figured. problem solved anyway, im just using my isp as my smart host for mercury c.

-Jcampbe

I was also experiencing this with my Palm Treo 700wx and a few other windows mobile devices. I have applied the beta patch and all has been working without issue for a few days now. Thanks so much David!

 

Here is the follow-up:

With ClamD working properly and no

content control to worry about, 1313 messages of about 10kb to active addresses on

our main mailing list passed through the core process in just under 8

minutes. The list is still running as a VERP list and this is with ClamWall also scanning all outgoing mail. This is running on a 2.8Ghz P4 with 1Gb RAM, running on Server

2003 SP 2.

Very impressive indeed. Thank you, David 

Yes indeed we have done this and it does work.   It was a few weeks back but feel free to mail me chrisc@wwl.co.uk if you have any questions you think we may be able to answer.

Thanks, Eduardo! 

[quote user="howard"]

OK sorry - think I found the answer in an earlier post ( was stressed and failed to spot it at the time!)

The  'Accept mail for invalid local addresses' tickbox  seems to do the trickin MercuryS - but does that apply on older version ( Novell version 1.48) - can't see  the line in the ini file?

[/quote]

The line in MERCURY.INI is Allow_Illegals : 0 and is in the [MercuryS]  section for v1.48. If this is turned off (off =0, on=1) then MercuryS does the rejection and the bounce goes to the connecting system and not the MAIL FROM: address.  If this is a spammer it gets dropped on the floor, if this is a good server the server sends the bounce message back to there sender.

 

Rules and policies are executed in the core module in Mercury, so once a message has been handed over to MercuryC or MercuryE for delivery it's out of their reach. It might be possible to create a function like the one you describe using the new daemon interface, but as the specifications haven't been released yet I can't say for sure.

/Rolf 

Came over this problem in 4.52 just now. Checked any combination of current releases of cl32.dll and cl32ui.dll I could find, but no one worked. Then I replaced the newer versions wiht those from Mercury 4.01. That worked a little better, Properties Bottomn now works, but shows incomplete info (no Info for what the certificate is good). But no Startsl connection. Debug log:

 13:59:38.234: Connection from 11.22.33.44, Mon Sep 10 13:59:38 2007<lf>
13:59:38.234: << * OK xx.xx.de IMAP4rev1 Mercury/32 v4.52 server ready.<cr><lf>
13:59:38.234: >> A1 STARTTLS<cr><lf>
13:59:38.250: << A1 OK Begin SSL/TLS negotiation now.<cr><lf>
13:59:38.250: 21: Error -2 adding socket to CryptLib session (locus 0, type 0, code 0, '')
13:59:38.250: --- Connection closed normally at Mon Sep 10 13:59:38 2007. ---
13:59:38.250:

 

Thank you Marco for pointing this out.

Licensing has changed, the current info on this matter is located here at the community under the Mercury pages:

As for the FAQs and the whats new - this will be corrected.

Are you sure there isn't some kind of rights issue? The error you're getting means that the installer can't actually see the file MERCURY.EXE in that directory.

Cheers!

-- David --

Thanks for the suggestions about SquirrelMail and Telaen, I am looking into getting a web server with PHP set up inhouse here to support them.

 Meanwhile the SMTP problem is solved it was an issue with the way our firewall was set, it only allows connections from our ISP's relay system.   They have a secure SMTP relay we can use so that is what we are doing as the firewall setting would seem to give us extra security.   Thanks for all the help we got on this.

 

[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

I see that it is now available as a download:

 http://www.ararat.cz/download/graywall.pdf

You really should get a static IP.  If you can't, then that's another good reason for using an SMTP relay service.

 

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 --
 

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?

 

[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 --

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?