Applying config by XML API | MDaemon Technologies, Ltd.

Applying config by XML API


  • Hello! I'm using the XML API to add addresses to the sender blacklist. Using SenderBlock action="set", but the addresses added in this way don't work until I go to the MDaemon Configuration GUI and click the Apply button in any menu. What should I do to apply addresses immediately after adding them via the XML API?



  • I'll look into this. It is posible that the MDaemon service is not reading the updated data and I may have to signal it. Will report back here my findings. May find a workaround for you for the time being and will create a work item for a permanent solution.


  • Maybe, as a temporary solution, it is possible to use some other xml api method that will force MDaemon to re-read the configuration file without making changes?


  • For now... After modifying the Sender Block List, use the CreateSemaphore operation and create "SENDERBLOCKLIST.SEM"

    Version 24.5 will no longer require that extra step. Solved this is several Settings_Security related areas.


  • @Keith This doesn't work. I'm making the following request:
    <MDaemon>
    	<API productversion="23.5.2" serviceversion="23.5.2.6">
    		<Request verbose="0" echo="1" version="23.5">
    			<Operation>CreateSemFile</Operation>
    			<Parameters>
    				<Semaphore filename="SENDERBLOCKLIST.SEM"/>
    			</Parameters>
    		</Request>
    		<Response version="23.5" et="0.000320">
    			<Status id="0" value="0x00000000" message="The operation completed successfully."/>
    			<Result>
    				<Semaphore filename="SENDERBLOCKLIST.SEM"/>
    			</Result>
    		</Response>
    	</API>
    </MDaemon>
    In GUI I see: SENDERBLOCKLIST.SEM unknown semaphore file found and deleted.
    I looked in the MDaemon's manual in the "Semaphore Files" section and didn't find such a file name there. Any ideas?

  • In version 23.5, that would have been "SENDERBLACKLIST.SEM"

    Apologies... Seems that even SEM file names changed when the push to change from Black/White to Block/Allow occurred.

     


Please login to reply this topic!