> When I choose the solution with "MercFwd daemon", can the Mercury server perform all the following
> tasks before the "MercFwd daemon" forwards all the emails to the Postfix server?
>
> the tasks would be as follows:
> - Graywall,
> - Spamhalter,
> - SMTP transaction filtering,
> - Content Control/Filtering rules,
> - and virus checking

 Yes, since all you are doing here is using a daemon in the domains section to change the RCPT TO address and core uses this to send the mail off to the other server after all receipt processing is completed.

.

The detailed logged revealed it was an SSL error which I fixed. Thank you for your help.

> If someone knows the answer to the does Auth or DNSBL happen first, I would still be interested to have the answer to that question.

Blacklisting happens upon connection by the sending system when MercuryS checks to see of the connecting IP address is blacklisted. Authentication happens much later in the process after the receipt of the EHLO string.  If you do a session log from a blacklisted address it becomes readily apparent when the blacklisted connection is rejected.

What you can do though is tag using the blacklist instead of rejecting and then later in the receipt process done by the core module setup some sort of filter based the header added to the message.

Thanks for your help Thomas.

It turned out that the problem was with the firewall protecting the Mercury server.

I'd not allowed traffic to port 993 and of the various mail clients I was testing IMAP SSL connections with, only Outlook used that port.

Regards

Richard

Thanks Rolf, that is very helpful.  This is the behaviour I expected to see, and think I did initially.  I will check on the settings you suggest!

Thanks again for your time
Ormo 

Hi Theresa,

I've upgraded Mercury a few times and I've never had a problem with configs or other settings so I can't see it being a problem for you. Just make a sideways copy of your mail folder before you do.

However, have a look through the forum at the issues raised by poeple since they've upgraded! We've been running 4.72 with no problmes for ages and have recently upgraded - I'm now looking at rolling back to 4.72 as I'm unhappy with a particular issue I have.

Regards

Dave.

Thanks for the reply. Much appreciated.

 Duncan

OK, I think I'm done now, executed the following steps;

1. stopped Mercury
2. created RAR archive of Mercury directory in Program Files
3. created RAR archive of Mercury directory in VirtualStore
4. deleted Mercury directory in VirtualStore
5. created C:\Mercury and moved all contents of C:\Program Files\Mercury over
6. extracted the RAR archive of the VirtualStore into C:\Mercury, overwriting existing files (assuming that the last files written would always be in VirtualStore, so these should be the correct ones)
7. Modify C:\Mercury\Mercury.INI and change all filepaths to point to the new files/folders in C:\Mercury
8. Assumed ownership off C:\Mercury including all underlying files and folders
9. Modified rights so regular users have full control over C:\Mercury and all underlying files and folders
10. Modified all links in the startmenu to point to the new location in C:\Mercury
11. Disconnected network
12. Started Mercury and paused POP3 retrieval (to prevent loss of newly retrieved emails in case of a restore)
13. Reconnected network
14. Started mail clients and verified everything working fine (duplicate issue and deleting old messages)
15. un-paused POP3 retrieval (to restart processing incoming mail)

The tricky part was merging the users folders, as a lot of files where overwritten. In the other folders it were merely settings, logs, or empty folders. All in all it seems to have worked out fine, though I probably won't be sure about that for at least a couple of days.

Just posting this as it might help someone else out.

[quote user="royhink"]

I would really appreciate some configuration pointers as I am a non-IT Tech trying to install Mercury32 on my Win2003 server.

This install only needs to handle outgoing email thru our smtp host, Rackspace, which requires authentication. Plus, there is only 3 'users', the three ShopSite eCommerce platforms on the server. ShopSite sends out a confirmation email after the purchase.[/quote]
Before going any further, I want to be absolutely clear on something...  Those "ShopSite eCommerce platforms" are running on the same server that you have installed Mercury on, right?  I'm going to continue based on that assumption; but if it's wrong, PLEASE say so ASAP.

[quote]ShopSite simply asks for a smtp host name.[/quote]
That should be OK -- i.e., not a problem.

[quote]I've installed Mercury32 with  MercuryS, MercuryC and MercuryX,[/quote]
I agree with "dilberts_left_nut" on this one -- you do not need the MercuryX module for this application; and in the interest of simplicity, you probably ought to disable it.

