Re: [exim] message_size_limit depending on incoming domain

Top Page
Delete this message
Reply to this message
Author: Niels Kobschätzki
Date:  
To: Jeremy Harris
CC: exim-users
Subject: Re: [exim] message_size_limit depending on incoming domain

Jeremy Harris via Exim-users <exim-users@???> writes:

> On 18/11/2019 09:20, Niels Kobschätzki via Exim-users wrote:
>> I know that there is a setting message_size_limit and that I
>> can control it
>> globally and per router.
>>
>> I accept mails for a lot of domains and for some of those
>> domains I'd
>> like to
>> have a bigger message_size_limit than for the rest.
>
> Since you're talking about message acceptance, you're wanting
> to deal with the main config option message_size_limit.
>
>
>> I am not sure at which point the message_size_limit
>> comes into play.
>
> The data has only arrived at the point the data acl (or one
> of the data-like acls) is run.
>
>> In acl_check_rcpt I have several rules regarding those domains.
>> Can I do
>> in one of
>
> No, but you don't need to.
>
>
>> or is acl_check_rcpt too late in the configuration for the
>> message_size_limit-check?
>
> Actually it's too early. But no matter; the option is
> documented
> as being expanded, meaning that at the time of application
> (after data has arrived, so that the amount of data can be
> counted)
> it can depend on other factors.


meh…

> For your purposes, a definition something like
>
>  message_size_limit = ${lookup {$domain} partial-lsearch \
>      {$config_dir/special_domains} {100} {50}}


That does not seem to work. According to the documentation:

$domain: When an address is being directed, routed, or delivered
on its own,
this variable contains the domain. In particular, it is set during
user
filtering, but not during system filtering, since a message may
have many
recipients and the system filter is called just once.

Therefore I guess that $domain is empty when the
message_size_limit is checked.

So it seems I have to accept all the big mails and then reject
them during
routing I guess.


Best,

Niels