[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
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
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==?=
ad...@domain1.com
Date: Fri, 18 Jul 2014 15:13:05 +0300
From: =?UTF-8?B?0YLQtdGB0YI=?= ad...@domain1.com
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 mr...@courier-mta.com:
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: 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
Thanks a lot ! :) 2014-07-22 2:52 GMT+03:00 Sam Varshavchik mr...@courier-mta.com: 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
