On 7.8.2013, at 9.29, Ulrich Zehl wrote:
> On Tue, Aug 06, 2013 at 09:20:13PM +0200, Thomas Leuxner wrote:
>> Now everything in between seems to create SMTPD rejections in some cases
>> _or_ queue the mail and let it hit the quota in other cases. That's my
>> whole point...
>
> I'm sorry, I don'
* Ulrich Zehl 2013.08.07 08:29:
> Are you saying that rejects depend on SIZE= being sent during the RCPT TO
> stage (i.e., messages that announce their size correctly are rejected
> during the SMTP transaction, while those without size inidcation are
> passed)?
Yes.
signature.asc
Description:
On Tue, Aug 06, 2013 at 09:20:13PM +0200, Thomas Leuxner wrote:
> Now everything in between seems to create SMTPD rejections in some cases
> _or_ queue the mail and let it hit the quota in other cases. That's my
> whole point...
I'm sorry, I don't get your point.
Are you saying that quota-status
Thomas Leuxner skrev den 2013-08-06 18:25:
* Timo Sirainen 2013.08.06 18:15:
Now the real problem along the road is the submitting server. If
that server does not
indicate the message size during handshake the pre-queue rejection
simply can not work.
quota_grace was meant to solve that. You
* /dev/rob0 2013.08.06 20:49:
> Personally, I'd much rather allow the last overquota mail, even in
> cases where the user goes far over the quota. Apparently Thomas
> intends to have a solid, inflexible quota.
The point I'm trying to make is mail being queued by Postfix because it has no
mean
On 2013-08-06 2:49 PM, /dev/rob0 wrote:
Another way, in Postfix, is to wait for end-of-DATA. Regardless of
SIZE being given, at that point, the actual size is known.
Of course as Thomas would probably point out, such a rejection is
unsafe, because ANY overquota recipient would cause rejection f
Am 06.08.2013 20:27, schrieb Timo Sirainen:
> On 6.8.2013, at 20.57, Thomas Leuxner wrote:
>
>> * Timo Sirainen 2013.08.06 19:42:
>>
>>> The idea behind quota_grace is that the last mail would be allowed to take
>>> the user somewhat over quota (e.g. up to 109% quota usage). On the next
>>> ma
On Tue, Aug 06, 2013 at 09:27:20PM +0300, Timo Sirainen wrote:
> On 6.8.2013, at 20.57, Thomas Leuxner wrote:
> > * Timo Sirainen 2013.08.06 19:42:
> >
> >> The idea behind quota_grace is that the last mail would be
> >> allowed to take the user somewhat over quota (e.g. up to 109%
> >> quota
On 6.8.2013, at 20.57, Thomas Leuxner wrote:
> * Timo Sirainen 2013.08.06 19:42:
>
>> The idea behind quota_grace is that the last mail would be allowed to take
>> the user somewhat over quota (e.g. up to 109% quota usage). On the next mail
>> delivery user is already over quota, so the size
* Timo Sirainen 2013.08.06 19:42:
> The idea behind quota_grace is that the last mail would be allowed to take
> the user somewhat over quota (e.g. up to 109% quota usage). On the next mail
> delivery user is already over quota, so the size of the mail is irrelevant
> because a mail of any siz
On 6.8.2013, at 19.25, Thomas Leuxner wrote:
> * Timo Sirainen 2013.08.06 18:15:
>
>>> Now the real problem along the road is the submitting server. If that
>>> server does not indicate the message size during handshake the pre-queue
>>> rejection simply can not work.
>>
>> quota_grace was
* Timo Sirainen 2013.08.06 18:15:
> > Now the real problem along the road is the submitting server. If that
> > server does not indicate the message size during handshake the pre-queue
> > rejection simply can not work.
>
> quota_grace was meant to solve that. You'll allow the user to become
On 6.8.2013, at 18.49, Thomas Leuxner wrote:
> Now the real problem along the road is the submitting server. If that server
> does not indicate the message size during handshake the pre-queue rejection
> simply can not work.
quota_grace was meant to solve that. You'll allow the user to become
* Ulrich Zehl 2013.08.01 16:39:
> If you store your mailbox and alias information in the same data source
> (LDAP, SQL, ...), you should be able to do the same.
Thanks. I did address this using a restriction class which works fine for my
scenario and allows selective quota checking.
/etc/postf
On Tue, Jul 30, 2013 at 03:20:47PM +0200, Thomas Leuxner wrote:
> This is probably intended behaviour, just want to make sure that I'm not
> missing a point here. For now the only fix that comes to my mind to create
> "quota aware" aliases - is creating 'dummy' users in Dovecot which point to
> the
The latest HG commits seem to have fixed some underlying problems with the
'quota-status' service. Now doing some quick tests I wonder if this can be used
with aliases on the Postfix side. Appears the 'check_policy_service' used in
the example below will query existing users via Dovecot's Auth B
16 matches
Mail list logo
