Re: [exim] Special character in exim.conf

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Bill Hacker
Datum:  
To: exim
Betreff: Re: [exim] Special character in exim.conf
Latrell wrote:

> Hi! All:
>
> I'm using LOGIN smtp authentication. When I use client_send to send username and passwd,
> I found special characters such as $ and ^ will cause authentication fail.
> I've tried to use backslash to escape special character, but it seems not worked.
> What are the all special characters recognized by exim.conf? How can I escape them?
> Thanks in advance.
>
> Best,
> Latrell


Exim is highly RFC-compliant (at least until messed-about with).

While authentication need not use any part of an email address as the
user's login identity, most folks do so,
hence it is wise to adhere to RFC-2822 throughout if at all possible.

Exim authentication quite aside, you can have trouble later if
prohibited / seldom-seen characters find their way into a 'From:'.

There is a handy chart of what characters may appear in local_part
published here:

http://www.remote.org/jochen/mail/info/chars.html

If you *must* use special characters, you may find that they can be made
to work by doing a table or DB or SELECT string comparison such that
Exim 'knows' it is not expected to handle an RFC-mandated 'local_part'
(not 100% tested - see below).

MySQL, CDB, GDB, Berkeley, or flat-file lookup or lsearch examples are
plentiful if you browse for them.

Here is a PostgreSQL example wherein the 'pg_send_login' has no relation
to the user's email address, nor to their POP or IMAP login identity -
it is just a string retrieved from a DB:

plain:
      driver = plaintext
      server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
      public_name = PLAIN
      server_prompts = :
      server_condition = ${lookup pgsql{SELECT '1' FROM mailprof \
                 WHERE pg_send_login='${quote_pgsql:$2}' \
                 AND pg_send_pwclear='${quote_pgsql:$3}'} {yes}{no}}


This has not been tested with the characters you mention, but HAS been
tested with multiple embedded '@', which are otherwise prohibited, so it
may work for you.

HTH,

Bill Hacker