Thank you for the quick reply, Rolf.  Yes, I will be making a back-up, though at over 6.5GB, this may take a while.

Thank you for the clarification, it's a pity that the SSL options are only for Mercury S.

I would be very happy to use a VPN, which is what I have been using with my WinXP laptop.  However, the Motorola Xoom tablet, which I have recently acquired, runs Android.  This doesn't seem to be supported by Road Warrior.  There is an Android client available for OpenVPN (the VPN that I have been using), but it requires me to "root" the Xoom.  This potentially voids the warranty, which I don't want to do so soon .... I may do this in a few months.  From what I have read, the VPN situation on the Xoom is a real can of worms at the moment.

Gordon

Can someone tell me whether there is a maximum defined size limit for the number of entries in access control lists, e.g. MERCURYI.ACL?  I imagine that there may be practical limitations in terms of the time it takes to examine such lists when a connection is made.

Also, when a connection is set up, are ACLs consulted only during the initial set-up or are they used many times during a session?

Thank you

Gordon

I think that I have been able to answer part of my own question.  I have just re-read the information about the 4.73 changes, which contains the following:

*    ACL range corrections  In previous versions of Mercury, access controls would not work correctly if the address range exceeded 256 addresses, and would occasionally work incorrectly with particular address ranges. These problems have now been fixed.
 

I presume, therefore, if I update to 4.73 (currently 4.72), there will be no pre-defined limit to the number of lines that can be put in the .ACL files.

I am still wondering about practical limitations .... if I have hundreds (say 1,000) of address-range entries will processing become really slowed down?

Gordon

> I think that I have been able to answer part of my own question.  I have just re-read the information about the 4.73 changes, which
> contains the following:

> *   ACL range corrections  In previous versions of Mercury, access controls would not work correctly if the address range exceeded
>     256 addresses, and would occasionally work incorrectly with particular address ranges. These problems have now been fixed.

This had nothing to do with the number of entries but had a lot to do where the entry passed the 256 limit on a IP address.

> I presume, therefore, if I update to 4.73 (currently 4.72), there will be no pre-defined limit to the number of lines that can be put in the
> .ACL files.

Correct there was no limit before except for the OS limits on a file.

> I am still wondering about practical limitations .... if I have hundreds (say 1,000) of address-range entries will processing
> become really slowed down?

Quite possibly since each and every time a IP address is received it's checked against the listing.  Even if all of these are read into memory I suspect that a lot of CPU cycles will be wasted checking this listing.

FWIW, why are you going to have thousands of these anyway?  If this is for anti-spam there are a number of other much more effective methods.

There is no set limit to the number of ACL entries, but a large amount of range entries it will of course slow down connection handling some. On a busy server the hardware may need to be upgraded.

Hardware is cheap these days, though, but maintaining an IP filter system involving a thousand address ranges sounds like an undertaking that may cost a lot of time.

The ACL change in version 4.73 was to fix a problem that could happens with a range covering more than one segment with 256 addresses, and didn't actually make any difference for the size of the list. There are other important changes in 4.73, though, so an upgrade is highly recommended anyway.

/Rolf 

Thank you for the clarification.  I obviously misunderstood the description and intention of the ACL improvement.

I am going to update to 4.73.  Can you confirm that, if I do so, the process will not touch any other (not belonging to the basic Mercury package) files and folders that are in the main MERCURY folder?  They shouldn't really be there, but it's taking me a while to clean this up, as they have accumulated over two to three years.  However, I can't move them all at the moment.

My reason for being interested in the access control lists is with repect to the IMAP4 server ... not related to SPAM control.  I saw the possibilty of only allowing IMAP connections related to the places where I expect to travel. However, on reflection, this is almost certainly a bad (and probably unnecessary) idea.  I looked at the Canadian (where I live) IP address list and it contains over 4000 ranges.  The US one is larger, though not as much as I would have expected (the US list seems to be more contiguous).  These numbers could be reduced, because of the presence of contiguous second octet ranges, but I don't think that it is worth the bother.  By using Mercury's SSL/TLS capabilities, I am presuming that this will be safe enough.

Also, if I interpret it correctly, I think that 4.73 will allow both SSL/TLS and secondary unprotected connections, the latter being potentially useful for connections within my LAN.......

Selective SSL options  The MercuryS SMTP server now has options that allow you to enable SSL support on the primary and alternate SMTP ports selectively (so, you can have SSL enabled on the secondary, but not on the primary, ideal for submission by your remote users). There are also new Access Control permission settings in the MercuryS ACL editor that allow you to enable or disable SSL based on the IP address of the connecting client.
 

I hope that I am interpeting this one correctly :-)

Thank you

Gordon

The 4.73 update will mainly replace .exe and .dll files, which means that Mercury must be shut down when doing the upgrade. It won't attempt to remove anything from the Mercury directory. Still, it's always a good idea to have a current backup before doing an upgrade.

The selective SSL options are for MercuryS.

If opening IMAP to the Internet makes you feel uncomfortable a very safe alternative might be to use a certificate based road-warrior VPN connection to your LAN (assuming that your router/firewall can be configured for that).

/Rolf