Hello everyone,
as i described below i ran into trouble with my autoresponder subject.
this was not because of php or database, but the pgsql_lookup in exim
(searching for propper subject)
returns more than one tuple, so pgsql_lookup returns a subject with new
lines :)
the pgsql_statement MUST return only one subject, not more than only one
record....otherwise it will fail with 'unprintable character 10 in subject'
(hmmm what about having multiple subjects *g)
maybe this tip is useful :)
and maybe the autoreply transport could modify the subject, and strip \n
from it.
can i do this by a filter or something like that?
what so you think? thanks in advance
exim 's best ....
greetings,
volker
Development - multi.art.studio wrote:
>This is a multi-part message in MIME format.
>--
>[ Picked text/plain from multipart/alternative ]
>Hello all :)
>
>in regarding to this very old message i found at my websearch, i got the
>same problem now.
>i use an autoresponder-router and transport
>routing is fine, now the transport fails while reading subject from
>databasefield because of 'unprintable character 10'
>ok, i wrote my own form to update database, and strip all \n \r and html
>tags and some 'special characters' from the autoresponder-subject
>but always fail with the same error.
>some links on the net say character 10 is \n, but \n is already
>stripped from the subject......
>i think this problem is not in exim, because buglet is about 6 years
>old... but any needful hints would be very nice 8---)
>
>many thanks in advance
>volker
>
>attached message:
>_______
>-
>[EXIM] autoreply: newlines in text cause it to bomb. Help.
>-
>On Tue, 17 Nov 1998, Mark Buckaway wrote:
>-
>->/ I've created a DB file via perl for Exim to read for the autoreply
>transport.
>/->/ However, there seems to be some unprintable character in the text that
>/->/ exim does not like. The "unprintable" character appears to be a
>newline.
>/-
>-That appears to be a buglet. Exim tests for non-printing characters in
>-the various autoreply options, but it looks as though it is being
>-stricter than it need be. I will investigate in due course. Thanks for
>-the report.
>-
>-
>-Philip Hazel University of Cambridge Computing Service,
>____
>--
>
>
>--
>
>## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
>
>
>
