As empty HELO greetings aren't RFC compliant we will probably have Mercury reject them by default in v5. Thanks for pointing this out!

I that you are having such problems and that you missed the setting in the POP3 host configuration that controls deletion of messages on the server.  Recovery may be possible if you can create an IMAP connection to your hosted mailbox then copy the messages to the IMAP connected new mail folder.  This will put them back on the server.

For additional help start a new thread on the Pegasus Mail forum with a description of what has happened and the specifics you need help with.

Hi,

I'm not shure about what you are doing.

You have some groups created on Netware?

You want to send mails to those groups so that they will be distributed to the members?

Then you have to create a "groupsalias" (public name) in Mercury Core Module pointing to each group in Netware you want to use for maildistribution. With bindery module loaded in Mercury you simply enter the groupname, with NDS Module the full distinguished name (.groupname.ou.o).

If a Netware group has no public name in Mercury poiting to it, Mercury should not recognize it and send no mails to the members. That's how it works for me for many years.

bye    Olaf

With all your help I am getting there. I went through all again and really it turned out to be a mistake in the UNC path. there was a little "l" missing for the drive on the server where mercury and pmail reside, which obviously goes away if you map drives.

Sending is working all well now, after I updated the gateway via pconfig with the right information.

Now I learned as well that I have to create a fsynonym database, as this was handled by netware in my case... 

 :-), Thanks again to everybody who looked into it,

Dieter

Rather than confuse the OP the answer is that you can either configure a new mailbox(User) account or use an existing one.

The protocol IMAP has no feature translating mailaddresses! It's something like a filesystem for your mailbox.

To solve that problem, you have to avoid users from using Netware usernames for addressing. There is no other way to solve it.

The way I've gone years ago is to install a SMTP-Configuration for my Pegasus users. If in place, two things happen. The module SMTPS in Mercury shows up on such a mail:

Connection from 129.217.xxx.xxx, Tue Jul 21 07:39:10 2015
EHLO xxx.xxx.tu-dortmund.de
STARTTLS
EHLO xxx.xxx.tu-dortmund.de
MAIL FROM:<xxx.xxx@xxx.tu-dortmund.de> SIZE=1840
RCPT TO:<netwareuser>
QUIT

Seems normal, but SMTPS denies receipt (the protocol entry DATA is missing, which indicates SMTPS to accept the mail) and Pegasus produces an internal errormessage including the line:

553 Invalid RFC821 mailbox specification.

 So your local users can't send with netware usernames any more.

bye   Olaf

[quote user="PaulW"][quote user="Greenman"][quote user="Rolf Lindby"]

The way I understood it the message arrived from an external distribution list to local user A, was forwarded using Pegasus Mail to local user B, resulting in the forwarded message being killed by Mercury, but that was maybe not actually the case?

[/quote]

You are almost right. The external message was addressed to local user A who forwarded it via a distribution list to several local users B, C, D, E etc.

However, the original message was delivered by Mercury without being 'killed'.[/quote]

Is this just happening to one user or several?  And how is it being forwarded - bounce or fwd with edit?

[/quote]

They tried it with forward as edit, and forward as attachment. Did not use the bounce option as they needed to introduce the message.

RE:  TRANSFLT,MER:  No transaction filtering.  I checked the file with a text editor confirming that all lines are commented out.

I originally installed Mercury with the sole purpose of running it with POPFile to keep the crap out of the users mailboxes.  I created a large number of global filters to auto-delete known unwanted messages (vulgar terms, male enhancement, viagra,...) as well as rules that manipulated messages (copied, forwarded, deleted attachments, added text fragments).  The second instance was the result of me never being able to exclude outgoing messages from global rule filtering.  It worked well so I never revisited the issue.

The occasional outgoing messages that are being copied to the postmaster mailbox appear to be just flukes.  I searched 6 months worth of logs and only find the two messages that prompted this post, and they occurred months apart.  Whatever is causing it appears harmless and is so rare that it is not worth any more effort.

Thanks for your thoughts.

I confirmed it last night and have since suggested that the user enable the delivery confirmation on a per message/as needed basis.

