> Hongwei Li wrote: >>>Hongwei Li wrote: >>>>A correction: from the beginnig of the subject line to the last searching letter should not exceed 65 chars. For example, suppose the subject line is >>>>Acccc Bnnnn ..... Hhhhhh is out of the office >>>>and the matching string is "is out of the", then if the count from A (the first letter of the subject line) to e (the last letter of the matching string) is longer than 65, say 66, then the procmailrc does not function. Then, remove any one letter before "is out...", it works. >>>>Everybody can try it to see if that is the case. >>>>Is there anyway to lift this limit? Since Lotus Notes may add very long >>>> and >>>>strang things in the subject line, it will be very usefull to lift this limit >>>>to 80 chars long or so. >>>That limit just sounds terribly unlikely. The default LINEBUF is 2048, and it cannot be set smaller than 128. I wonder if Lotus Notes is actually word-wrapping the long subject line, e.g.: >>> Subject: Aaa Bbbb Ccc/Xxxx Yyy/Zzzz Dddd/Eeee is out of the >>> office. >>>If your email client reassembles the split line you might not be aware of the split. Procmail does reassemble the split line, but it's possible that whitespace is being mishandled. Procmail's >>>manpage has a noteabout a problem with the embedded newlines in continued headers. Try adding a '+' sign after each space >>>character in your matcher and see if that helps. >>>-- >>>Bob Nichols Yes, "NOSPAM" is really part of my email address. >> No, this time it is not Lotus Notes issue. I sent the test email myself from >> one FC4 system using squirrelmail to another FC3 system, and manually typed the >> Aaaaa Bbbbb Ccccc....Hhhhh Iiiii Jiiii is out of the office >> in the suject line. I found if the total length is 65 or less, procmail works, >> if longer than 65, it does not function. >> Hope more people test it e.g. enter the subject like: >> 123456789 123456789 12...... is out of the office >> to see what happen. > > I ran several tests using your matcher and sample subject lines, and procmail worked perfectly. Then I tried a test with a word-wrapped subject line as I described above, and the matcher did indeed fail just as I thought it might. The problem is that procmail replaces the newline with a space and then concatenates the following line just as it appears, with whatever variant of leading whitespace is on that line. > > Procmail does not recognize the notation [[:space:]] as representing any whitespace character, so the only solution I found is to replace each space character with "[ ]+" (without the quotes, of course, and the brackets actually contain just two characters, <SPACE> and <TAB>). That makes the matcher work correctly regardless of how the line gets split. Yes, it looks like a mess, but I couldn't find anything else that works 100%. > > -- > Bob Nichols Yes, "NOSPAM" is really part of my email address. > I added LINEBUF=2048 at the top of my .procmailrc, but does not change the situation. I was using squirrelmail to tet, then, I tried pine with the subject line as: 123456789 223456789 ... 62345is out of the office the .procmailrc does not work. If I use 123456789 223456789 ... 6234is out of the office then, it works. That is, in pine 67 chars are okay, 68 chars are too long for it. So, it seems that it also depends on what I use to compose the email. Probably, the tool (squirrelmail or pine) wrapped the subject line according to its own rule (probably squirrelmail is 65 chars, pine is 67 chars). Once the subject line is wrapped, it adds extra char(s) in between "of" and "the", then it does not match. So, I tried: * ^Subject:.*is.*out.*of.*the then, it works for all cases. But, it seems that it is not always safe. It may filter some normal emails? Hongwei
