Re: [exim] Problems with colons in addresses

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Jim Cheetham
Date:  
À: exim-users
Sujet: Re: [exim] Problems with colons in addresses
On 08/06/11 02:14, W B Hacker wrote:
> 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.


Very well -- then why does Exim reject the first form, but leave it up
to my configuration to reject the second form?

>>> This then caused a paniclog entry, because I was using $local_part in a
>>
>> Big mistake. You should always quote variables you use for SQL lookups,


OK, that's fair. However, I am using sqlite, and according to the
documentation "The only character affected by the quote_sqlite operator
is a single quote, which it doubles".

> 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
> ...
> acl__m10 boolean 't' or 'f' is then used in subsequent tests which
> generally lead to acceptance within acl_smtp_rcpt.


Generally I have all users in the db for this system, so that might be
useful. Testing by SQL lookup for a valid recipient during _rcpt would
help me, I'm not currently doing that. But I'm sorry to say that I don't
understand how your RCPT_4 is protecting me from doing a SQL lookup in
RCPT_5 ... ? Perhaps I don't understand the implications of verify
correctly.

>>> 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.


I'll be able to test the system again in a few hours. I look forward to
working out some way to make the system better as a result of this :-)

-jim