This is a discussion group for the Mercury email program. You claim you received an add for a Mercury automobile. Are you sure you posted in the right forum?

I eventually bought the Motorola Xoom and am largely very happy with it.  The Android K9 mail client appears to work well with Mercury IMAP.  I am marking this question as Resolved.

Gordon

 

 

The default settings in Mercury are usually the best place to start. For Windows 7 you will need to download the WinHelp installation files from Microsoft to get the actually very useful help system working. This KB article has the download links: 

There is a PDF manual included in the standard Mercury installation too. I'm not sure if it's there in Xampp as I haven't tested that package.

The current version of Mercury is 4.73 and in most cases it's a good idea to upgrade.

If you need help with specific details about the installation please let us know a bit more about your requirements and network environment.

/Rolf  

A little more testing with hints from what has been happening and I am now at the point where I can reproduce the problem exactly time after time.  First things we can rule out, file caching by the Netware client, it happens exactly the same whether the caching is on of off.  The problem is related to the SSL errors we see on both Thunderbird and Mercury when Thunderbird is first started.  Specifically where on an initial attempt to connect, Thunderbird's error console reports "server does not support RFC5746, see CVE-2009-3555" and Mercury reports "SSL direct-connect failure form ....".  When Thunderbird starts up and attempts to connect, it fails with the error message noted, however the TB status bar is still "displaying Connected to test.mailserver.com".  I have always been somewhat suspect of messages in TB's status bar, however can not afford to spend the time to dig through the readily available source code to verify what is going on.  In any case if I at this point mark a number of messages in the inbox to delete in the inbox window on TB, and for the sake of test, I pick the oldest 24 so things will be looking the same in the logs as they were in the previous test and press the delete key, those 24 messages do appear to move to the trash folder on TB.  I switch to the trash folder in TB and at this point it now establishes a real connection with Mercury, which show up in the Current connections and status window on Mercury at this point.  If I at this point switch TB back to the inbox view, I now see all the messages I just deleted.  For the sake of this test, I do roll the mailbox back to its initial state by replacing all the files in the PMAIL folder of the test user in question to the exact state they were in before the test so we are always starting with everything at exactly the same point.  On the client side, the computer in question is always rolled back to a state where everything on it is back in a state where TB had successfully gotten it self in complete sync with no ongoing problems.  At this point if I delete files from the inbox in TB, they come back after switching folders. 

  If I look at the Mercury logs after this has happened and pick the oldest message that I deleted, I see it come back with a different UID.  Also if I look in the test user's PMAIL folder, I find the .CNM file from this message with the only difference between it and the original being the addition of a line as follows

X-PMFLAGS: 570949760 0 13 292DC404.CNM

This line is inserted just after all the rest of the headers and before the rest of the message, specifically the line 'This is a multi-part message in MIME format.'.

On the surface it appears that TB is moving the message to the trash folder offline and not marking it to be deleted because it does not have a connection to the server.  Once it does establish a connection to the server, which happens when the user takes some action, such as clicking on get mail or switching to a different folder, it now makes a connection and then syncs the message that it moved to the trash folder back to the server and the original is still in the inbox because a delete message was never sent due to the lack of a connection.  This would appear to be a bug in Thunderbird, however I will immediately get feedback from my users to the effect of "This never happens with other iMap servers". 

Gus

Although I have been using filtering rules for several years. I still don't think that I have a full understanding of them.  For example, as I understand it, Global Rules affect both incoming and outgoing messages.  Outgoing Rules affect outgoing messages, but there seems to be no direct way of only dealing with incoming messages.  For me, it is almost always the incoming messages only, to which I would like to apply rules.

