Good and Bad News!

First, the bad news is that the trailing asterisk in  .ru/B*  did not help.

In the above two rules, each of the 13 caught by Russia was

also caught by Russia B.  Each of the 12 missed was missed by

both. 

Good news is, after closely analyzing the hex in what was caught and missed, I think I finally figured it out.

The catch is when there are 2 CRLF adjoining the .ru:     www.somewhere.ruCRLFCRLF next line may be blank or may have text CRLF       (or sometimes no next line at all)

The miss is when it is followed by only 1 CRLF:              www.somewhere.ruCRLF  (next line is  blank in the ones I looked at) CRLF

 So, it appears the bug is not at EOM, but at the end of a line.

Mike

[quote user="jessicarabbit"]The ClamAV world seems in flux. ClamAV now seems to be Immunet.[/quote]

ClamAV is still ClamAV and they produce a Windows version of the product available . Immunet was a separate company who developed a 'cloud-based' Windows anti-virus product with ClamAV.  The Immunet version is not suitable for use with Mercury.

[quote]In an effort to get ClamWall running, I ended up downloading ClamWin and pointed ClamWall to the bin directory. The Question then became "Is it working". I have not figured out how to tell.[/quote]

ClamWin from www.clamwin.com is a different product that does not contain the clamD module that Mercury needs.

You can go to http://sourceforge.net/projects/clamav/files/clamav/win32/ and download the latest ClamAV version - *i386* for 32-bit or *x86_64* for 64-bit install.

