There's a nifty little tool named poppass 1.05 for win32 written by Michael John Phillips / Vortex Software which I'm using since years. Unfortunately it's page is down and I couldn't find it anywhere else on the net so I'm providing it at my server: 

Best regards

Nico

> Hello.
>
> We'd like to move from Sendmail(unix) to  Mercury(win2003).
>
>  We do not need to migrate existing mail, because it is a training lab.
>
> We'd like to create and delete  Mailboxes via Script. How can that be done?
>
> Pointers to existing manuals very welcome
>
> Bye
>

Should be pretty straight forward to modify the pmail.usr file and make the subdirectories for the users.  The default pmail.ini and passwd.pm files are also all self explanatory. The only thing that you probably need to do is use the reload users command if you are trying to do this with Mercury/32 running.

*   The mail server now has its own password file, created and
    managed on the "Mail server" configuration page. This is not
    covered in the help yet, but you can create any number of mail
    server passwords that can be used in a "PASSWORD" command to
    handle the new operations described below. If you have no
    password file, then no password will ever succeed and the new
    operations will fail automatically - hence the operation is secure by
    default. Mail server passwords are simply one-per-line (like
    everywhere else) and cannot contain the character ';' (semi-colon).

*   A new mail server command, "KILLFILE" has been added. This
    command allows you to manipulate the MercuryS killfile by mail. At
    present, the only implemented command is "KILLFILE ADD", which
    adds the parameter you supply to the MercuryS killfile. An example
    is at the end of this message.

*   A new mail server command, "RELOAD" has been added. This
    command allows you to force Mercury to re-read certain
    configuration files by mail. At present, the only implemented
    command is "RELOAD USERS", which takes no parameters, and
    tells Mercury to reload the user database, PMAIL.USR.

Both of these commands need to be preceded by a PASSWORD
command specifying a valid password from the password file created in
the mail server configuration dialog.

Examples (these examples assume that the password 'foo4u' is
specified in the Mail Server password file):

* To add *@163.com to the MercuryS killfile, issue these commands:

      PASSWORD foo4u
      KILLFILE ADD *@163.com

* To force Mercury to reload its user database, issue these commands:

      PASSWORD foo4u
      RELOAD USERS

The commands are not case sensitive - I've shown them in uppercase only to emphasize them.

I plan to add more commands of this kind - administrative in nature - and will be adding a level of discrimination to the password file to allow passwords to work only for certain types of operation (hence the reason why ';' cannot be used in a password).

i think it is best for me to review my situation in view of the long post i have created. with this in mind i would like to begin again. watch for another NEWBIE post.

 thanks in advance

gjc 

Users are setup using Configuration | Manage local users.  The postmaster is specified as one of the local users so error messages have a place to go.  The domains in the server are setup using Configuration | Mercury core | Local domains.  The domain of the server is set in Configuration | Mercury core "Internet name for this system"  You might want to checkout http://kbase.pmail.gen.nz/viewfull.cfm?ObjectID=C1523317-4EC6-11D4-8B6B0008C709E5EC to see if some of your basic questions could be answered via the knowledgebase.

 

On 22 Nov 2007 Pegasus Mail & Mercury - Automated Email <NoReply@praktit.se> wrote:

> Hi guys.
>
>  A little bit of both.
>
> The Shared Mailbox thing:
> I setup mail to all users ( i.e *@agrilibrium.co.za) to be forwarded
> to agrilibrium@iburst.co.za.
> (This is done from the domain host cPanel).  The split is done after
> retrieval by Mercury.
> My reasoning was to avoid defining a mailbox for each of the users
> at the domain level.
> I simply administer locally via Mercury.
>
> Mail from this person (of the Exim server) is processed correctly
> when they are on TO: or CC:
> It's only when on BCC that it doesn't work as the To: header shows
> <Undisclosed Recipients>.
>
> I have no idea whether I am processing Envelope_to: before any To:

