[quote user="wolfkin"]the banging on my door is starting to ease up now....  maybe I'll unlock it.[/quote][:)]

Unravelling someone else's undocumented non-standard setup....you should ask for danger money.

Mercury help recommends using 60 minutes between retries, or 15 minutes with progressive backoff. As Thomas already pointed out it defaults to 30 minutes. With so many servers using greywalling as there presently is I'll have to agree that this recommendation is starting to feel outdated.

A suitable solution should probably retry quickly a few times to get through greywalling and then increase the intervals to handle offline or overloaded servers in a suitable way, keeping on retrying for at least 48 hours.

/Rolf

How are you receiving your mail? If it is by POP3 through MercuryD you could start by increasing the download timeout considerably. To find out exactly what is stopping transfer switch on session logging for the next download session (but please remember to switch it off again).

/Rolf

I'm confused. Why would your ISP block INBOUND port 25? Most ISPs block OUTBOUND port 25 for customers with dynamic IP address - they don't want their customers sending spam. But if you are paying for a static IP address - and I assume you are if you are trying to run an email server - then you should be entitled to receive inbound on any port (perhaps subject to limitations on volume). Otherwise what's the point of paying them extra for your static IP?

As for outbound port 25, I would also question the value of a static IP address if they block it.

Encoding of mail messages is done using the MIME standard, in Mercury as well as in other mail server programs. It should make no difference what language is used as long as the right charset is specified; the mail server just forwards whatever it has received to its destination. It's then up to the receiving mail client to interpret and display the message correctly.

During transfer some content transfer encoding is applied to the contents of the message, like quoted-printable or base64. If you try to read the raw message before it has been decoded it's likely to look rather messy.

If you want all the details the rules for MIME messages can be found here:

/Rolf 

I've heard keytool is pretty finicky on format, did you double-check your command?  Also did you specify an alias for the key?

Ok I'll try another e-mail, thanks for your answers!

Hi, just for the record, without ssl not succesfull connection with yahoo server....

Hi Rolf,

Thanks for fast reply. I'll try it today.

Best regards,

Zeka

Sounds like a good idea to make a collection of useful rule samples. There has of course been various examples here in the forum and in the Mercury mailing list over the years, but they haven't been collected anywhere. The wiki would perhaps be the best place for it.

/Rolf

> http://code.google.com/p/android/issues/detail?id=4761

Thanks for this - that's an interesting thread, and highlights just how difficult it is to write an IMAP implementation that correctly deals with every possible combination of commands the protocol allows. In this particular case, the issue is clearly a bug in my code rather than anything the Android code is doing, but it's fascinating that the approach the Android developer has taken has exposed similar problems in a wide range of other IMAP servers too.

Cheers!

-- David --

Thank's for help.

It was an old version of clamav! After update all work's fine.

Thank's for the help!

Matthias Schlegel

Hi!

I've hit some problems when upgrading popfile to 1.1.1. and don't really know where to begin looking to sort them out and since all I really want to do is upgrade Mercury... do I need to upgrade popfile to the latest version in order to run the latest version of Mercury or would the latest version of Mercury work with popfile 0.21.1?

The issue I'm having with the popfile upgrade is that popfile crashes whenever I open the "security" or "configuration" tabs in the UI (in case anyone here has seen that issue before).

EDIT:

In case anyone else runs into this... the problem was that the old popfiled merc.pm module was still in the proxy directory of popfile. I removed the file (...\popfile\proxy\merc.pm) and could once again access all the tabs in the GUI. Upgrading to the latest version of popfiled was then easy. 

Yesterday ClamAV released a signature that disabled all versions of the program older than 0.95. If you are running ClamWall this will cause the daemon to try to start clamd for every message. The resulting timeouts will more or less make Mercury core stop working even though it indicates that it's active.

Thanks to Grant Root for pointing this out!

Thanks Rolf.  I checked this file with the service here:

 http://virusscan.jotti.org

 and it was clean.  I've reported it to AVG.  Hopefully they can fix/correct it.

Mark

A MILLION THANKS, PAUL!!!  I had no idea it was that easy. 

I'm on my way!

Thanks again!!!

Thanks for your fast reply and pointing me to the right direction [:)]

This is really confusing stuff, but i guess it be more clearer the more time i spend with it.

This is what i did, and it works just fine.

From: admin@~N (=?UTF8?Q?Administrat=C3=B6r?=)
To: ~T
Subject: =?UTF8?Q?Bekr=C3=A4ftelse_av_E-post_leverans?=
Date: ~D

Ditt support ärende har mottagits, och kommer så snart som möjligt att behandlas.

not really a big message, around 350kb, timeout 30, and the problem is, that everything since last backup is lost. i was able to download bigger mails by isdn conection and now by dsl.

Hi!

the same problem exists if one of those users wants to use the REVIEW command. The mail is processed by the core and that is the result:

I 20100413 2126 MG000B1A hpr@domain                    Maiser                         560
I 20100413 2126 MG000B1B Maiser@domain                 :hpr                           35176

But, HPR should be resolved to both users, right? That part is missing and no list review is send to the original user...

Best,

Konrad

Works quite well for English speakers when processed through Google Translate.