Re: [courier-users] Interesting bug - failed to match after adding headers in maildrop
Thanks a lot ! :) 2014-07-22 2:52 GMT+03:00 Sam Varshavchik : > Denis Kanchev writes: > > In the last test we see that the last symbol in subject is missing ( >> compared to previous log ) and the string is not decoded >> The pattern matching fails in last 2 tests. If the logging is the problem >> - the pattern will match and evaluate code inside the condition . >> >> I tested with the latest patches , but the result is the same ( with and >> without mime encoded texts ). And thanks for the previous answer ! >> > > Indeed, this bug depended on the size of the headers, and their order, to > happen. > > It should be fixed in the 20140721 build. > > http://www.courier-mta.org/download.html#maildrop > > > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > courier-users mailing list > courier-users@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Interesting bug - failed to match after adding headers in maildrop
Denis Kanchev writes: In the last test we see that the last symbol in subject is missing ( compared to previous log ) and the string is not decoded The pattern matching fails in last 2 tests. If the logging is the problem - the pattern will match and evaluate code inside the condition . I tested with the latest patches , but the result is the same ( with and without mime encoded texts ). And thanks for the previous answer ! Indeed, this bug depended on the size of the headers, and their order, to happen. It should be fixed in the 20140721 build. http://www.courier-mta.org/download.html#maildrop pgpfbAPeS0uzR.pgp Description: PGP signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Interesting bug - failed to match after adding headers in maildrop
The maildrop rules are just : import SENDER; SENDER=tolower($SENDER) import RECIPIENT; RECIPIENT=tolower($RECIPIENT) RECIP=substr($RECIPIENT, length($HOST)+1) SHELL="/bin/sh" logfile "maildrop.log" # junk to:тест if (/^subject:.*тест.*/:h) { log "Matched" } exit Mail is ( data is not actual :) ): Received: (qmail 23913 invoked by uid 506); 18 Jul 2014 12:13:07 - Received: from domain1.com (123.456.78.90) by domain1.com with SMTP; 18 Jul 2014 12:13:07 - Received: (qmail 1172 invoked by uid 506); 18 Jul 2014 12:13:06 - Received: from unknown (HELO ?123.456.78.90?) (ad...@domain1.com @123.456.78.90) by domain1.com with ESMTPA; 18 Jul 2014 12:13:06 - Message-ID: <52c90f52.4041...@domain1.com> Disposition-Notification-To: =?UTF-8?B?0LTQtdC90LjRgQ==?= Date: Fri, 18 Jul 2014 15:13:05 +0300 From: =?UTF-8?B?0YLQtdGB0YI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ad...@domain1.com Subject: =?UTF-8?B?0YLQtdGB0YI=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Then i test it with cat mail2.eml | /usr/local/bin/maildrop -V 4 -A "Return-Path: ad...@domain.com" -A "Delivered-To: ad...@domain.com" '.maildrop_prev_config' And with this is ok - here is the debug output Matching /^subject:.*тест.*/ against Subject: тест maildrop_prev_config(8): Search of ^subject:.*тест.* = 1 maildrop_prev_config(8): IF evaluated, result=1 But when i add some sybols to maildrop options cat mail2.eml | /usr/local/bin/maildrop -V 4 -A "Return-Path: ad...@domain.com" -A "Delivered-To: ad...@domain.com" '.maildrop_prev_config' It fails and log says Not matched. Matching /^subject:.*тест.*/ against Subject: =?UTF-8?B?0YLQtdGB0YI Not matched. maildrop_prev_config(8): Search of ^subject:.*тест.* = 0 maildrop_prev_config(8): IF evaluated, result=0 Then when i add 1 more symbol cat mail2.eml | /usr/local/bin/maildrop -V 4 -A "Return-Path: ad...@domain.com" -A "Delivered-To: ad...@domain1.com" '.maildrop_prev_config' Matching /^subject:.*тест.*/ against Subject: =?UTF-8?B?0YLQtdGB0Y Not matched. maildrop_prev_config(8): Search of ^subject:.*тест.* = 0 maildrop_prev_config(8): IF evaluated, result=0 In the last test we see that the last symbol in subject is missing ( compared to previous log ) and the string is not decoded The pattern matching fails in last 2 tests. If the logging is the problem - the pattern will match and evaluate code inside the condition . I tested with the latest patches , but the result is the same ( with and without mime encoded texts ). And thanks for the previous answer ! Regards, Denis Kanchev 2014-07-21 13:55 GMT+03:00 Sam Varshavchik : > Denis Kanchev writes: > > >> Matching /^subject:.*тест.*nst >> / against Subject: =?UTF-8?B?0YLQtdGB0YI= >> >> >> Nice - the subject is 3 symbols longer :) , then lets cut more symbols >> from the headers in the options, then we remove 3 more symbols from the >> options and finally maildrop matched the pattern >> > > I can't reproduce this; something like this typically depends on the exact > contents of the message, and the filtering recipe. > > However there is a logging bug in 2.7.1, which affects logging only, in > this manner, and should not impact the actual searching; it's already been > fixed. > > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > courier-users mailing list > courier-users@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Interesting bug - failed to match after adding headers in maildrop
Denis Kanchev writes: Matching /^subject:.*тест.*nst / against Subject: =?UTF-8?B?0YLQtdGB0YI= Nice - the subject is 3 symbols longer :) , then lets cut more symbols from the headers in the options, then we remove 3 more symbols from the options and finally maildrop matched the pattern I can't reproduce this; something like this typically depends on the exact contents of the message, and the filtering recipe. However there is a logging bug in 2.7.1, which affects logging only, in this manner, and should not impact the actual searching; it's already been fixed. pgpGz7s7ZDskg.pgp Description: PGP signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Interesting bug - failed to match after adding headers in maildrop
Hi all, I've found a bug, where mail drop cant match the mail headers ( version 2.7.1 ) . The mail headers are in this order Received: Received: Message-ID: Date: From: User-Agent: To: Subject: Content-Type: Content-Transfer-Encoding: Then i run mail drop with -A option ( to add headers ) maildrop -A "Return-Path: ad...@something.com" -A "Delivered-To: ad...@something.com" And if i turn on the debug - then i see that the last headers are cut and subject is only partial ( or missing ) and the pattern can't match the subject . And there is the proof: We have a subject like this "Subject: =?UTF-8?B?0YLQtdGB0YI=?=" ( decoded is тест ) and filter /^subject:.*тест.*/ , then we run maildrop with -V 4 ( for debug ) and here is the output Matching /^subject:.*тест.*nst / against Subject: =?UTF-8?B?0YLQtdGB0 Then i cut added headers with 3 symbols ( they become something like this maildrop -A "Return-Path: ad...@something.com" -A "Delivered-To: ad...@someth.com" ) and we repeat the test Matching /^subject:.*тест.*nst / against Subject: =?UTF-8?B?0YLQtdGB0YI= Nice - the subject is 3 symbols longer :) , then lets cut more symbols from the headers in the options, then we remove 3 more symbols from the options and finally maildrop matched the pattern Matching /^subject:.*тест.*nst / against Subject: тест I found a solution for this ( and keeping added headers ) Just add xfilter "cat" and xfilter will read the message again ( and all headers ) Regards, Denis Kanchev -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users