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

[quote user="Greenman"]
Hi

How about an annotation for each connection control entry in the SMTP settings?

I was reviewing these and had to spend some time tracking down a couple of entries that I had made several years ago.

It would be useful if there was an extra column after Allow/Refuse called Notes or something similar. It would allow the entries to be quickly identified. It would also be useful in case a new administrator needed to quickly understand what each of the entries related to.
[/quote]
I realize I'm following-up to a rather old post, but I thought I'd throw in my 1.87 cents-worth (inflation, you know...).

What I do is, I keep a text file on a local system, in which I log each and every new ACL entry, including not only the "why", but also the "when" and all the supporting evidence I used to reach the conclusion that I don't want traffic from that IP range or network.  That way, if I'm ever asked why so-and-so can't send mail to my domain, all I need is the source IP (or often just the e-mail address) in order to not only answer the question, but (usually) mete out a bit of education regarding incompetent/malicious mail service providers & ISPs.

Alas, over the years that text file has by now grown rather huge -- just under 2MB as we speak.  So while it is still usable (specifically, full-text searches still run acceptably fast), a "better way" would be welcome.  I probably ought to put it into some form of DBMS (perhaps an SQL database); but converting it at this point would be a fair amount of work.  Still, if I had the database, then that "extra column" you speak of potentially could -- and IMHO *should* -- be a key into that database, which would make lookups even more painless.

That said, using the ACL list itself as the index would NOT be all that useful unless it could be sorted (presumably by IP Address) on-the-fly -- i.e., *without* shutting down and restarting Mercury.  If anything, that sorting feature in and of itself would be MORE useful, at least to me.  As it stands, I have to periodically shut down Merc, then MANUALLY sort the ACL file, resave it, then restart Merc, just to keep it from becoming an utter mess.  Pretty crude.

So my "vote" wold be to first make the ACL sortable from within Mercury.  *Then* maybe add the additional field.

It works well, kills most of the spam and just works... But I need to filter my IMAP Mail.