Re: [exim] message_size_limit extension for two users

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] message_size_limit extension for two users
Stanczak Slawomir wrote:
> I have 1000 accounts on my mail server. I set limit 50MB for all:
>
> message_size_limit = 50M
> return_size_limit = 500K
>
> How can I set biger limit (200MB) for two users? Can you help me?
>
> Regards
>
> S.S.
>


Your 200MB should be OK - but I'd test that to insure you can DO it reliably
before even worrying about permitting it.

A few questions, and some background in that regard;

- Do you also use storage quotas, and if so, with what limits?

- You mention two users (of yours). Can your logs (or the users) tell how many
correspondents WITH those users are involved? E.G. - the same few, or
potentially anyone?

- WHEN those two users get large files sent to them, are they also the only
recipient asked for in that session? My bet is that they are, which - if so -
makes life easier when granting the overize.

- What is your setting for smtp_receive_timeout?

- Have you ever logged multiple back-to-back incomplete delivery attempts
on relatively large message sizes - even those below the present limits?

- can you run multiple 200MB tests between the 'typical' end-points involved and
see if *those* require multiple attempts?



Background:

We've run a server (with *very few users*) for many years with no fs quotas and
an 800MB message limit - four times what you seek to allow. We;'ve tested to far
higher limits - 2, 4, 8, 10, 15, and even 20GB.

The practical limit, however, is not determined by just OUR server settings. It
is also impacted by link characteristics and far-end submitter time-out settings
in both MUA and MTA.

If the transfer takes a really long time, their MTA may fail to see our '250
OK', thinks they've failed, sends the submitter a not-final DSN, tries again ...
and we have seen as many as 15 actually successful attempts impact the resources
before they were aware that they had (finally) suceeded.

Obviously, those 14 extra copies are a PITA - *especially* when an end-user's
MUA gets hung on each in turn as it tries downloading them to his desk. If they
have POP, not IMAP, and default to downloading all, not just headers-first, it
can be tough with even the one copy.

So - as has been said - smtp is not a good way to move large files...

HTH,

Bill