[quote user="Peter Strömblad"]If Mercury can't locate the user accounts, it can't decide whether or not to accept inbound mail. Maybe it shouldn't crash as you say, just say service unavailable on all ports.[/quote]
I think i might done this. I added two spam options, zen.spamhaus.org and bl.spamcop.net
Both are active at this time. The error above was neglected and the two test descriptions i made (very far earlier) earlier, were deleted. Both options are here and i'll see later if it works. Now it says:
Wed, 20:07:22 SpamHalter 4.4.0 started Wed, 20:07:22 ClamWall 1.3.0.95 started Wed, 20:07:22 GrayWall 1.1.0.117 started Wed, 20:07:23 Program started
So i'll wait for the first idiot to come by ((-:
Thanks again...
Anne
I did a test from spamhouse.org and after some time i got a message back saying it worked. The other i have to check still.
It's not that hard, i did install spamhalter in Mercury but that program gave the error that it did not work. I do not know where to put an adres of a blacklist but i'll look for that too. At this time i shut that down.
I just copied the contents of my Google Apps account to the Mercury IMAP server using IMAP Sync from (free registration required for download, but they accept throwaway email addresses).
I don't know yet if it syncs automatically, though.
What IMAP commands are supported by Mercury IMAP module?
The character set functions are no supported as it shows in the session log. There is no server side sorting either. It's pretty much the simple UW version of IMAP4.
Ok then it looks like the local user does not exist. Possibly you did not restart Mercury or use the CTRL+Configuration+Manage local users when creating the new user.
we use Mercury/32 als Server for our domain. The MX points to our Mercury.
We have a branch office, which is connected via a vpn connection over DSL to our network. At the moment, all mail traffic goes to our Mercury, which delivers the mail. What we like to do is setting up an extra Mailserver in the branch office, so that they can use that 2nd server as a local server and any outgoing mails from the branch office should be forwarded by that 2nd server and the 2nd server should also pull incoming mail from server 1 and distribute that mail than in the branch office.
All users have the same domain part in their address, there should be no subdomain in the mail address.
How can we set this up, so that from both servers, all users of the domain can be reached?
1. Set all users on the primary Mercury system and then have the secondary system pull the mail via MercuryD from the primary. The secondary Mercury should setup a domain like sec.domain.com and alias all users to that domain so that the local mail stays local. They still will use the when sending the mail. MercuryD will use the address user@sec.domain.com when delivering the mail to the local user.
2. Setup the Secondary Mercury so send using MercuryC and use the primary MercuryS as the relay host.
There are other methods that can be used as well but this is the simplest and most reliable since it is a pull system. You might want to checkout the use of Petr Jaklin's daemon for redirecting mail if the secondary system is connected full time.
There isn't enough information to say exactly what's wrong, but I could give you some pointers for you to start checking on.
- MX records are expected to contain an A record or a CNAME record, never an IP address.
- Make sure there isn't a firewall blocking access to mail ports on the PC running Mercury.
- Make sure there is a port forward from your Internet modem/router/firewall to the Mercury PC for mail services that should be available from the Internet (SMTP and perhaps POP3 and/or IMAP).
- Verify that the Local domains section in Core configuration is properly filled in (see Mercury help about this).
- Check the console windows in Mercury for error messages.
Hi again! I tried and changed for Outlook SMTP server from Mercury.NLM (on NW 5.1) to Ipswitch IMail (all other route is same) and ... subject didn't disappear! See two part of headers, first sent via Ipswitch IMail and second one via MercuryS (NLM). More thanks, Alar.
[quote user="tdawson"] We use SQL Server 2005 and are testing using Mercury to handle some simple mail lists for us. It appears that Mercury (or maybe the MAISER component) is having trouble with the BASE64 encoded emails generated by SQL Server 2005. [/quote]
You need to write a CLR-routine to send the message as plain text, or process the database mail-queue from an external "maintenanceapp". We've internally taken the second path, since the sql-2005 built-in mailer non changeable base-64 encoding gives problems with f.ex. squirrel mail and other clients as well, plus we can combine other actions outside the db in a separate app.