[quote]and configured MercuryC with the host name and credentials, and get the following:

Sendmail failed; SMTP server error: 553 We do not relay non-local mail, sorry.[/quote]
This is of course the critical part; but here, I'm not nearly so certain that "dilberts_left_nut" was correct.  The mention of Sendmail implies that it may be your smarthosting provider (i.e., Rackspace) which is generating that error message.  If that is correct, then it would seem that MercuryC is failing to properly authenticate itself with Rackspace's SMTP server.  I suggest that you double-check the MercC configuration settings, especially make sure that "Authenticate via prior POP3 connection" is NOT checked, and that you have correctly entered the username and password that Rackspace gave you in the appropriate fields (yes, upper/lower case counts!).

[quote]I also want to be sure that it is restricted to only sending from the ShopSite stores.[/quote]
Way back when I first set up Mercury (v3.01, IIRC), I needed to do something similar because the server itself was co-located some 3,000 miles away, and effectively open to the general internet (hence, proper authentication and strict relaying control was absolutely required); but the mail client (a very old version of Eudora) that I was loathe to abandon (and still am, mostly -- at least to the degree that I still use Windows at all, which is waning steadily) did not support SMTP AUTH.  My solution was to run two copies of Mercury...  One on a local box to which my desktop system(s) could connect to directly via the LAN, which in turn relayed to the "real" mail server at the co-lo site.  This scenario largely mimics your situation; where the "local copy" is analogous to your Merc install, and my co-located and remotely administered Merc server corresponds to your smarthosting provider's (i.e. Rackspace's) SMTP server.  The key to making it all work, while still keeping it secure, was to create two specific entries in the "Connection Control" pane of the (local) MercS configuration screen:  Namely, a general "Refuse" definition for the entire IPv4 netspace (0.0.0.0 - 255.255.255.255), followed by an "Allow" entry for just the local LAN segment (192.168.0.0 - 192.168.0.255), then UNcheck all four checkboxes under "Relaying control".  With this setup, any workstation on my local network could connect to the local copy of Merc and relay mail through it, without needing to use SMTP AUTH (or any authentication at all, for that matter); but since ONLY clients on my local network could connect to it at all, it was still protected against unauthorized relaying (such as by spammers).

[quote]Any help greatly appreciated.[/quote]
You're quite welcome.  I hope this has been helpful.

[quote user="forum user"]
"mydomain" isnt mine. i have "oapplications" the domain name.[/quote]
Which means you should not use "mydomain" as an example.  There IS a domain which is maintained for precisely this purpose, and it is called (surprisingly enough...) "example.com".

[quote]i changed and now i have as bellow:

mailqueue:       C:\MERCURY\QUEUE    # Where mail should be put for delivery
smtpqueue:       C:\MERCURY\QUEUE    # Where the SMTP client should look for mail
newmail_path:    C:\MAIL\~n    # Where to find the users' WinPMail mailboxes.
[/quote]
So far, so good.

[quote]i added in Mercury at "Manage local users..." a user,"mail".[/quote]
Do you have something against using sensible user-account names?  How is "mail" supposed to distinguish between various users (or various role accounts, for that matter)?

[quote]i see in C:\MAIL\   the mail folder and PMAIL.USR file.[/quote]
Do you mean to say that the PMAIL.USR file is actually in ~/MERCURY/MAIL/ and not in ~/MERCURY/MAIL/MAIL/ ?  If so, that is potentially a problem, especially when you go to add additional user accounts.

[And as a side note...  Yes, you WILL need to add additional user accounts, even if for nothing else besides "postmaster@..." and "abuse@...", both of which are required by the relevant RFCs for any domain which sends or receives mail.  If you operate a web site, you probably also ought to have "webmaster@..."; but AFAIK this is not strictly required.]

[quote]the first three at "Relaying control" are checked.[/quote]
Good.

[quote]i tested again and i found the email in mail\mail folder (the other incoming strange mails from strange users seems to be refused fine).[/quote]
You can confirm that by reviewing the log files.

[quote] Thanks for your help.All the good things.[/quote]
You're welcome.  I'm glad that you (apparently) got it (at least partially)  working.

