Thomas,

I will test this out.  Thanks very much.

MP 

I am currently running Mercury on a system where it is installed on the C drive, but Popfile appears to be installed on a Raid drive that is in a critical state, on the same machine. I need to install Popfile onto the C drive of the machine and am not sure how to do this. (I am moving all data off this raid drive as it is not worth keeping it any longer.)

I seem to have originally had Popfile installed on the C drive as old Popfile directory resides there now, but obviously predates the existing setup.

The version of Popfile that I am running is probably quite old, but I have been very wary of changing anything that was not broken. V 0.22.4

Among other things I have a neat link in my Pegasus Mail message where I can access my Popfile data for particular messages and correct any Popfile mistakes. Currently it looks like this:

X-POPFile-Link:    http://computername:8080/jump_to_message?view=xxxxxxxxx

Can anyone give me instructions on getting this working in Mercury from a different installation directory for Popfile, please?

Many thanks,

Ellie

[quote user="Thomas R. Stephenson"]> RFCs aside, it is just common sense: If the client sent a command (Delete Mail X) and the server confirmed the execution of the command
> ("OK"), then the server is responsible to retain this information.
> There must be a very specific reason for "forgetting" such a command long after the fact, and in this case, I cannot see such a reason.

The most common reason is that it is better to not delete mail from the server until you know that this was what was desired by the user properly closing the session.  The same reasoning is used for POP3 as well, all delete flags are removed if the session is not properly closed.

[/quote]

I heartily disagree: While this behavior made sense with POP3, where a session has a very specific, predetermined purpose (get list of mails, download certain mails, delete other mails, close session). If during all those steps an error happens, the client can start from the beginning.

The usage of IMAP4 is completely different: The session is left open for hours, or even days. The user does many different "transactions" during this session (reading a mail, moving another, going back to the first to delete it etc.). All this is interactive. Every single step must be considered as final, since after hours (or days!) in this open connection, you do not want your actions from way back to suddenly be reversed. Also, it's not like Mercury magically reverts your mailbox to the state before the connection was opened: Only the deleted flag vanishes. Copied mails stay copied, Replied to mails retain that tag etc.

IMAP4 is used hugely differently from POP3. The mailserver has to treat it that way.

Also, one of the new features of 4.73 was, that the index files are now written immediately. I think everyone took this to mean, that all relevant information is saved immediately. Change of a flag, especially "Deleted" is relevant information.

Greetings

Markus Borst

Also, and this is not small problem: Mercury crashes from time to time, mostly on corrupt mailboxes. In this case, the server has no chance to retroactively save the Deleted flag, it is simply lost without any user error at all. 

Maybe the _INBOX_.PNM file got corrupted: We noticed that if this file somehow becomes empty (0-Byte file), Mercury can never recover from it and listing the contents of the inbox gets inconsistent results.

If _INBOX_.PNM is empty, just delete the file, it should be re-created next time you connect to imap.

Same goes for other PNM files for mailfolders. Be careful though to not confuse these with the PMM files: PMMs contain the mails in the mailfolder proper. The PNM only contains a unique identifier for all e-mails in the folder and a flag whether the mails is deleted or not.

Greetings

Markus

You can check the path to the alias file used by Mercury in Core configuration / Files / Alias database file. The standard value is C:\MERCURY\Mercury\ALIAS.MER. This is a structured file that shouldn't be edited manually.

After changing an alias in the Aliases dialog in the program just click Save, no restart is required.

/Rolf 

True, messages sent to the external address will be distributed to all local recipients even if sent by one of the local users. Mercury could probably catch the message and reroute it to the local forwarding mailbox instead of first sending it to the external server, though. Other than that some header with the intended local recipient would be needed to avoid sending to all. 

/Rolf 

I found the postmater whitelist app for aol if anyone else needs it:

http://postmaster.aol.com/cgi-bin/whitelist/whitelist_guides.pl

thanks for all of your help.

