Hi Paul, thanks for your response.

The trial was being conducted externally.

We now know what happened - when the tester set up IMAP, instead of using the MercuryS server address for SMTP authentication, they used their own ISP. This is why they were still able to send email after the Mercury32 re-installation.

Sorry for the confusion.

Hi

We have recently setup IMAP and have no problems using it. The configuration for the SMTP server MercuryS has both relaying controls checked.

Before we set this up, we had been trialling Mercury for several months using dummy accounts and had IMAP working, but with no relaying controls in place. Unlike the SMTP and POP3 trial, IMAP referenced a valid Pegasus account. After the trial, we uninstalled Mercury, deleted the local Mercury folders, then reinstalled and configured it to use genuine accounts.

The server IP address is the same as before, and what we have discovered is that the tester who used IMAP to reference the Pegasus account, can still send email via IMAP, even though the relaying controls are in place and SMTP authentication had not been setup. New IMAP accounts setup after the reinstallation were unable to send email, obviously. IMAP is setup to connect via an IP address, and the user in question uses the same username and password as was used for the trial and still uses the same IMAP account used during the trial.

I don't understand why the old IMAP account is allowed to send email via the SMTP server. I have asked the user to delete the IMAP account, and set it up again just to see if they can still send mail.

The test IMAP account was setup on a WinXP Pro SP2 PC, using Outlook Express 6.

From Mercury help:

In normal anti-relaying mode, Mercury will accept mail for delivery if either the recipient or the originator has a local e-mail address. If neither address is local, Mercury will compare the IP address of the connecting host to its connection control list (see above): if it finds an "allow" entry in that list that explicitly includes the connecting machine, then it will accept the mail, otherwise it will be failed with a diagnostic like "553 - We do not relay...".

In strict anti-relaying mode, Mercury follows the normal rules described above, but if the "From" address appears to be local, then Mercury will search the connection control list and will only accept the mail if an "allow" entry appears that explicitly permits the connecting host.

If strict local relaying is checked then the IP address of the client should be marked as allowed in the Connection control table to be able to send mail to non-local recipients (if authentication isn't used). It makes no difference if the client uses IMAP or POP3 to get mail.

/Rolf
 

I understand this, and have read the Mercury help manual concerning this. My point is that the old IMAP account should not be able to send email using the MercuryS server. The IMAP account is from the testers home PC - it does not have a static IP address, therefore no IP address can be authorised to use MercuryS. Because no relaying controls were in place, the old account was able to send mail, obviously. I am still waiting to hear if the person has deleted the old IMAP account and created a new one, and tried to send mail.

You don't state whether the tester was accessing the server externally or on the same lan (some ISPs intercept any SMTP transactions and route them through their own servers).  Also, check Mercury logs and the headers of the emails to confirm the exact routing of these messages.