The good news is that your ini file looks overall quite good. The bad news is that sending SMTP mail over the Internet requires port 25. If you can't convince your ISP to allow you to use port 25 you should switch from MercuryE to MercuryC and relay through their SMTP server.

In MercuryS configuration change server port to 25 (and set 587 as alternate if you plan to use that for message submission). Change port forwarding from your Internet firewall/router accordingly, and you should be able to receive incoming mail.

Note that the MX records for the domain points to a different IP address:

 Name=ezish.com

    Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=10

    Preference=21, Mail Exchange=mail2.ezish.com

- Name=ezish.com

    Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=9

    Preference=10, Mail Exchange=mail.ezish.com

Additional Records Section:

- Name=mail2.ezish.com

    Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4

    IP Address=174.37.88.145

- Name=mail.ezish.com

    Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4

    IP Address=174.37.88.145

/Rolf 

Thanks, Sailor21 and Rolf. I really was writing rubbish there. As you say, it's my mail client which is sending the traffic with the incorrect EHLO, nothing to do with Mercury.It has also 'spontaneously' (probably due to a reboot for an unconnected reason) fixed itself.

The client, incidentally, is Thunderbird. I'm not sure where the EHLO is set; can't find it in Thunderbird or Windows.

I did have 127.0.0.1 in hosts, but Sailor's post set me thinking, and in Thunderbird I've now replaced the domain name for Mercury with 127.0.0.1. My intent is that traffic will no longer go via the router, and it is in fact much faster.

 As suggested, thanks, I have whitelisted 127.0.0.1 and my local subnet.

[quote user="Rolf Lindby"]
As you already noticed there is no built-in option to remove MIME parts with HTML coding for mailing list messages. It would certainly be possible to create a policy or daemon to do that, though. Maybe someone already did?[/quote]
That's what I'm hoping; but I know of no such animal.  Is there a "central repository" or similar for Merc add-ons that I could search?

[quote]Rejecting certain attachments during the SMTP session is a bit tricky as the entire message is sent at once. All data is already received when it's decoded and split into MIME parts.[/quote]
Yes, I am aware of that, which is why I'm only looking at this in the context of messages destined for redistribution by the mailing list.  I would then make an exception to my already-existing Global Filtering Rule which (currently) bounces any message with HTML content.

Frankly, I'd like to get rid of that Rule altogether.  Several years ago I lobbied here for expanding the Transaction-Level Filtering function to at least permit testing all the headers, if not the full message (including the body), before having to make the decision to accept or reject; but AFAIK, nothing ever came of that.  Now that "backscatter" is even more unacceptable than it was then, perhaps David will take another look at that idea.

I can't say where the line with the IP address and the asterisks comes from, but it's not added by Mercury.

/Rolf 

> I would like to know how to add the "smtp" address (cant get anything to

resolve) info into the php webpage
> so that my mail server will send the

email.

Depends on the PHP mailer and your going to have to someone else about that.  Most PHP mailers use mail() and that can be set to connect to the IP address of the host running Mercury.  Mercury must have MercuryS loaded and connection control set so that only authorized users can relay mail.  The PHP mailer must use some sort of SMTP authentication to relay the mail off MercuryS. 

There is no separate log for this, but there should be a line in the MercuryS log when an IP address is blacklisted.

/Rolf

Hello,

 to answer myself - to use 'Only authenticated SMTP connections may relay mail' was the solution for this.

Unclear to me was the exact meaning of 'relaying mail' in this context. I can send mail to external recipients, and I can receive mail from external senders. But if somebody fakes a local address, then he must be authenticated, which he will not be. Mail will be rejected. 

If the spammer does not fake, then he will be filtered by SpamCop and the local SpamHalter.

I hope this is correct now - seems to work.

jupiter11

Thank you Mr. Stephenson for your reply. Always learning...[:)]

I checked old list messages and Mercury has been adding a Sender header since at least 2004. So if the on behalf text has started to appear recently it's probably because of some change in the mail client software.

There is no setting for including or not including the Sender header, but you could perhaps rename Maiser to ListServer or something similar if that would make more sense. Other than that it would probably be possible to create a daemon to remove Sender headers from list messages.

/Rolf 

Got everything working. Will donate $5 to David next week if I get time.