I knew that I had the wrong mercury protocol, but forgot to change it before submitting, and with it having to be approved, there was no way to edit before having to leave...sorry for any confusion.

There is no setting to change that, but as daemons can change the SMTP envelope it would be possible to do it with a daemon. It's not advisable, though. RFC 2821 clearly suggests to use a blank MAIL FROM for non-delivery notifications:

This notification message must be from the SMTP server at the relay host or the host that first determines that delivery cannot be accomplished. Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is transmitted the reverse-path MUST be set to null (see

4.5.5 for additional discussion). A MAIL command with a null

reverse-path appears as follows:

MAIL FROM:<>

/Rolf

Exactly what I needed, thank you!

Has a solution been found to this problem? I am a long time mercury user and the last version I used was 4.72 and I never experienced this problem.  Just about a week or so ago, I decided to update to 4.73, and I immediately noticed this problem from hotmail. I've tested from two different hotmail accounts and all long messages have this problem.  Is there a fix coming out soon, or should I revert to ver. 4.72.

 Thanks in advance for your reply.

Justin

[quote user="opa56"]

Hi

Mercury as a service works fine on Windows 2008 R2 SP1 Enterprise X64

Cheers   Peter

[/quote]

 On Windows 2008 R2 SP1 Foundation also!

Well, that was rather embarrassing for a whole mornings work.  Thanks.[:'(]

In the last two days, I have received 3 notifications from Mercury that it has recovered from an "abnormal termination".  Most of the messages (all SPAM, of course) that caused this have very strange (Russian character encoding) From" headers.  I have never seen this before in several years of using Mercury .... maybe I am fortunate.  A typical From: header is:

From: ?koi8-r?B?98HMxc7Uyc4g8s/Nwc7P1yA8PT9rb2k4LXI/Qj82Y3pZMFNEd3o4Nw==?= =?koi8-r?B?UHpjSFN4ZGNnUEQwL2EyOXBPQzF5UDBJL1NVOTZRakU1VEVaNmRGUg==?= =?koi8-r?B?WmVBPT0/PQk9P2tvaTgtcj9CP1pHTm5VRVF3TDJFeU

I think that the whole From: line may be in cyrillic.  .

Does anyone know why Mercury is having to "Recover" as  a result of these messages being in the queue.  Not all of these "bad" messages have this strange From: line, but most do.

Thank you

Gordon

Double checked hotmail and found the email was sent to spasm, So it is fixed.

AOL on the other hand, not spasm but get lost for a while.  Sent 10:30 am, finally show up in the inbox at 5 pm. Novertheless, it arrived.

Thank for all the help.  We are slowly picking up how the program work.

At this point, our problem, of course, is still addressing the incoming email.  It seems our ISP only recognized the standard format.  At least the work around works.

Looks like your new ISP is blocking port 25.

You will need to change to MercC to relay through their SMTP server.

My bad. I did but it didn't make sense.

Error -32 activating SSL session (locus 6014, type 4, code 0, 'Bad server key agreement parameter signature')

Hello Rolf,

Thank you for your answer I will try your suggested webtools solution.

The windows version is Windows Server 2008.

Best regards,

Jhonny

Hello Thomas,

I have tried both solutions (just to learn .. ) and I have to agree with you the mailing list is much easier than the filter or maintain a forward file.

Thank you for your support.

Best regards,

Jhonny

Link for Island Def Jam Music Group, the current owners of Mercury Records.

Thanks for the confirmation, Thomas.  As it's the security of mobile (public AP) connections that I am most concerned about, what Xoom/K9 offers with CRAM-MD5 will do the job.  The use of CRAM-MD5 will provide protection for my logins (I will be the only mobile user using my server), specifically just the password, I suppose.  However, it seems that Mercury will still also accept plain logins.  It would seem better if CRAM-MD5 had to be used to login, but I don't know whether it is normally used in that way by IMAP4 servers.

Thank you

Gordon