The X-Envelope-To: is being added by Mercury/32 when delivering the message to a new mail directory.  If your forwarder has not added the original RCPT TO: addresses the the mail when it's being rewritten and forwarded then you'll never be able to determine an original Bcc: address since it's only in the SMTP addresses in most cases.  The forwarder normally should add this as a Deliver-To: or similar header that you can use in delivery.
   
> Where would I check this ?

[quote user="dpulver"]

Hello,

 i want to use the Mercury Server as a IMAP Server. I readed, that there is a difference for performance between the maildir and the mbox

format. Which format supports the mercury server ?

Is it possible to manage many thousand mails per user as IMAP with a good performance?

Thanks

[/quote]

 

Neither, the mailbox format is the Pegasus Mail file and folder format.  I use Mercury/32 IMAP4 with SquirrelMail to provide web mail services and find it works quite well over a broadband connection.  Thousands of message may or may not be a problem.  I open folders with a couple thousand messages with no problem; I generally shy away from opening folders with over 10K messages because it's slow.  My personal account has a few hundred separate folders and many thousands of messages.  Whether it will work for you or not is really based on the number of concurrent users, the capability of the hardware you are using and the bandwidth.  The mail clients also come into play here, some are a lot better than others.

 FWIW, the IMAP4 protocol is a very busy protocol and does put a lot of stress on a system.

  

> Hello,
>
>  we are running Mercury32 4.51 on Windows XP and Windows 2000
> Server as IMAP-Servers and Mercury Pop3 Server module 1.48 on
> Netware 6.5
>
> On both IMAP- and Pop3-Servers the Client has to login with
> the full Novell-Name like .User.Context.Tree to authenticate
> with Novell NDS.
>
> To make things easier for our Users is there a way to make a
> login with only the Username (without the Container and Tree)
> possible?

This is what I see in the readme.nds for POP3, it's probably good for IMAP4 as well:

11: POP3 server considerations

Under NDS, it is possible to have exactly the same username defined in
multiple contexts in your NDS tree. This can pose a problem for MERCNDSP,
the POP3 server, in that when presented with a name like "david", it may
be unable to tell which of several possible "david"s in your NDS tree is
the proper user. To get around this, you can take one of two approaches:

  * Require your users to give a full NDS distinguished name when
    logging in to the server (for example, "david.dev.pmail").

  * Create a POP3 alias file, POPALIAS.MER, in SYS:SYSTEM. This file
    simply equates a simple username (like "david") to the full NDS
    format used for logging in (like "david.dev.pmail"). POPALIAS.MER
    is a simple text file where each line has the form:

        <pop3_login_name> = <nds_username>

    As an example, using the names above, you would have the line

        david = david.dev.pmail

    NDS usernames must be expressed as full paths relative to the root
    of your NDS tree. Each line must begin hard against the left margin.
    Lines beginning with #, * or ; are regarded as comments and are
    ignored.

>
> Usernames are unique.
>
> Thanks for your help
>
>  Anke
>

 

 Thomas wrote:  "There is nothing that MercuryS, MercuryI and Mercury P can do to identity anything in the customers equipment or mail client."

 The Directive says "identify users' communication equipment or what purports to be their equipment"

 I don't think, from that wording, that there's a requirement to identify the type of equipment, or anything in it. All it requires is to identify the equipment, ie, its FQDN or IP address. I assume the second part " or what purports to be their equipment" is avoid providers being in default when they receive mail from spoofed addresses.

 

I agree with the above comments about blocking the rest of the world being not the smartest method to combat spam. However, if you want to use this approach for some reason you could do it by using the Blacklist feature of MercuryS and either query the ip-to-country list at http://countries.nerd.dk/ for uk.countries.nerd.dk and let Mercury add a header on which you can filter later, or, if you want to block foreign IP's at the SMTP level you could set the strictness level in the Blacklist definition setup to 'range', query zz.countries.nerd.dk instead and block everything above and below 127.0.3.58, which is UK.

To mitigate the effect of blocking foreign IP's somewhat you could also set up a Whitelist in MercuryS and query a public whitelist like http://www.dnswl.org/ before.

