Re: [exim] Problems with colons in addresses

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim-users
Subject: Re: [exim] Problems with colons in addresses
jh@??? wrote:
> Jim Cheetham, 2011-06-07 11:55:
>> A user managed to submit an email to a local_part beginning with a colon
>> (:info@domain)
>>
>> Normally this would be rejected early on, but their mail client managed
>> to sneak the offending character in by wrapping it in double quotes ...
>> (":info"@domain)
>
> That's not sneaking in, it's just quoting. His MUA probably dit it for him.
>
>> This then caused a paniclog entry, because I was using $local_part in a
>> DB lookup : "... and users.lhs='$local_part' and ..." and the message
>> remained undelivered. Every time the queue is run, this message panics
>> again.
>
> Big mistake. You should always quote variables you use for SQL lookups,
> e.g. "... and users.lhs='${quote_mysql:$local_part}' and ...". Otherwise
> you are prone to SQL injection attacks. (See also http://xkcd.com/327/).
>


Seconded. And 'Bigtime'!

quote_<flavor>sql is *essential*.

One can further protect by doing a router-walk recipient verification
BEFORE the SQL is actioned at all. Useful if, for example, all users are
in the DB *except* certain otherwise-valid system aliases.

====

  # RCPT_4: IF not a valid recipient, THEN deny
  #
   deny
     !verify     = recipient
     message     = Mis-typed or Invalid address or Format.
     log_message = $acl_m2 $local_part@$domain invalid address


   # RCPT_5: IF address in our domain AND active AND valid user
   # THEN flag for later acceptance
   #
   warn
     set acl_m10  = ${lookup pgsql{SELECT pg_active from mailprof \
                   WHERE pg_active AND \
          pg_domain='${quote_pgsql:$domain}' \
                   AND pg_local_part='${quote_pgsql:$local_part}'}}
     log_message = R5 $local_part@$domain is a valid recipient


====

CAVEAT: We use SQL in most routers/transports, so they ALSO need
quote_<flavor>sql so that verify router-walk does TRT.

NB: acl_m2 is carrying info about the sending host to anyone who needs
it for logging

acl__m10 boolean 't' or 'f' is then used in subsequent tests which
generally lead to acceptance within acl_smtp_rcpt.

But not always, even there.

Further:

- the exim daemon's DB connection ID is allowed read, not write

- User mail profiles are managed with separate tools, not Exim or Dovecot.

- the smtp UID:PWD, IMAP UID:PWD, and DB update UID:PWD are all
independent of each other and have different privs GRANT'ed.

'belt and braces'.

But also peace of mind, robust, even 'cheap', as the initial extra work
invested at Exim 4.4X and PostgreSQL 7.X has needed no alteration
through the present day in either ~/configure or the DB, now at
PostgreSQL 9.x.

QED

Bill

>> I tried playing with a test in acl_test_rcpt for this on a scratch
>> system, but didn't manage to get it right, even though I remembered to
>> double the colons :-)
>>
>>> deny    message     = Restricted characters in address
>>>          local_parts = ^[./|] : ^.*[::@%!] : ^.*/\\.\\./

>
> This works here. Run a test session with "exim -d+expand -bh
> some.ip.add.ress" to see what goes wrong.
>
>