Imexpire Really Should Error And Not Do ANYTHING On Bogus Input
(Doc ID 2345765.1)
Last updated on MARCH 19, 2019
Applies to:Oracle Communications Messaging Server - Version 8.0.2 and later
Information in this document applies to any platform.
Using: Oracle Communications Messaging Server 18.104.22.168.20171208 64bit (built Dec 8 2017)
The imexpire command seemed to execute (instead of error out) and should not do ANYTHING on bogus input.
An admin just ran the following command by accident:
imexpire -m 1000 -v3 -f host7.imcheck
The accident part is that host7.imcheck is a script for running imcheck.
The output of that script would then be used to create imexpire rule files.
It contains several blocks like this:
echo "Check read flag for uid=username"
imcheck -m user/username/INBOX | grep -i "<0AB4D60B-408A-48FD-BE21-CE8D1CF5A913@domain.com>"
But the person used the wrong input file name (cut-n-paste fumble) when running imexpire.
The output of expire was alarming:
[21/Dec/2017:21:28:44 -0800] host07 imexpire: General Notice: PARTITION (TOTAL): expired 519916 messages
It would be expected that imexpire would not do anything with bogus input and would provide an error that the input was invalid.
As it turns out, it simply ignored the invalid data in the input file, which was the whole thing
and then since there was basically nothing in the input file, it behaved as if there was no input file.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document