Hi,

beside all the problems which are discussed here and which most probably arise due to false configuration of Mercury, I would like to state a successful update from 4.73 to 4.74 on a Windows Server 2003 R2 32bit. Update process proceeded without any errors (as usual).

The one and only conspicious thing which I have experienced is, that Mercury D (POP3 Client) is polling all of our POP3 accounts as fast as never before. It seems David has released all brakes. [;)]

Greetings

Joerg

I think I had this same issue and I was never able to figure out what was wrong but a reinstall did fix it.  

Jim 

PaulW - Four years ago I was playing with XAMPP and at that time it was not intended for use in a production environment.

Since it is almost inevitable that this will happen I would try the following:

put something like this in your rules.mer file

If not header "F" contains "postmaster@targetserver.com" SkipNext ""

If header "T" contains "source@sourceserver.com" SendMessage "source@sourceserver.com:error.txt"

If not header "F" contains "postmaster@targetserver.com" SkipNext ""
If header "T" contains "source@sourceserver.com" Delete ""

you would have to create the file error.txt  with the message you want it to say

An email that was just auto-forwarded to target@targetserver.com was not delivered.  It was probably too big.

I think that will work, perhaps others can expand on my idea.

Thanks!

As this already was answered by Paul Whelan in the Mercury mailing list I'll quote his answer here:

Orphaned *.qdf files are normally associated with a server problem - like

running out of

space. What are their dates?  Do they correspond to a problem?  Can you

confirm that they

weren't delivered?

They are the same format as new mail files (*.cnm) so you could rename them

and deliver

them directly, or put them in you own mailbox and forward them.

When the envelope information in the .QCF file is missing that is probably the best way to handle it. It would be possible to have Mercury core do the delivery by making .101 files (adding envelope information to the beginning of the file and changing the extension to .101) as well. The 101 format is quite simple. It starts with a line containing $$ and the sender address, followed by one or more lines with recipient addresses, and then one blank line before the actual message.

/Rolf 

Well, "OK UID FETCH complete" is obviously not an error, so it would seem that the software that is retrieving messages from MercuryI somehow is out of sync. Try restarting it.

/Rolf 

Ok i found my mistake...i needed to use SSL and not STARTTLS for MercuryC SMTP relay client.

Maybe I found where is the problem.

Here is the QCF/QDF of a test message in the queue folder of the first instance:

[quote]

ST: R 000000000000 00 000001 000000 000000

FR: <pinco.palla@pec.it>

DF: MG000022.QDF

FL: 65536      

OS: 120112111502

BA: <myhouse@blabla.it>

ES: R 120112111502

RI: 000.000.000.000 000.000.000.000 000.000.000.000 000.000.000.000

DI: --------.---

EA:

Return-path: <pinco.palla@pec.it>

Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000022;

   12 Jan 2012 11:15:02 +0100

From: "Pinco Palla" <pinco.palla@pec.it>

To: <myhouse@blabla.it>

Subject: prova 12genn h.11.14

Date: Thu, 12 Jan 2012 11:15:02 +0100

Message-ID: <00f201ccd113$0c3d9cd0$24b8d670$@palla@pec.it>

MIME-Version: 1.0

Content-Type: multipart/alternative;

    boundary="----=_NextPart_000_00F3_01CCD11B.6E0204D0"

X-Mailer: Microsoft Office Outlook 12.0

Thread-Index: AczREwwXeQjdos+cQ1+Jps9WknKHzw==

Content-Language: it

...cut......cut......cut...

[/quote]

As already seen, this message is moved by an outgoing rule to the

PEC-out mailbox, and sits there waiting to be picked up by Wsmtpex; the

following is the Header of the message found in the CNM file in the

PEC-out folder

[quote]

Received: from spooler by palla09.local (Mercury/32 v4.72); 12 Jan 2012 11:17:50 +0100

Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000022;

   12 Jan 2012 11:15:02 +0100

From: "Pinco Palla" <pinco.palla@pec.it>

To: <myhouse@blabla.it>

Subject: prova 12genn h.11.14

Date: Thu, 12 Jan 2012 11:15:02 +0100

Message-ID: <00f201ccd113$0c3d9cd0$24b8d670$@palla@pec.it>

MIME-Version: 1.0

Content-Type: multipart/alternative;

    boundary="----=_NextPart_000_00F3_01CCD11B.6E0204D0"

X-Mailer: Microsoft Office Outlook 12.0

Thread-Index: AczREwwXeQjdos+cQ1+Jps9WknKHzw==

Content-Language: it

...cut......cut......cut...

[/quote]

We can see that the "Return-path: <pinco.palla@pec.it>" line disappeared.

Now, as stated in the wsmtpex.txt file

[quote]

WSMTPEx looks into .CNM file and search for header 'Return-Path' for

SMTP envelope MAIL FROM address. Uses "<>" if none is found.

[/quote]

So, I was thinking that this may lead to the QCF with the empty "FR: <>" field in the queue of the second instance (and to the subsequet problems).

May this be so?

I'm wondering what to do... Any idea?

Best regards

Filippo