Hi PaulW,

Thanks for the reply.  No, they got sent after a few minutes.  I was just being impatient, and wanted to know if I could force them somehow.  It sounds like that isn't an option, and you just have to wait.  I even tried exiting and restarting the server, but that didn't force them either. 

I did a quick test and it looks like adding a period would solve this problem. For some reason extension detection triggers on contains rather than exact match, so that's why there were false positives in the first place.

[quote user="Brian Fluet"]You say that your MercuryD retrieves two messages from each mailbox which is different from mine which only retrieves one message from each mailbox.  It then delivers to the To: AND to the CC: of the message.  This is the problem that the MSGIDS.MER fixed. Perhaps this is just a matter of semantics.  I am looking at messages retrieved from each mailbox (one) whereas you are looking at messages delivered from each mailbox (two, possibly more if the To and/or CC contain multiple local recipients). [/quote]

I think you are right. Mercury-D retrieves only one mail but because there is no direct local user designated, Mercury checks which local user or users mostly match. Therefore it checks the synonym.mer, too. The mail contains a To: and a Cc: section where both recipients are available as local users. And that's why it delivers to both local mailboxes.

And the same game when connecting to the second ISP mailbox.

On the other hand, when designating a local user for each ISP mailbox in Mercury-D, Mercury knows the local user where the mail has to be delivered to and does not check for any other possible users. That could be the reason for that behaviour.

Thanks for the hint, Brian 

[quote user="PaulW"]Try connecting via IMAP - mixing the access types to the mailbox is going to lead to blocking issues.[/quote]

I confirm this. As already stated above, I'm not able to connect over IMAP when simultaneously Pegasus is still connected to a user mailbox.

Also two simultaneous IMAP sessions to one Peg mailbox don't work. The second IMAP attempt gets an error message back, at least with our IMAP client RoundCube.

Joerg

It is also worth noting that Pegasus Mail will not allow a PMM file to grow larger than 2GB. If you try to add messages to a folder that will take it over 2GB Pegasus Mail displays a notification saying the limit has been reached.

[quote user="Greenman"]

Messages identified as spam are often simply dumped without notification. 

[/quote]

Thanks for the input folks, but it looks like Greenman is on the money.

I took my problem to another forum where reps from the ISP contribute and got a bite.  At the end of my log is: 14:25:07.920: >> 250 ok: Message 330362388 accepted<cr><lf> , and at some point in their log is Thu Apr 30 12:24:57 2015 Info: MID 330362388 using engine: CASE spam positive

I'm now in email communication with an actual person at the ISP and he's currently looking into it, and theorised that "image in signature is a common culprit" which my emails have.  The timing of the spam identification would indicate something within the DATA section of the email too, since my message hadn't even completed sending when it was tripped.

I'll let you know the result, but in any case it's nice to know I'm not crazy.

I need to exclude autoforwards (generated by the FORWARD file) from global rule filtering as they go out.  Does anyone know whether the X-Autoforward: header is created in time to be used in an expression rule to stop processing?   

Thanks, Brian

The rules I have are simple and minimal. I have gone through every rule now and made sure that all the old rules now target the new addresses. I have also moved all the rules that forward messages from 'old address' to 'new address' to the top of the list - well, after the catchall rule that is always triggered first.

I will see how this works.

Cheers!

Its semms working but the mail not come.

Yes - copy the present folder structure to the new server (and keep a backup). 

Why not recreate the same folder structure? That way all your settings will be OK.

If you really do need to change the folder structure you will need to amend the Mail Queue Directory in the Mercury Core Module and also the paths to the Mercury System Files, also in the Mercury Core Module.

You will need to edit the location of other folders/files in MercuryS etc.

Copy the installation across to the new location, put Mercury in Offline Mode then go through each setting and check that all paths are updated.

Or, it may be simpler to carry out a fresh installation.

I think perhaps if you created an SPF record that authorized your ISP to send mail on your behalf you might be ok.  It's at least worth a try.  You could also ask your ISP to try sending them an email to see if it goes through, if not then it is your ISP's problem perhaps.