Another thing that I am not sure about is whether all outgoing messages will be processed by Global Rules.  For example, if within a Global Rule set, I forward the message currently being processed, is this message added to the mail queue again and, therefore, gets reprocessed by the Global Rule set?  Similarly, if I call a program and that program sends a mail message (e.g. with Mercury's msendto.exe), does this message get put into Mercury's mail queue and, therefore, gets processed by the Global Rule set?

On the assumption that some messages (e.g. forwarded messages) get reprocessed by the Global Rule set as they go out, I have placed a number of rules in the Global Rule set to check whether the message is outgoing.  This isn't very satisfactory and it may not be a correct thing to do.  Even (potentially) worse, if any of these outgoing messages exit the Global Rule set are they then subject to Policy actions.  So, for example, if one of my Policy Tasks does some checking for spam, I would possibly not wish to have any messages that I am forwarding checked by the same Policy Task as I am using for incoming messages.  Do I, therefore, need to have the program, which is being called by the Policy Task, check whether it is dealing with an incoming or outgoing message?

This would all be simpler if incoming and outgoing messages could be filtered separately.

Perhaps someone could help me with these mysteries!

Thank you

Gordon

> You have made me wonder about whether I could extract the connecting
> IP address from (presumably) the Mercury log.

The log does have the IP addresses of the connecting host.

T 20110501 000410 4d9fbdca Connection from 62.20.118.73
T 20110501 000411 4d9fbdca EHLO mail.praktit.se
T 20110501 000411 4d9fbdca MAIL FROM:<NoReply@praktit.se> SIZE=4291
T 20110501 000412 4d9fbdca RCPT TO:<support@tstephenson.com>
T 20110501 000412 4d9fbdca DATA
T 20110501 000413 4d9fbdca DATA - 69 lines, 4397 bytes.
T 20110501 000413 4d9fbdca QUIT

That said, I use POPFile and POPFileD for spam and this is 99.97 percent effective.  I move the spam to a spam account that I check every so often so my false positive rate is zero.

Sure, here is a link to the Mercury Daemon developer kit:

http://community.pmail.com/files/folders/mercur/entry10073.aspx

/Rolf

Why not use Mercury help (or check the PDF manual) instead of searching the Internet, it's more efficient! ;)

First make sure the local domains part of Core configuration is correct. If users should be allowed to send messages to non-local recipients you should add the IP range of the LAN in MercuryS configuration, Connection control and allow relaying for that range. Verify that the ports for the email protocols you use (SMTP, POP3, IMAP...) are not blocked by firewall software on the server.

If you still can't get it to work please post your mercury.ini file here so we can check it!

/Rolf

Figured out after some digging that I was running IIS in the background, turned it off and now the world makes more sense.  Thanks for everything![Y]

Thank you Rolf, i will be waiting.

I think I've figured out the problem - by not honoring expunge requests until a logout has occured, it makes the IMAP implementation incompatible with mobile phones and laptops.  If your IP address gets changed (such as going from one mobile phone tower to another, or carrying a laptop between hotspots without shutting your email program), it leaves a hanging connection.  I guess you could fix this by setting a very low time before it automatically disconnects.

Yes, but I got the gist of it.

 

Thanks again.

> I have a dynamic IP from my ISP which means I don't want to send my own email, as some people consider mail from dynamic
> automatically spam.  

Anybody using the Spamhaus-ZEN blacklist will reject mail from dynamically assigned IP addresses.  Many other blacklists also use this technique.

> Furthermore my ISP restricts the number of unique FROM: email addresses when sending to 10 and I have to register all email addresses that will
> be used for sending.  I run a small business and this limitation of max of 10 outgoing addresses is hurting me.

How about getting a fixed IP address.  Is the cost that much more than the dynamically assigned IP address.  

>
> I see two solutions: 1) is to pay for a SMTP service to relay the mail for me.  I've done that in the  past, and it's ok, but they're
> expensive.

I'm not all that sure it's all that expensive.  DynDNS costs ~$15/year for 150 relays and you can buy this in blocks to increase the limit.

https://www.dyndns.com/services/sendlabs/outbound.html

> 2) my ISP (Rogers in Canada, which is in cahoots with Yahoo by the way) allows multiple mail boxes, so I've been thinking that I set up
> a mail box for each employee.  But this means that the Mercury Relay SMTP client somehow has to send to the correct Rogers/Yahoo mailbox
> depending on which of my employees is doing to the sending.  And I don't think it can do that.

The employees could bypass Mercury when sending and send directly the the Yahoo host.

> So then plan B was to run multiple Mercury's - one for each employee.

A real pain in the rear!

> But this becomes a nightmare to administer, and I've been running Mercury forever (10 years+) and how do Itake the various user
> sections apart into separate folders for each mercury?
> So do you have any suggestions on how I can solve this?

1.    Get a fixed IP address.

2.    Talk to your ISP and tell them you are running a business and the outbound limit in killing you.

3.    Use a commercial SMTP relay host.

4.    Have the users send mail directly to the ISP's host using their mail client.

> PS: With proper SPF, can I send directly without being considered a spammer?  I've never really figured out SPF...

Nope, SPF has nothing to do with the blacklisting of mail from dynamically assigned IP addresses.  Good grief, I expect more spammers are using SPF than valid mail sites.

Hi, Thomas

Thank you so much for your help and suggestions. I had seen your initial response and spent quite some time searching for something suitable.

