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.

Thank

you for response.

 

my

problem was solved by your advice.

 

>I think you are asking how to stop certain headers being added by

Mercury - is that correct?

Yes.Your

understand is right.

 

>Try turning off the Content Control (CC) filtering which adds most of

the headers you give.

I tried

to it. below message is disappear. thank you.

 X-UC-Weight: [# ] 51

 X-CC-Diagnostic: Not

Header "Date" Exists (51)

 

I was

able to delete below message.

 Message-body

 Message-ID:

<F099047AF2@localhost>

 

It was

miss type in my code of X-Port Control.

miss

type in create DATA information part.

 

 char

txbuf[1024];

 sprintf(txbuf,"Message-body\r\n\r\n");    ← : is none.bad.

 sprintf(txbuf,"Message-body: \r\n\r\n");  ← : is added.correct.

 

I find

above miss code,because there was your advice.

 

in

Forder \xampp\MercuryMail\QUEUE.

in File MG0000003.QDF  this file is not processing.

 

Return-path:

<es@example.com>

Received: from

example.com (192.168.16.175) by localhost (Mercury/32 v4.01b) ID MG000003;

   8 May 2011 14:07:06 +0900

From:<es@example.com>

To:<arx@yahoo.co.jp>

Subject: SUBJECT

Message-body

 

my

name is smtp.

 

in File MO0000004.QDF  this file was processed

for relay.

 

Received: from

spooler by localhost (Mercury/32 v4.01b); 8 May 2011 14:10:12 +0900

Received: from

example.com (192.168.16.175) by localhost (Mercury/32 v4.01b) ID MG000003;

   8 May 2011 14:07:06 +0900

From:<es@example.com>

To:<arx@yahoo.co.jp>

Subject: SUBJECT

Message-body  ← i find miss type.

Message-ID:

<F099047AF2@localhost>

 

my name is smtp.

> We use MercuryD to collect the mail. It is a domain type mailbox.
>
>  I don't know what you mean be the 'original RCPT TO address for delivery', how do I tell?

There is one added by Mercury just before putting the mail into a users mailbox that is the X-Envelope-To: header.  You cannot use this one but there my be one showing one of the following or similar.

X-Rcpt-To: <email@address>
X-Recipient: <email@address>
X-Deliver-To: <email@address>

It's what the original receiving SMTP server writes to the message to show the original RCPT TO address of the message before it writes it to a POP3 mailbox just like Mercury does with the X-Envelope-To: header.

If there is not then you do have some problems and the postmaster is going to spend a lot of time forwarding mail when there is no local address in the message.

Have you got a real-time virus scanner running?  If so, exclude all of the Mercury directories as it needs exclusive access to its own files.

If that doesn't sort the problem turn on session logging and trace a message through Mercury.  Post anything relevant here, but leave out any passwords.

> I've been using Mercury for a couple years now, without much trouble.  A few weeks ago, without changing any settings, thunderbird started
> complaining that the password was wrong and mercury started complaining about multiple failed log ins.  I reinstalled to get
> around this but now nothing is coming through.  I'm pretty sure it's all set up like I had it on the last installation but sending emails
> to my own address just bounce back (eventually).  Any ideas?

1.    Turn on session logging in MercuryS to see if the mail is getting into Mercury core without error.

2.    Check the Mercury system log for errors.

3.    Post an unmodified copy of you Mercury.ini file for analysis.

4.    Provide copies of the text of the error messages.

No, we are not at the EXPUNGE stage yet.

Before an e-mail can be expunged, it has to be flagged as DELETED first. For most imap clients this means the mail is no longer displayed in the mailfolder (or it appears as "striked through"). This flag disappears, i.e. the e-mail appears again in my inbox, as if I had only read it, not deleted it.

Initial testing suggests, the Marking of the e-mail is lost, if the client connection is lost without EXPUNGE. This would be really bad, since up to Mercury 4.72, disconnecting your imap client was the only way to assure such flags where saved to disk.

I had to switch back to 4.72 on our user servers.

Greetings

Markus Borst

It's not running in program mode that slows Mercury down, and it's not the Windows Server environment as such either. Obviously we need more information to figure out what the problem could be, though. If you can give specifications about the hardware used, other software running on the server, number of mail accounts, Mercury settings and things like that we can see if anything obvious comes to mind.

One thing that always is important is that there must be no antivirus software or similar that interferes with Mercury's access to queue, scratch or mailbox directories.

/Rolf 

File-based forwarding using FORWARD files can be switched on in Core configuration / Advanced. There will then be a forwarding button available when you edit user details in Manage local users. The syntax for the FORWARD file is explained in the edit dialog (and in Mercury help).

/Rolf

> On a small mercury mail server we see quite some message in the map \mercury\mail\user
>
> Opening these files with notepad we see the are all the messages (.NCM) from a 10 day period the user received and misses in his POP
> e-mail client.
>
> Telnet with the list command shows 0 messages for the user.
>
> Any ideas how to get them into the "proper" inbox folder of the user ?

Make sure the POP3 server is configured to offer read mail.  From the MercuryP help:

Mark retrieved mail as "read"  When this control is checked, MercuryP will change the status of all messages downloaded by POP3 clients to "read". This can be used in conjunction with the "offer only unread mail" option to allow users to leave copies of all their mail on the server, but be offered only mail they have not seen.

Offer only unread mail  If this control is checked, Mercury will list only messages whose status is "unread" - mail marked as read will be invisible to POP3 clients. This option is very convenient, but is also not a part of the POP3 standard.

 

> I can see that doing thinks Mercury doesn't allow could lead to

unexpected results, but it wasn't the mail cache that
> was messed up, it

was the PMM file - verified by reading it on the server. I didn't

examine the cache but from the file
> size it appeared normal, it

certainly wasn't anywhere near the size of the PMM.

> gusq, in

theory the situation you describe can result in conflicts, but as noted

above, my experience has been that
> problems were very rare up to and

including 4.72.

Did you run the MBXMAINT.exe from v4.73 on all of the PMM files?  In v4.72 and earlier there are problems with duplicate message identifiers when using IMAP4 and these can cause all sorts of problems.

 

OK - sorry folks I think this was a red herring. I had a single Android phone with two mail clients polling simultaniously (Vanilla Android and K9) stopped one and crashing stopped now stable again

 

I'll run Mbxmaint and the  tip is useful thanks - I wondered before why mbxmaint could run with no apparent success

 

thanks

 

Ron