A question about procmailrc

[Hongwei Li]

> 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