Davide, I did look at the binary (after my first email) - see the my subsequent email included below for reference:
Further to that email below, It seems that the basic issue is that your doco states that the RC +16 is valid, it does not state that if the 5th LSB is on then filter processing will stop - quite a difference. >So I'm assuming that you check for bit 5 to be on, to stop the filters. >Probably a logical "AND 16" or "AND 0x10". Can I suggest that the next version of xMail limit its errcode interpretation to the published numbers of 0,3,4,5,6,7,19,20,21,22,23 ignoring any other - OR change the doco to reflect actual operation. I still welcome your feedback Davide. Rob :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Arends Sent: Monday, 24 April 2006 1:27 AM To: xmail@xmailserver.org Cc: [EMAIL PROTECTED] Subject: [xmail] Re: Filters stopping with errcode 90 Davide, I have diagnosed this further to be able to say with certainty, that any filter returning with errcode 90 will not run the next filter. (The SMAIL log shows that the offending email was actually delivered, & the user confirmed this.) So the Nett effect is that all filter processing stops and the email is delivered. Having a think about your errcode logic... You document that you can add 16 to the errcode to "stop filter list processing" So I'm assuming that you check for bit 5 to be on, to stop the filters. Probably a logical "AND 16" or "AND 0x10". 4 decimal = 00000100 binary -> stop email, but process next filter 20 decimal = 00001100 binary -> stop email, and do not process next filter 90 decimal = 01011010 binary So that would mean that every alternate 16 numbers would trigger the "stop filters" 16-31, 48-63, etc Or divide the number by 16 and if the integer part is odd then it falls in to the '16' category. It really depends on how you have coded this logic. And I know you never expected some filter writer to return errcodes that were not on YOUR list, however your documentation is clear and I don't believe an errcode=90 violates that. I can probably work-around this by wrapping the EXE in a CMD (not very nice) but this will get around the issue. I'll follow up with Dario about his errcodes, but can I suggest that the next version of xMail limit its errcode interpretation to the published numbers of 0,4,5,6,7,20,21,22,23 ignoring any other. I welcome your feedback Davide, Rob :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davide Libenzi Sent: Wednesday, 26 April 2006 3:44 AM To: xmail@xmailserver.org Subject: [xmail] Re: Filters stopping with errcode 90 On Sun, 23 Apr 2006, Rob Arends wrote: > I'm trying to track down a non-delivered email. > I have found that the root cause was Dario's AVFilter returned errcode 90. > > Which I believe to be 'normal' for a particular behaviour. > > The problem is that the next filter did not execute and the email was > dropped. > The filter is a normal 'in filter' and returns '20' when a Virus is found. > It does return various other errcodes, but not the usual xMail > documented codes. > No problem, xMail just ignores the ones it is not looking for. > > I had this scary thought that, like DOS cmd file, the errcode is true > when the value is equal OR higher. > > So I checked the xMail doco and it clearly states the if the filter > does not return 4,5,6 (and I assume 20,21,22) the message continues. > > "If all filters return values different from '6, 5 and 4' the message > continues its trip." > > I have logs created for filters and smtp, and looking through them, I > clearly see that the email was RECV=OK (smtp), and 2 of 3 filters ran. > See below the filters log excerpt, showing the errcode 90. > > "pre-data" "" "0" "0" "d:\Greylist\glst.exe" > "in" "" "0" "90" "D:\AvFilter\AvFilter.exe" > > So the point is, the filter returned 90, why did the next filter not > fire - why was the email not delivered? > > I was running 1.21 at the time and are now running 1.22, but looking > at the change log, I don't believe there is any difference in filter > handling and execution. > > Does anyone have any thoughts? Now stop thinking in decimal, and look at it in binary: 4 = 00000100 5 = 00000101 6 = 00000110 16 = 00010000 90 = 01011010 For XMail you are returning: = 00010010 ^ ^-----> 2 +--------> 16 - Davide - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
