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.
