Re: [vchkpw] Qmail rejection of overquota messages instead of bouncing
[EMAIL PROTECTED] wrote:
Quey wrote:
Rick Romero wrote:
I went looking into this thinking chkuser would be a perfect place
for the basic quota check.
Of course that would be sort of vpopmail specific, but lo and behold,
it's already in there.
'chkuser.c' v.2.0.8
if (vmaildir_readquota(tmp_path.s,format_maildirquota \
(user_passwd-pw_shell)) \
= maxmbxquota_limit) {
retstat =
CHKUSER_ERR_MBXFULL;
}
It's not as encompassing as Tom was envisioning, but it does do what
the parent is looking for..
Rick
I thought this used to work back in the days when we used CDB, but
does it still work today (using SQL at least?)
on my production it still generates a new bounce, as it does on my
test server...
Connected to fox.
Escape character is '^]'.
220 fox ESMTP
mail from: [EMAIL PROTECTED]
250 ok
rcpt to: [EMAIL PROTECTED]
250 ok
data
354 go ahead
blah
..
250 ok 1197328261 qp 12808
and yes david is well over quota :)
Dec 11 09:11:06 fox qmail-send: delivery 65: failure:
user_is_over_quota//
Dec 11 09:11:06 fox qmail-send: status: local 0/200 remote 0/200
Dec 11 09:11:06 fox qmail-send: bounce msg 131246 qp 12818
Chkusr accepts it like any other user found message...
Antonio perhaps I missed a config option to force this? (or has
it been so long since i needed to install it, it never actually did it
and I'm remembering wrong?
no matter, I found what I did wrong, I ommited the variable in tcp.smtp
file :)
it now works as stated.
But I agree it would be nice to do by default without adding into that
file if it is defined.
Hi!
well my current solution is to check all mailboxes with a perl script and
add those email addresses to be removed from validrcptto.txt file... then
rebuild validrcptto.cdb... and mail won't be accepted for them... but this
is a permanent failure error.. should be better to be specified a 450 at
smtp time for example as error code...
have a nice day!
Antonio's Chkusr works perfect maybe you could look at implementing it :)
will save a lot of hassle
!DSPAM:475e816632001610717592!
Re: [vchkpw] Qmail rejection of overquota messages instead of bouncing
Rick Romero wrote:
[EMAIL PROTECTED] wrote:
Quey wrote:
Rick Romero wrote:
I went looking into this thinking chkuser would be a perfect place
for the basic quota check.
Of course that would be sort of vpopmail specific, but lo and behold,
it's already in there.
'chkuser.c' v.2.0.8
if (vmaildir_readquota(tmp_path.s,format_maildirquota \
(user_passwd-pw_shell)) \
= maxmbxquota_limit) {
retstat =
CHKUSER_ERR_MBXFULL;
}
It's not as encompassing as Tom was envisioning, but it does do what
the parent is looking for..
Rick
I thought this used to work back in the days when we used CDB, but
does it still work today (using SQL at least?)
on my production it still generates a new bounce, as it does on my
test server...
Connected to fox.
Escape character is '^]'.
220 fox ESMTP
mail from: [EMAIL PROTECTED]
250 ok
rcpt to: [EMAIL PROTECTED]
250 ok
data
354 go ahead
blah
..
250 ok 1197328261 qp 12808
and yes david is well over quota :)
Dec 11 09:11:06 fox qmail-send: delivery 65: failure:
user_is_over_quota//
Dec 11 09:11:06 fox qmail-send: status: local 0/200 remote 0/200
Dec 11 09:11:06 fox qmail-send: bounce msg 131246 qp 12818
Chkusr accepts it like any other user found message...
Antonio perhaps I missed a config option to force this? (or has
it been so long since i needed to install it, it never actually did it
and I'm remembering wrong?
no matter, I found what I did wrong, I ommited the variable in tcp.smtp
file :)
it now works as stated.
But I agree it would be nice to do by default without adding into that
file if it is defined.
Actually, as I was falling asleep last night (isn't that always the
case), I wondered why chkuser.c sets maxmbxquota_limit = 0 and not 100
by default. It would seem to me if you're enabling the define, you
would already expect that function to just work, not go to another place
and enable something else. Having the environment variable is great,
then if you want to alter the default, you can set it there...
Just my .02.
Rick
Rick
I believe that Tonino has set this for the tcp.smtp otherwise you need
to recompile qmail everytime you need to change the setting for the quota.
Just my 2 cents.
Remo
!DSPAM:475eb32932001630015932!
Re: [vchkpw] Qmail rejection of overquota messages instead of bouncing
Rick Romero ha scritto: Actually, as I was falling asleep last night (isn't that always the case), I wondered why chkuser.c sets maxmbxquota_limit = 0 and not 100 by default. It would seem to me if you're enabling the define, you would already expect that function to just work, not go to another place and enable something else. Having the environment variable is great, then if you want to alter the default, you can set it there... Just my .02. Rick Rick I believe that Tonino has set this for the tcp.smtp otherwise you need to recompile qmail everytime you need to change the setting for the quota. Just my 2 cents. Remo Right - that makes sense, but as it is now when it's enabled, it's not REALLY enabled until the environment is set. The environment is required, it's not an option. This is because in the chkuser.c the limit is set to 0, which disables the check. If, by default, the limit was set to 100, then it would be enabled by the define AND you can change the limit in environment or disable it by setting the environment to 0. To me the environment variables should override the 'standard' - and if you've enabled 'smtp bouncing', you shouldn't have to add the environment as well (imho, enabling it twice). Rick, the standard I'm following in chkuser, whenever possible, is the following: each time a variable is needed/used, it must be defined, otherwise the feature is disabled. You see this for each variable you can use: enabling variable, bad rcpt limit variable, quota variable, etc. This is a double security against unwanted features, very useful for new features within new releases. Tonino Rick -- [EMAIL PROTECTED]Interazioni di Antonio Nati http://www.interazioni.it [EMAIL PROTECTED] !DSPAM:475ec7ba32001560123944!
