Mercury will by default store the password for POP3 and IMAP in a file named PASSWD.PM in the user's mailbox directory. If these files are included in the backup then passwords are preserved. The exception is if an addon for verifying against another source such as Active Directory or Netware has been installed, but if so there is presumably already backup for that.

Well, Internet routing issues, certificate issues, bad wifi connections, bad 3G/4G connections or pretty much anything that is part of the network connection between the mobile device and the web server that provides the images. 

There are many ways to do this in Mercury, and which one is best or easiest depends on what you are trying to achieve. If you want to forward incoming mail for a specific mailbox the easiest is probably to use the automatic mail forwarding feature (Configuration / Manage local users), which is available if "Allow file-based forwarding specification using FORWARD file" in Core configuration / Advanced is selected. You can add as many recipients as you like.

Filtering rules are much more powerful tools that allow you to control delivery of messages passing through Mercury in different ways, but they may require some basic understanding of programming logics to use. Brian's example of a global set of rules (each line is a separate rule!) was based on having a rule (in this case triggered by a specific sender) jump to a label to execute a number of rules, finally exiting rule processing. Check Mercury help or the PDF manual for more information about rules.

A third option would be to create aliases and link to general rulesets. If you have a lot of different forwarding cases based on recipient address this will be more manageable than creating very many global rules.

Hi Rolf,

wow ... thank you very much! Seems in future I should look for some more reasons for those errors.

[quote]It checks to see whether the user part refers to a Group that has been defined in the “Groups” page of the Mercury Core Module configuration dialog.[/quote]

Did know that and have some groups defined in Mercury pointing at groups in NDS/eDirectory (Novell User Management Database).

But I didn't realize what happens if the userpart of the mailaddress is the same than a groupname in NDS. The problem was: no errormessage by Mercury than a mail with "Recovery from abnormal termination" to Postmaster and similar entries in Loader.log. A hint like "New mailbox directory missing" would have been nice ... because a existing user in NDS, who deleted his new mailbox directory located in his home directory on the server, results in same behaviour of Mercury.

I think even without NDS and simply defined usernames/mailboxes with Mercury and Pegasus, the result would be the same if that directory is deleted or renamed: termination of Mercury. Can't test it due to NDS ... perhaps somebody else?

thanks    Olaf

I've basically given up on Mercury IMAP. IMAP problems are the #1 reason I'm having to migrate our company from Mercury to Exchange. Granted we're probably a worst-case small business scenario for any IMAP server.

* 50 employees, half of whom carry iPhones or iPads for email.

* Outlook 2007, 2010, 2013, and 2016 are all in use around the company. And the CEO carries a MacBook.

* Half our workforce works from home or travels 75%+.

* We have staff who assume it should be possible to have slashes and ampersands in folder names, and deeply nested folders.

It's perfectly typical for me to see some employee mailboxes with 10 connections to their mailbox, given the way they "flip" between iPhone/iPad and Outlook client throughout the day, or attempt to use email while traveling/in flight on dodgy airline WiFi. 

Most other Mercury features have been flawless: POP3, forwarding, aliases, mailing lists, you name it.

IMAP with mobile devices + Outlook clients is a disaster. I reconstruct a mailbox each month, on average.

A user needs to be connected to the server to authenticate, so if you immediately refuse the connection (based on IP address) there will never be a chance to authenticate.

There is however an option in transaction-level filtering (found under MercuryS configuration / Compliance) to use deferred HELO processing. Connections that otherwise would be refused will then be allowed to attempt to authenticate to avoid being shut down.

Locate something in the rejection notice that you can filter on then add a global rule that deletes the rejection and breaks the cycle.  For instance, I have an expression filter that detects "*550 5.7.1 Backscatter DSNs not accepted*" and deletes those messages.  I don't specifically remember the service the generates this content though.

No, Rolf. I'm using "Refuse messages that have no or empty 'subject' fields" in the SMTP server module.

It seems, the folded subject-header is not properly interpreted.

Some minutes later: There is only a space and not a whitespace in the folded  header and that isn't RFC conform [:@].

my very first rule is
If expression headers matches "*received*from bouncejimmyspam*" Goto "jimmyjim"

 bunch of other filtering rules here....

my last two rules are:
Label "jimmyjim"
Always Exit ""

I then configured Pegasus mail to use this name in the helo

bouncejimmyspam

The odds of a spammer using that exact string is pretty remote

Not sure but I would guess that MX records for the recipient domain still points to a mailserver (presumably at the hosting company) where that domain now has been removed.

The other way to accept all messages for the domain is to check "Accept mail for invalid local addresses" in MercuryS configuration. If the recipient doesn't exist the message will then be forwarded to the postmaster account, and a notification will be sent to the sender.

The problem with accepting all mail is of course that one is likely to receive a ton of spam addressed to non-existent accounts. Unless that can be contained it's best to stop nondelivery notifications (by removing or renaming the template file failure.mer).

Only having a domain mailbox in the local domains list is somewhat less orthodox but works as well as long as there is no conflicting definition for the domain.

The client is an iPhone.  I'll have this user dig into his configuration settings to see if he can identify where it is coming from.

In Mercury 4.7x  a "Sender" field was added to every E-Mail, that was sent from  the Mercury listserver.
This meant that always "Maiser in order of ..." has been displayed in each email, but allowed a clear identification to avoid multiple processing.

In Mercury 4.8, this field is not set and we need for our policies (scripts) another option now.
Could we use the field "X-listname" and delete them after processing? How does it affect if we delete this field during the processing of e-mail?

Operation:
We use the Mercury listserver as our project server. Each list corresponds to a construction project.
Just our part of the communication is done via the server, which is why our users have to know who the email originally get even.
We use the Policy CMD scripts with Find and especially Sed to modify the e-mails and allow this. 

Thanks, Torsten

[quote user="J_Aarni"]You can also use special names in Mercury log files to re-create them regularly.[/quote]

Jyrki has a very useful point and is what I do. This way its easy to delete or archive old logs. I usually zip up my logs from the previous month. Having 10's of GB of old log files is not really an issue when pretty much your minimum hard drive is 500GB, although I haven't found a need to look back over stuff.

accept mail for invalid local addresses was already unticked. so far everything looks good now, lots of connection refusals from the same IPs :) genuine register requests are working properly and mail is being sent perfectly. the mail server is under far less stress now. CPU usage is next to nothing and memory usage is very low too. I will keep an eye on it over the next couple of days. I really need to understand more about how this mercury mail server works.

thanks for your support guys, I am very grateful for your help. thanks

Brian

Thank you for your comment - I think you may have somewhat 'inadvertantly' opened my eyes to this! 

I have been using a single primary mailbox  into which all the email arrives. Mercury D polls this single mailbox and then dsitributes to local users based on the domain name prefix.

I have now created separate mailboxes - one for each user on the name hosting server and updated Mercury D to download from each mailbox - the duplicate message problem now appears to be solved! I love simple solutions. 

Thanks for the  light-bulb moment.

lol i had the same Problem probing 2 hours to fix this Problem :D

i had no delivery file tamplate in the config so it always crashed but now we are happy :) 

FYI With Mercury 4.8 & Win7 I just set my server to large fonts (125% scaling) and the dialogs have auto-scaled and are fine.

[quote user="Brian Fluet"]Have since discovered that the recipient address the original message was incorrect.  Subsequent messages have been delivered.  What an annoyance to have the delivery failure notice reference greylisting when the problem is an invalid address.
[/quote]

Haha - at least it was easily sorted out :)

Rolf,

Thanks very much, that fixed the problem!