Best regards

Nico

buying a license is not = travel expenses, which violates mr bfluets company policy.

And here a PayPal receipt is not the same as a purchase order.

IMHO: The comment & sincere request is fair, and should not be "corrected" as a proff of lack of "petty cash" system.

Fixed

Yes. Moving a message from the queue effectively kills it.

Cheers!

-- David --

If it's a legitimate sender you could contact him to have him update his addresses. Or you could allow more failed RCPTs, or remove that restriction altogether.

/Rolf 

[quote user="Thomas R. Stephenson"]

Correct.  The bounces are generally coming at the time MercuryE is talking to the receiving host but you should still get a bounce message .  I run a number of lists using VERP and I always get a bounce message pretty much telling me why the connection failed.  Are you not seeing any bounce messages at all?

[/quote]

Yes, I do get some bounce messages but I didn't think I got all of them. Perhaps I do - I will start paying more attention to them and, heaven forbid, perhaps even keep copies of them.

Thanks for the reply.

[quote user="jatubio"]

Hello, today i a have a very, very bad day [:S]

 
I don't know why, but my ip server is listed into spamcom spam lists... Now i can't send mails to many of my big clients.. 

I need one  fast solution. I have think to get one cheap mail hosting and 'reroute' Mercury SMTP mails through new server.

It's possible to config Mercury to do this??

This is one possible solution? O maybe no solution because the 'ip source' of e-mails is the mine (black listed)??

Thank you in advance.

 
PS: Sorry for my bad english
 

[/quote]

 

Unload the MercuryE protocol and load the MercuryC.  You point MercuryC at your ISPs SMTP host to send the mail.  If you might need to find another SMTP host because you might be caught in a block type blacklisting.  Hard to tell anything more since you provided nothing in the way of domains and IP addresses for us to work with.

 

 

 

I came across PLAIN authentication in a FileMaker Pro plugin once, and that one could also do the LOGIN authentication - so it worked.

In this case, the point was to chech the session log, to see why the authentication failed - and if it is using PLAIN, then change the client behaviour if possible.

At the SMTP level, Mercury is very strict on proper addressing standards being used. This dates from the days of "services" like ORBS, that would try to trick a mail program into relaying mail, often using tests that involved addresses in illegal formats.

In a plain mail message, having an address without "<>" is generally OK, but in the SMTP transaction state, it's quite illegal, and it's my guess that this is where the problem is occurring in your case. Your best bet is to get the application generating the faulty addressing corrected.

Cheers!

-- David --

[quote user="Heini_net"]

i let all my Mails on my MercuryMail-Server. but after it has changed the timezone to Winter-Time so my E-MailClient download all e-Mails again. whats wrong ?

[/quote]

It's only quite recently that I've been able to work out exactly why this was happening. It turns out the problem is a clear bug in Windows - see this link for more: . It turns out that Windows incorrectly applies timezone variations even to files that were not modified when that timezone variation applied! In other words, a file modified at 9am before daylight savings time will appear to have been modified at 10am after daylight savings comes in, even though that's obviously nonsensical.

I'm trying to find a solution for this, but it is likely that the solution will cause some initial pain - i.e, the first time you switch to the new method, you'll probably get all your mail offered to you again, but it will be the last time it will happen. The solution will be available in v4.53, which will be out before the end of the year.

Cheers!

-- David --

This isn't mentioned explicitly in the manual, but as correction messages preferably should be forwarded to SpamHalter without any changes I believe you need to send them separately.

/Rolf 

[quote user="dkocmoud"]

Mercury currently doesn't have the ability to change the Sender header from to listname@domain.com.

[/quote]

You also would never want to do this - it would result in too many errors, bounces and other assorted malformatted kruft being redistributed to the list when problems occurred.

As I mentioned in another thread, I'll see what I can do about this, either by adding an option to suppress the "Sender" field, or by allowing its content to be changed.

Cheers!

-- David --