3

I have setup exim to get autoreply text from an sqlite database. It is sending the autoreply just fine with the exception that I can't get new lines in the autoreply.

This is the line in the transport:

text     = ${lookup sqlite{SQLDB \
              SELECT body FROM autoreply WHERE \
                (username='$local_part' AND domain='$domain') \
              AND (sender ='$sender_address' or sender ='$reply_address' or sender ='*') \
              AND enabled=1 \
              AND (valid_from <= strftime('%s', 'now') OR valid_from IS NULL) \
              AND (valid_to >= strftime('%s', 'now') OR valid_to IS NULL) \
              LIMIT 1\
            }\
          }

As I mentioned, this is returning the proper text, the email just contains the actual characters \n instead of new lines.

I've tried things like \\n and nothing works.

I've been searching online for quite a while and I can't find anything about doing this or anything saying it can't be done.

mhost
  • 1,159
  • 3
  • 16
  • 25

1 Answers1

1

I'm assuming that you've stored the newlines as escape sequences in the database, meaning the string "\n" rather than the actual newline character. The sqlite lookup will return exactly that, and Exim will happily put the string as-is into the autoreply message. The reason is that the lookup is already a string expansion; you could use it as part of another string, in which case Exim would replace it by whatever is in the database. Exim won't expand it a second time.

In order to have Exim expand the character literals on the lookup result, you need to tell it to do so explicitly by surrounding the whole lookup with an expand operator, like this:

text = ${expand:${lookup sqlite{SQLDB \
                                SELECT body FROM autoreply WHERE \
                                ...
       }}}

Exim will then take the string returned by the lookup and perform expansion on it. For details, see the Exim specification, Chapter 11, Section 6, regarding the expand operator and Chapter 9 regarding file and database lookups.

Fabian Fagerholm
  • 121
  • 3