> i've got an old backup text export of my mails, i'd like to re import in any common format (like mbox).
> (haven't been using pegasus for years, since i got rid of windows.)
>  Could someone help me to identify the format, and suggest how to parse it, or convert it?

Not sure what you are saying.  How did you backup the messages?  Send this all to the a single text file?  Extract the messages to single message files?

Pegasus Mail messages are just RFC 2822 messages and the file extension can be changed to match the extension required for most any new mail of a mail client.

FWIW what operating system are you using?  Pegasus Mail (and Mercury) can be run on Mac/Linux using Wine.

SSL tunneliing via stunnel worked fine on my XP system - thanks for the head's up.

This is a much simpler solution than interposing Mercury in the path for our home

network, although I must admit I was also curious about possible advantages

and uses of Mercury in this environment - but that is a bigger project..

Thanks again for the quick advice.

Mercury supports any charset in messages, but not in IMAP SEARCH queries. In this case the query is for all messages (in the given range 1 - 64) that do not have the /deleted flag set. As there is no text part to match here I'm not sure why a CHARSET was specified at all. CHARSET is not a required part of a query according to RFC 3501, but the server is required to return a NO response if queried with a non-supported charset. It's then up to the client to adapt to that, but in this case the client simply repeats the exact same query one more time (hoping that the server is going to change its mind?).

I would suggest that you try POP3 instead of IMAP to access the mailbox, or see if there is an email client update or some alternative email client available. 

/Rolf 

If after making sure that the settings for Local domains and host name in Mercury core and MercuryE configuration are OK (have a look in Mercury help!) sending still fails the most common reason is that your Internet provider blocks port 25. Many Internet providers do this to stop spam bots, unless it's a business connection that is expected to host servers. If so you could try asking them to open port 25 for you, or you could switch to using the MercuryC module and relay mail through your Internet provider's SMTP server.

/Rolf 

Hmm ... you had Mercury/NLM on a Novell Netware server - right?

Now the servers os was replaced with Novell OES.... so there still is a NDS/eDirectory.

Have a look at the logs. Is MercuryS receiving mails? Or are they not delivered to users homediretories?

Anyway ... the WinXP has another IP-address than the Netware server before. Did you change the involved DNS-entries so that external SMTP-Servers know about where to deliver?

bye   Olaf

I hope the 2 Mails arrived 

I am ill i will go to bed now i am sorry but I have fever....

I will look if you have been able to help me tomorrow. 

That does not mean that you didnt help me until now.... I learned much the last 10 hours

Thank you!!!! 

PS: Is this a firebrigade car infront of which you stand on the foto? 

Hi Thomas,

thank you, you have given me the power to continue trying today ;-)

1. I can poll all mails from my official URL

2. I can "translate"  (alisa)   when I know the signs in front of the @

   Thanks a lot it works may be that the "userguide" what tro write in witch line is not so clear to understand, but now I know how to do!!!!

3. I can poll from my mobile with POP3 and!!!!  IMAP   cool!!!

4. There is one Problem still remaining, I need a "catchall" account for all mails which are

    not recognized by  the Alias tool.  It must not happen that a mail which is not translated by the Alias tool is lost. Please help me here .

Thanks for the tips in your mail. the rest seems to work fine!!!!!!

regards Schorsch 

Greetings!

 Thank you for the prompt reply.  As it turns out, the root of the problem was my own lack of faith.  Both systems are configured identically and both Mercury installations are identical.  And when I went into the system tools to investigate my problem, lo and behold there was Mercury running as a system service exactly as it should.  Apparently, all I needed to do was to reboot after copying Mecury over to the new server and that was the only thing I had forgotten to do.

 Sorry for the false alarm; I feel like such a Noob!  (And I've been around long enough that I should have known better!)

[quote user="FJR"]Donwloaded CalmAV from http://www.clamav.net/lang/en/about/win32 which gets ClamAVWindowsSetup.exe and got no warning from my Sophos!!![/quote]

That is the cloud version is no good for integrating with Mercury.

[quote]So I think it is not OK!!![/quote]

Maybe he has a corrupted version but I've never had anything bad from tBB at hideout.ath.cx, so it could be a false positive from Sophos.

[quote]In most cases you should download from original source![/quote]

In this case in would be  but that lacks some optimisation and a built-in service installer.  tBB's version (above) hasn't been updated recently, so I would try the version at http://oss.netfarm.it/clamav/ which is up-to-date.

> I'm at a loss. I'm not sure why I can send it to the postmaster, but
> none of the other accounts.

Not sure what to tell you here's a couple of things to try.

1.    Try using CTRL+Configuration+Manage local users and edit one of the users.

2.    Send a message to postmaster using the Reload users.

*   The mail server now has its own password file, created and
    managed on the "Mail server" configuration page. This is not
    covered in the help yet, but you can create any number of mail
    server passwords that can be used in a "PASSWORD" command to
    handle the new operations described below. If you have no
    password file, then no password will ever succeed and the new
    operations will fail automatically - hence the operation is secure by
    default. Mail server passwords are simply one-per-line (like
    everywhere else) and cannot contain the character ';' (semi-colon).

*   A new mail server command, "KILLFILE" has been added. This
    command allows you to manipulate the MercuryS killfile by mail. At
    present, the only implemented command is "KILLFILE ADD", which
    adds the parameter you supply to the MercuryS killfile. An example
    is at the end of this message.

*   A new mail server command, "RELOAD" has been added. This
    command allows you to force Mercury to re-read certain
    configuration files by mail. At present, the only implemented
    command is "RELOAD USERS", which takes no parameters, and
    tells Mercury to reload the user database, PMAIL.USR.

Both of these commands need to be preceded by a PASSWORD
command specifying a valid password from the password file created in
the mail server configuration dialog.

Examples (these examples assume that the password 'foo4u' is
specified in the Mail Server password file):

* To add *@163.com to the MercuryS killfile, issue these commands:

      PASSWORD foo4u
      KILLFILE ADD *@163.com

* To force Mercury to reload its user database, issue these commands:

      PASSWORD foo4u
      RELOAD USERS

The commands are not case sensitive - I've shown them in uppercase only to emphasize them.

I plan to add more commands of this kind - administrative in nature - and will be adding a level of discrimination to the password file to allow passwords to work only for certain types of operation (hence the reason why ';' cannot be used in a password).