Please send me a private message here on the forum with a working email address - the messages we send to you about this are refused.
/Rolf
Hello All,
I am running version 4.72 of Mercury. I used a website (http://www.ipaddresslocation.org/ip_ranges/get_ranges.php) to construct a list of all U.S. IP ranges and then did a search and replace to construct a properly formatted MERCURYS.ACL file to be used by the Connection Control section of the SMPT module. I am finding that the module re-writes the the file and in the process is dropping some lines. The file is over 500K so perhaps no one has ever made one quite that big or noticed the problem?
I can supply examples but I thought I'd throw this out there first to see if anyone had come across this issue....
Brian
I can't imagine that MercuryS connection control was implemented with that many rules in mind, so it will probably cause a load on the program, and the list may be truncated if any changes are made through the GUI.
Querying an external database through a MercuryS event daemon could perhaps be a better way to do it. I fear that this kind of check may cause a fair number of errors, though.
/Rolf
I'm just trying to limit this server to U.S. only IP's... since the IP numbering system is not consecutive it requires a lot of ranges....
Thx for the suggestion... we'll see what else people come up with.
I have done the same thing, created a script to generate a MERCURYS.ACL, MERCURYI.ACL and MERCURYP.ACL file. All files are about 300K.
I'm also running Mercury/32 4.72. In my environment the files do not get rewritten, Mercury is also not dropping any lines. Maybe you have reached a limitation in the maximum number of lines Mercury can accept. Or could it be that your acl file somehow gets corrupted? Anyway, I'm not having the same problems as you have. Maybe you could test it by creating a file half the size of what you have now (about 250K) and see if that works.
tested with file sizes from 2k to 500+k... same results...
here is a pdf file that shows the orig file and then the corrupted file. The corrupted file was created by transfering the orig to the mercury directory, opening mercury, opening smtp module and then opening and closing connection control dialog. The orig is on the left. Appears to skip a few bytes...
http://www.woofiles.com/dl-206143-CGc08OSb-jjj.pdf
[quote user="briankelly63"]http://www.woofiles.com/dl-206143-CGc08OSb-jjj.pdf[/quote]
The link appears to be a pdf file, but when I click on it (or right click, save as), I just get the woofiles.com start page.
(On different machines & browsers)
I'm a little puzzled at your desire for "U.S. only" addresses. Some of the ISPs will actually route all mail through the U.S. even though the sender's location is actually outside. I used to find that I was "in the US" despite the x miles between the US and the UK.
You probably can't rely totally on the information you get (although it will be largely accurate).
Tom
I can't read the PDF.
I'm a little puzzled at your desire for "U.S. only" addresses. Some of the ISPs will actually route all mail through the U.S. even though the sender's location is actually outside. I used to find that I was "in the US" despite the x miles between the US and the UK.
You probably can't rely totally on the information you get (although it will be largely accurate).
Tom
I can't read the PDF.
I can't read the pdf either. Maybe you can supply the script you use to generate the acl file and the input file you use:?
try this link... I have as of today started corresponding with the technical support folks and have sent them the files but try this link then click download button in top center of page:
http://www.woofiles.com/dl-206145-UQl0DsFN-jjj.pdf
what you will be looking at is a screen shot converted to a pdf file that has the original file on the left and the re-written - changed by mercury file on the right... See how its dropping a full IP address?
brian
[quote user="briankelly63"]what you will be looking at is a screen shot converted to a pdf file that has the original file on the left and the re-written - changed by mercury file on the right... See how its dropping a full IP address?[/quote]
I don't see any addresses dropped in that sample. On the highlighted lines, the IP addresses have been swapped over. The list on the right has them reversed so that the higher address is first. That is the list after Mercury has processed them?
Are there any non-printing characters in the original file?
I have to agree with PaulW. The from..to address range should be ascending, some lines now are descending. I can imagine Mercury having problems with that.
In my case I have never seen Mercury swapping the start and end address, I think something else must have gone wrong. Could be some corruption in the original file, maybe some non printable characters ended up in there.
Paul , You caught something I didn't see which is that nothing is lost its JUST swapped. When looking at this many numbers it looked to me as if an entire addr had disappeared. These reversals would be a problem I would think, who knows how they would be handled by the program.
Well anyway it does this every time...I don't know how intelligent that file writing process in the Connection Control section, perhaps its trying to apply some logic to arrange the ranges and there is an issue in doing that? Anyone have access to that code portion?
If someone else would like to try loading either the 2k or 600k file to see if its gets changed on your system here are the links...
http://www.woofiles.com/dl-206478-4JCSpRHT-premercurys.acl
http://www.woofiles.com/dl-206479-ZNY37zUR-prelrgmercurys.acl
remember the download button is in the middle of the page, ignore the empty file box on the left...
Brian
Here's an interesting tidbit... I tried making the mercurys.acl file "read only" just to see what the effect would be.. Well it did in fact prevent the file from being changed by Mercury but when you open the connection control dialog box the addresses have been swapped in memory even though the fresh source file was unchanged ! Making the file RO just prevents Mercury from writing those swapped values out to the file and "corrupting" it...
So..... it would appear that there is an internal issue with the way Mercury builds the dialog box / list / array from the original file.
brian
This is quite simple to replicate and will be examined to see where it occurs and what else is affected.
The problem happens when ranges have the starting last octet higher than the ending last octet - so your 12.1.52.72-12.4.123.79 is OK, but 12.18.45.232-12.19.193.159 is not.
The re-ordering appears only after a restart - as you have stated.
