>> At least from Thunderbird, yes. But SIZE=… does not seem to be a
>> mandatory addition to the RCPT-TO line. Perhaps other mail clients do
>> not use SIZE either. Just guessting.
Correct. It's optional and can't be trusted anyway.
> http://www.postfix.org/SMTPD_POLICY_README.html
> The "size" attribute value specifies the message size that the client
> specified in the MAIL FROM command (zero if none was specified). With
> Postfix 2.2 and later, it specifies the actual message size after the
> client sends the END-OF-MESSAGE.
<bad idea>
I misread that and Wietse (Postfix developer) kindly pointed me to the
"after" part. So I found an evil way to make it work:
smtpd_recipient_restrictions = reject_unauth_destination
smtpd_end_of_data_restrictions = \
check_policy_service inet:localhost:12340
The smtpd_end_of_data_restrictions are evaluated after the complete
email was received. Of course this is wasteful because receiving a large
email only to reject it afterwards is not very considerate.
Plus Dovecot complains that the policy service is only supposed to be
used in the RCPT stage. So clearly this is a bad approach.
</bad idea>
In my opinion the quota-status service from Dovecot should be able to
reject any email no matter the size if the user is over quota. But I
can't get that to work. I have set quota_grace to 0. And the user is
using 100% quota. Still…
printf "recipient=t...@bullseye.example.org\nsize=100\n\n" | \
nc localhost 12340
action=DUNNO
printf "recipient=t...@bullseye.workaround.org\nsize=1000\n\n" | \
nc localhost 12340
action=554 5.2.2 Quota exceeded (mailbox for user is full)
Dovecot is still responding with DUNNO. It accepts size=0. It accepts
size=100. Only at a much larger size (1000) it sends a rejection. Why is
that?
In
https://github.com/dovecot/core/blob/master/src/plugins/quota/quota-status.c
there are several e_debug statements. How do I enable that debug logging
for the quota plugin? Maybe that gives an idea.
I really wouldn't want to script my own policy daemon just to avoid
backscatter. :(
Thanks in advance…
…Christoph
