Quoth S White on Sun, Apr 30, 2000:
> This problem becomes compounded when the departmental server
> (MS Exchange in one particular problem case) either crashes or is taken
> down.
Duh. Typical.
> What I need is a way to tell our relay that it has differing mail sizes
> that it will accept based on the eventual destination of the message,
> rejecting messages that exceed the size limits set.
I can not think of any way to reject messages based on size at
SMTP time. So if different departmental mailservers accept
messages of different maximum sizes, but the maximum of all of
them is, say, ten megs, you can limit the message size to ten
megs, but I don't think you can do anything more specific than
that. One problem being that messages can be addressed for
several recipients from several different departments.
> Logically, the best
> place to do this would be in a router definition but I haven't been able
> to find how.
Routers are for outgoing messages. So yes, you can reject
messages based on size either in routers or in system filter.
> Setting up a seperate transport definition for a particular
> router associated with a department and setting the size limit there
> appears to be possible *but* is that size setting checked when a message
> is received or only when delivery is attempted by exim?
When delivery attempted. Before delivery actually attempted, to
be exact. After the routing is done, but before the actual
delivery.
You can set up, say, five different transports for five different
sizes. But it's not scalable. The problem is that the transport
option message_size_limit doesn't get expanded -- it would be
much easier if it were. No luck for us today.
> Any ideas on how I might get this to work would be appreciated.
You can set up a database for looking up maximum allowed message
size by hostname of departmental mailservers, such as:
devel.company.dom: 10000000
phb.company.dom: 5000000
bean-counters.company.dom: 2000000
Now, I'm not sure how you handle mail on your server, and whether
you have any local domains in there. If you handle mail to
departments as remote, you can define your domainlist router to
reroute big mail to the local addresses, as below (I assume that
you have mapping of usernames to departments):
department_domainlist:
driver = domainlist
transport = remote_smtp
domains = *.company.dom
local_parts = dbm;/var/exim/user2dep
route_list = "*.company.dom \
\"{$if >{$message_size}{$lookup{$local_part_data}dbm{/var/exim/depmaxsize}\
{$value}\
{999999999999}}\
{@}\
{$local_part_data}}\"\
bydns_a"
self = local
Ahem. I'm acting like myself again. This means:
Suppose that dbm file user2dep maps users to departments with
entries like this:
cheefbc: bean-counters.company.dom
bigboss: phb.company.dom
Suppose that depmaxsize is the mapping of departments to max
message sizes as described above.
For domains *.company.com, for local parts in user2dep, route
list is:
Look up local_part_data (the data from user2dep, i.e.,
the department) in depmaxsize (i.e., get the max message
size for the department the user is in). If found,
return the size, otherwise return big big number.
If message size is bigger than the number, return
localhost. "self = local" makes the address local then.
Otherwise, return local_part_data (i.e., the department).
Then, make the first director a smartuser director, such as:
too_big:
driver = smartuser
domains = *.company.dom
local_parts = dbm;/var/exim/user2dep
new_address = :fail: Message size exceeded.
Now, if the message got to the directors (i.e., is treated like a
local message), it got here from the routers. If there is no
other way that mail for *.company.dom domains can get to the
directors, you can remove the local_parts option.
Good luck, eh?
Vadik.
--
To the systems programmer, users and applications serve only to
provide a test load.