I found there were two problems - first, most comprehensive references are at least 10 years out of date, and second, those that were not were geared to particular software implementations. Although I have no doubt Sendmail et al. are excellent mail server programs, I don't want to learn them if I have no intention of using them.

I will purchase Johnson's work - the reviews seem quite positive.

Thanks again, I really appreciate it.

Hi, Paul

Many thanks! I rang Webroot's Tech Support and indeed it was a setting that needed to be changed.

If anyone else has this issue do the following:

Groups > edit the affected domain > Filtering

Remove the tick from the checkbox next to 'Bounce address tag validation'

Cheers!

Yes, your answer bring me to the right direction.

The "x-recipient" isn't added by the email client nor from mercury/32. It's added by the popfile-daemon.

It's the -t flag of the popfiled:

<dl><dt><pre><code>-t</code></pre>     If present, mail tagged with either the <p> <pre><code>X-Text-Classification</code></pre> or the <pre><code>X-POPFile-Link</code></pre> </p><p> headers will also receive the new header </p><p> <pre><code>X-Recipient:&nbsp;&lt;recipient_name&gt;</code></pre></p></dt><dt> </dt><dt>It seems to me: it's not a good idea to use the  -t  flag if BCC is used. <br></dt><dt> </dt><dt>Thank you :-) <br></dt><dd> <br></dd></dl>

 

> The above seems to indicate that Mercury is ignoring the port 587 and is trying to connect to port 465 at verizon?

> Is there a problem with this version of Mercury?

 

Nope, works just fine with port 587, are you sure that's what you have entered?  If you select direct SSL if will change to the default port 465 unless you tell it not to.  

What happens when you telnet into port 587 of the Verizon server?  What server name are you using?

This is what I get using the Verizon SMTP server outgoing.verizon.net.

220 vms173005.mailsrvcs.net -- Server ESMTP (Sun Java(tm) System Messaging Serve
r 7u2-7.02 32bit (built Apr 16 2009))
ehlo thomas
250-vms173005.mailsrvcs.net
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-DSN
250-ENHANCEDSTATUSCODES
250-EXPN
250-HELP
250-XADR
250-XSTA
250-XCIR
250-XGEN
250-XLOOP 05D88CCCAC0AC26CC792831AD209F0D0
250-AUTH DIGEST-MD5 PLAIN LOGIN CRAM-MD5
250-AUTH=LOGIN PLAIN
250-NO-SOLICITING
250 SIZE 20971520

It says you need to do authentication using either ESMTP AUTH LOGIN or CRAM-MD5 since these are the ones supported by MercuryC.  .Watch out for CRAM-MD5 since it's not properly implemented by many ISPs even when it is listed as supported.

Authentication via the extended SMTP AUTH command is handled automatically by Mercury: if you supply a username and password and have not checked the Authenticate via prior POP3 connection control, Mercury will attempt to use AUTH instead. Mercury supports the two most commonly-used variations of the AUTH command, LOGIN and CRAM-MD5. You do not have to worry which gets used - Mercury will automatically detect which variations are available and choose accordingly. Your ISP will be able to tell you whether his SMTP server supports SMTP AUTH.

 

Do not use CRAM-MD5 even if the smart host advertises it  The most secure SMTP authentication method is called CRAM-MD5 (for reasons far too arcane to cover here). Because it is the most secure method, MercuryC will always choose to use it if the server indicates that it is available. Unfortunately, some SMTP servers will advertise CRAM-MD5 as being available even though the extra configuration necessary to support it has not actually been done: this results in MercuryC attempting to authenticate using a method that will never actually work. If the SMTP server to which you're connecting has this problem, checking this control will tell MercuryC not to use CRAM-MD5, relying instead on much less secure methods of authentication. If you have to check this control to get MercuryC to work, then the remote SMTP smart host is badly misconfigured, and you should rant at its administrator until he or she fixes it.

OK, the admin says they don't use SPF and that the error was most likely due to the fact that we were between providers. The failure messages were received a couple of hours after I had changed the mx records for our domains and the smart host name in the MercuryC module.

Yes, the switch in the Core configuration is on, so I don't know what the problem is.  I have more urgent things to deal with at the moment, but I will come back to it later.

Thank you

Gordon

 

> Thanks. First, I assume the hgh bits problem can be coded into an error rather than a crash. If so, can we add that to a list?  Second,
> is the address reported in the crash notice of any interest for narrowing down the cause?

Generally the problem is the high-bit stuff will generate a command since Mercury really does not care all that much what the data being sent looks like.  Of course in this case there is nothing Mercury can do when the data stream turns into a TCP/IP command.