Given that a user edited procmailrc with a broken editor that recodes the whole
file to non unix line termination codes (like DOS, Mac) procmail is not able
to interprete procmailrc properly. This causes unpredictable behaviour.

Unpredictable behaviour includes things like saving mails in an mbox folder
called ".^M" (sic!) or other bogus and random filenames. For normal skilled user
this is equivalent to data loss but you also could think of circumstances where
procmail behaves in whatever catastrophic way.

Since the undesired recoding of line endings could easily happen in mixed
environments and this accident is not transparent to the end user nor does it
provide any instant feedback, this case should be catched by procmails parser.

Am 2006-11-09 21:18:30, schrieb Peter Niss:

There is not a singel Editor under GNU/Linux which does not handel
this files correctly.  Even OpenOffice.org do the right thing.

A NORMAL SKILLED USER does not edit a procmailfile under Windows.
How do they get it?  A NORMAL SKILLED USER which get a UNIC file
and try to edit it under windows, will get a Band-Worm sine Win
does not understand UNIF files and its line-endings.

Do you nuo understand it?

"^M" is a legal character (procmail is 8-Bit-Clean) and if procmail
recognize "^M" as linebreaks, it will break MANY recipes and scripts.

If you want to edit files under Windows, use

    1)  get th efile and do 'unix2dos <file>'
    2)  On windows edit <file>
    3)  Transfer it back and do 'dos2unix <file>'

Thanks, Greetings and nice Day
    Michelle Konzack
    Systemadministrator
    Tamay Dogan Network
    Debian GNU/Linux Consultant

Hello Michelle!

Michelle Konzack wrote:

Yes, that's right.

I am talking about mixed environments with network filesystems. Wordpad
can display UN*X files properly, but -- unexpectedly for normal users --
not save them properly.

I do not get how you relate your comment to the quotation of my
argument. Yes, ^M is a legal character and procmail interprete it as is
since procmail is 8-Bit-Clean. But this is no contra to the undesired
recoding which is intransparent to the user and breaks things, is it?

But show me one in-production recipe that uses any literal binary
character that are not directly typeable with your keyboard. I am not
talking about umlauts or accents. I mean: do you really have one single
serious recipe that you'd have to edit with a hex editor? Again: I do
not mean characters like ö,ä,ü,ß,í,é and their friends.

Yes, I know this and hundred other ways how to solve this. But that's
not the point. Also any discrepancy between procmail's behaviour and
it's documentation is not the point. The point is usability (this word
seems to be shocking to many hackers), i.e. all serious tools should
either do their very best to guess the desired meaning of their user
input or provide meaningful feedback.

Best wishes,
Peter

I'll see what I can do to make procmail ignore CR characters immediately
followed by NL in rcfiles (only).  This should not break any scripts.

I'll see what I can do to make procmail ignore CR characters immediately
followed by NL in rcfiles (only).  This should not break any scripts.