Restarted firewall: problem gone.

Thank you very much

Filippo

We have moved Mercury from one Windows Server 2003 (32-bit) to 2008 (32-bit). Nsynonym.exe work there either. It could be related to the Netware Client with Vista/2008.

At the moment we still have a virtual machine with Windows XP where we can run a script to read the users from the NDS. That file SYNONYM.MER is generated and copied to the mail server.
Has anyone found a better solution to this problem?

If Mercury/32 would support Active Directory and Windows Users directories somewhen, this all would no longer be necessary...
Best wishes, Torsten

There is no built-in functionality for this, but it should be possible to create an event daemon that refuses a RCPT if it can connect to the primary MX server for the domain. 

I've done this already few weeks ago. Don't be afraid. It runs properly so far and I'm happy with it. As Rolf said, you could install it without deinstalling your previous version.

Just created an own public folder structure. To avoid that every user is seeing the entire expanded public folder structure every time he starts Peg I have created only one main folder under the public tree head but with a lot of subfolders under the first main folder. This subfolder structure could be collapsed and keeps collapsed also after a restart. This avoids annoying of users which are not involved in working with those public folders.

But the main problem was the automatic new mail delivery of Mercury into one defined subfolder.

When creating the public folder/subfolder structure, Peg creates single file folders at your server file system (or where you've defined the location for saving) in the form folder.mai where the folder naming is always cryptic like S14DQYXS.MAI.

Now I have used one of that cryptic *.mai folder for the definition of the PUBLIC: alias in Mercury. And it works. Also with a deep path (I'm using e.g.: PUBLIC:E:\MERCURY\MAIL\public\public.MAI\S14DQYXS.MAI). Mercury is retrieving emails from our special public internet mail address as usual. But there is no local user defined where Mercury should drop the new mails. Instead of this Mercury has an alias for that address and drops the mails into the defined *.MAI folder.

Of course, you never will get a "new mail" notification. But public mail folders based on another concept other than ordinary mail account.

Uhhhmmm, no I don't use pegasus mail client. I set up my server for family members that live in other states and well, for instance, trying to convince my mom to change to another email client wouldn't turn out pretty *heh*. Another approach I'm looking into is writing my own daemon to modify the message and redirect it. I'm still looking at that trying to figure out how to "run the spam.dat" file first (to get my identifying headers) before i send it to the spam account. I need to look into those POPfile and POPfileD daemons you suggested. I'm still researching, let me know if you have any ideas, Thanx - Gary

I have installed version 4.8beta and have had no stuck emails for 2 weeks. I will say since currently I am only using this to relay some internal emails to another mail server I did not install clamwall, spamhalter or greywall so I don't have the exact same set up as before but at this time things are working as needed so thanks for your help.

Great! This solved the problem, as far as I can see now....

I will review some 24 hours and post if I can see any other effects.

Thank you very much, should have asked long time ago!

Dieter

Ah! Sorry - I'm getting IMAP and authenticated SMTP mixed up.

Staff can connect using IMAP and read their mail, but they cannot send mail when connected unless they authenticate their session. In order for this to work for staff connecting from a remote location I have to supply a password for both the user account under 'Manage User Accounts' and in the SMTP_Auth.pw file. As you say, you can give that file any name. So, reading this again I guess that as the server will be handling incoming requests to relay mail I will, therefore, need to install MercuryS.

[Edit]

It's OK - I think I've got this sorted out now,

Thanks.

Right, that's the preferred way to define what's local to the server. Public IP can be added as well to make it complete.

Hi, Paul

Yes, this is all sorted now, thanks. The second domain went live last Monday and all mail is being handled from one server. You are right on the ball.

I realised that I would have issues with remote mail access and that, as you say, the name of the sending server does not matter. There are good reasons for separating the mail source for both domains, but I also decided that they were not important enough to warrant setting up what would be an overly complicated 'solution'.

I'm glad that I started on this as early as I did as it gave me enough time to realise this setup would require more effort to monitor and maintain than was really required.

Thanks a lot for replying - it's reassuring to read your response and to know that I got there in the end :)

Cheers!

I run Mercury on a dedicated Win7 PC, not as a service, logged in as a domain user (comparable to a standard local user with limited access to files on servers).  I manage it as the same user so thought the answer was "no" to your admin question but upon further investigation I see that I have granted full permissions to C:\Mercury by Authenticated Users.  So, admin equivalent permissions to Mercury without being a local admin.

This PC is not publicly accessible so granting full permissions to C:\Mercury by Authenticated Users was a lazy way of allowing access to whoever I might login as.

See if you can follow a submitted message in console windows (or log files) as it is received by MercuryS and picked up by Mercury core, there might be some useful information there.

Hi!

 So the problem was not in version 4.8, but previous version, and updating to version 4.8 fixed it? OK, thanks for the info.

:) 

 Jyrki 

I am having the same problem like you and I can't solved it. Did you solve your problem? Thanks

I don't know full details about error responses in Mercury during an SMTP AUTH exchange, but as far as I can see RFC 2554 gives no reason to only expect a 535 response in this case. RFC documents have their own definition of certain words, and RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) indicates that SHOULD is to be read as a recommendation rather than a requirement.

Thanks - indeed, I had missed that! The Mercury D setting is set to 60 seconds.

One thing I have noticed is that even when I configure outlook (or an android device) to leave a copy of the email on the server, it does not?

thank you

If the server supports "sieve", the mail client (also supporting this language/protocol) is able to control things like server side filters, auto reply for vacation and other useful stuff every user wants to control by himself without sending a mail to his mail admin ;-)

Konrad