(There are other Windows versions at http://oss.netfarm.it/clamav/ and http://hideout.ath.cx/ClamAV/, although the last one has not been updated for some time.)

[quote]One of the things I love about Mercury is what I call "Visibility". It is reasonably easy to tell what it is doing or not doing. Please extend this concept for what ever resource we are using to do anti-virus checking and display some form of verification, status, log entry, etc. that the virus checker is alive and processing the mail. This goes for the other add-ons as well.[/quote]

One thing you can do is examine the ClamWall log file regularly and look for error lines.  There may be tools out there to automate that task as well.

Mercury/32 V4.73 with Novell Netware NDS-module.

Because logging in from Mercury/32 to NDS is not possible, this forum gives the advice to login to NDS prior to starting Mercury/32 with an account reduced to minimum necessary rights. Created such an account in first step with security equivalence to admin-account. Now started reducing the rights for that account. Ran in a little problem:

Due to policies set with NCONFIG  all users get right to create mailfiles in all other users new mail directory. Obviously Mercury/32 needs more rights. If a mail arrives for a local user, it is placed in queuedirectory of Mercury as file of type QDF. Than the coremodul copies this file to new mail directory in users homedirectory (CREATE) and than tries to rename it to type CNM for Pegasus to recognize it. Therefore the right CREATE isn't enough ... the reduced account needs MODIFY (which amongst others includes renaming) too. But that may be a securityrisk (and I will have to change rights of every of my hundreds accounts by hand and do that with every new account).

So it would be nice if Mercury/32 copies the QDF as CNM to the new mail directory instead of copying QDF and renaming  it to CNM afterwards!

Have a nice chrismas

     Olaf

Much appreciated! I've forwarded it to David.

/Rolf

Hello.

The IETF has just published STD 72 (aka RFC6409) "Message Submission for Mail", which obsoletes RFC4409 (same subject) and is now the ultimate reference on message submission processes.

Abstract follows:

<quote></quote>

This memo splits message submission from message relay, allowing each
   service to operate according to its own rules (for security, policy,
   etc.), and specifies what actions are to be taken by a submission
   server.

   Message relay is unaffected, and continues to use SMTP over port 25.

   When conforming to this document, message submission uses the
   protocol specified here, normally over port 587.

   This separation of function offers a number of benefits, including
   the ability to apply specific security or policy requirements.

This Internet Standard therefore mandates a strong logical separation between MSA and MTA processes in a mail server, defined this way:

• Message Submission Agent (MSA):  An MSA acts as a submission server to accept messages from MUAs, and it either delivers them or acts as an SMTP client to relay them to an MTA.
• Message Transfer Agent (MTA): An MTA acts as an SMTP server to accept messages from an MSA or another MTA, and it either delivers them or acts as an SMTP client to relay them to another MTA.
  

(MUA is the Message User Agent, ie the user's email client with which the user prepares and submits email messages to the server.)

Now I amaware that Mercury may already accept mail from different ports, but this STD goes further stating that different sets of filtering rules and/or security policies should be applied when the server is acting as an MSA (port 587) or an MTA (port 25), which is a powerful idea to better fight against spam and such.

I am therefore wondering if we can expect a future release of Mercury to be fully compliant with this STD and implement such a feature.

Regards,

  Corrado

Hmm ... that's not Pegasus Mail you use to read your IMAP-Folder! Oh - I see - Thunderbird behaves like that.

On creating an IMAP-folder  with Mercury as IMAP-Server, in this process you decide, if the folder will be a folder containing mails or a folder behaving as a tray. Once a folder is declared as holding mails, you can't create a "trayfolder" or "mailfolder" beneath. Thunderbird knows about and disables that option in contextmenue if you are pointing to such a "mailfolder".

I asume you have problems to create any folder. In Thunderbird you have to rightclick on the name of that account at top of that mailbox. There you may create a folder and decide in course if it is a "mailfolder" or "trayfolder". Beneath a trayfolder you may create more folders of what ever type by rightclicking there.

bye    Olaf

Hi there,

may be it's best to illustrate the "problems"  with a sample (delivery confirmation):

With reference to your message - In Bezug auf ihre Nachricht<br><br>&nbsp;&nbsp; Subject: "=?UTF-8?Q?T=C3=B6st=C3=BCr=C3=A4?="<br><br>Your message was successfully delivered to the following addresses:<br>Ihre Nachricht wurde erfolgreich an die folgende Adresse geschickt:<br><br>&nbsp;&nbsp; <...@wiso.tu-dortmund.de><br><br>---- Beginning of message follows -- Anfang der Nachricht folgt ----<br><br>Return-path: <...@tu-dortmund.de> <br>Received: from ....uni-dortmund.de (129.217....) by wiso.tu-dortmund.de (Mercury/32 v4.73) with ESMTP ID MG000541;<br>&nbsp;&nbsp; 27 Oct 2011 08:26:36 +0200<br>Received: from [129.217....] (....WiSo.Uni-Dortmund.DE [129.217....])<br>&nbsp;&nbsp; (authenticated bits=0)<br>&nbsp;&nbsp; by unimail.uni-dortmund.de (8.14.5/8.14.5) with ESMTP id p9R6OKOZ016032<br>&nbsp;&nbsp; (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT)<br>&nbsp;&nbsp; for <...@wiso.tu-dortmund.de>; Thu, 27 Oct 2011 08:24:21 +0200 (CEST)<br>Message-Id: <201110270624.p9R6OKOZ016032@....uni-dortmund.de><br>From: "..." <...@tu-dortmund.de><br>Organization: Technische Universitaet Dortmund - WiSo<br>To: ...@wiso.tu-dortmund.de<br>Date: Thu, 27 Oct 2011 08:26:36 +0200<br>MIME-Version: 1.0<br>Subject: =?UTF-8?Q?T=C3=B6st=C3=BCr=C3=A4?=<br>Subject: =?UTF-8?Q?T=C3=B6st=C3=BCr=C3=A4?

1. The subjectline of the originmal message isn't decoded! In addition it will not be encoded, CONFIRM.MER (even the original - some german in here [:)]) has no headers vor MIME-Encoding, FAILURE.MER explicite US-ASCII. In my opinion it would be best to decode the subject (and all other encoded Headers), add MIME-Headers for UTF-8 in MER-Files and qp-encode it in the templates for confirmation and failure with characterset UTF-8. That should spread a wide amount of national characters.

2. The last line with placeholder "~G" is doubled? This "bug" has been in Mercury/NLM too.

just my 2 cent

    Olaf

Thank you Rolf.

I installed Mercury yesterday, and have too many other problems right now. I will come back to this option later.

Bernward

Is there a single application that never crashes, no matter what the circumstances? I think not.

In my experience (which is limited to the work environment, as I operate OS X at home), Mercury crashes are so infrequent, they are of no consequence. Most often it is the operating platform around it that causes the problems. This is like saying to automobile manufacturers, "I suggest you build a car that never crashes, no matter what the idiot who drives it does, and despite any pot-holes or sudden blind bends in the road." I say, keep up the good work, Pegasus Mail and Mercury.

Hi. That would be great.

Does it check for transient codes as well as failure codes?

I'll PM you with my contact details

Thanks!

We suggest that the following restriction for the Mercury "Local mailbox directory path" is removed:

It is currently a restriction of Mercury that the ~8 or ~N placeholder must appear at the end of the path.

Explanation: We have to move the mail system from a Netware environment to Windows/Linux.
The local users connect to their Pegasus mailboxes by Novell client, the notebook user via Netware CIFS-Server.
So the local mailbox of a user is located in  while using a notebook.

A change of the "Home mailbox location" in every PMAIL.INI affects the functionality of the IMAP4-Server.
Therefore it would be helpful to allow also the mailbox locating pattern \\server\home\~N\PMAIL and (for Samba) \\server\home\~N\.pmail inside the Mercury core module.

Torsten

Could a moderator move this to the wishlist section please?

Thanks!

That is actually being prepared! You can find more info about ongoing development in this blog post by David Harris from June 15th:

/Rolf 

[quote user="Chris Bolton"]I don't use SPF but am frustrated by the way it has broken what used to be a useful forwarding service I provided for a local charity.

Is there any chance that Mercury could include (SRS) as way to fix this problem?

Or does anyone know if it would be hard to write a daemon to do this?[/quote]

You've found one of the main weaknesses of SPF and why it has never really caught on.

Is it the charity's outgoing mail that can't use forwarding?  If so you may be able to change their SPF records to help.  If it is incoming mail that you are forwarding on to personal mailboxes, then there's not much you can do. :(

In a similar situation I set up POP boxes for the people to download.

Hi

I'd love to have an option for Mercury to authenticate on an ldap/ad server, this could be used to authenticate on a Windows server, it would just have to add a line to the passwd.pm file such as "ldap=" completed with the ldap/ad server address. Without this line Mercury would go back to pop3 or apop.

My allmost 1300 users would appreciate to have the same password to connect to the domain at work and to the webmail at home.

Thanks

Thanks a lot dilberts_left_nut and Rolf, it works and it seems to be easily scriptable.

Next step is filtering on the From: field, I will open  a new thread on the support forum.

Thanks again guys

The underscore seems to be a safe bet and the deliminator could be something as simple as a double underscore "__" or even "ZZZ" - anything that wouldn't be "commonly" part of an email address.  Ideally, having a setting where you could set your own deliminator would be best.

Windows itself sometimes writes file data into the registry for indexing for example the mui entries or shell folder specific stuff in the portion of the user registry. But this isnt required for normal program operations an the program will run with or without its existence.

A developer news page was just published by David Harris on the pmail.com site:

http://pmail.com/devnews.htm

The new mail store will as I understand it be able to fully handle folders within folders. In the current version of Mercury an IMAP folder can either contain messages or other folders, but not both.

/Rolf 

I just moved mercury/32 from a Windows Server 2003 machine to a Windows Server 2008 R2, which is a 64-bit OS.

Two issues surfaced, both of which could be worked around, but, for the record, might be resolved in a future release of mercury/32:

When installing on Windows Server 2008 R2, I wanted to install Mercury/32 in "C:\Program Files (x86)\Mercury\".  This was accepted by the installer, but after the wizard completed, it proceeded to install in  "C:\Program Files (x86)\" instead.  This behavior was reproducible, although I was able to spot the missing directory on the second attempt, since the wizard gives the opportunity to cancel the install after showing the full install path on the screen. I also tried using "%The immediate workaround is to install using the 8.3 version of the directory name (in my case C:\PROGRA~2\Mercury). The PROGRA~2 was discoverable from a command prompt via "DIR  /D /X" (run from C:\).  I'm not sure if a different system would give the same 8.3 result, so I recommend this procedure to ensure the correct directory is chosen. using the 8.3 directory name in the installer.

Running malias.exe from a command-line prompt produces a pop-up with the heading "Unsupported 16-Bit Application" with the body text "The program for feature "\??\C:\PROGRA~2\Mercury\malias.exe cannot start or run due to incompatibility with 64-bit versions of Windows. Please contect the software vendor to ask if a 64-bit Windows compatible version is available". I was able to copy my ALIAS.MER file from the old server, so this was a non-issue.  Running malias on a 32-bit Windows OS would work too, but eventually that might not be a practical solution for new installations.

[warning: soapbox] A general comment on new Microsoft Windows OS's:

While it used to be common practice (my 44+ years as a programmer are showing) to have editable, and volatile files in the "Program Files" directory (or other file system space reserved for executables), it is now frowned upon because it requires programs to have write-access to files, necessitating Administrator access on a continuing basis (as opposed to install-time admin access). In an ideal "Windows" world, Mercury.ini and other volatile files should reside elsewhere (perhaps %ALLUSERSPROFILE%\Application Data\Mercury\Mercury.ini). Thus the files installed in a "Program Files" directory would be read-only, and the application would not require elevated privileges on an every-day basis. It's easy for me to say this, but as a developer, the task of making such changes to a mature, but highly successful application such as Mercury32, is time consuming. I only make these comments in the interest of Mercury/32 continuing as a viable solution in its segment of the marketplace.

Rob