[milters] Archive

Lists Index Date Thread Search

Article: 998
From: Barry Quiel
Date: 2006-07-07 20:45:48 -0400
Subject: Re: Looking ahead for "over quota" mailboxes

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

The problem I had with over quota users is that procmail handles my 
local delivery from sendmail.  Its not until the message gets handed off 
to procmail that quotas are checked.

So what I did was write a small script that runs a quota check and adds 
those names to the access.db for rejection.  I run this every few hours 
as a cron job so that if a user does clean out their inbox it will get 
updated in a timely fashion.

Quentin Campbell wrote:
> Removal...........: milters-request@milter.info?subject=remove
> More information..: http://www.milter.info/#Support
> --------------------------------------------------------
> I note that there have been enquiries before to the list for a milter
> that could reject delivery to an over quota mailbox. However I can find
> no response to those enquiries.
> We have found 'milter-ahead' a great help in reducing this site's
> exposure to the consequences of collateral spam generated from failed
> deliveries to an "Unknown user". However "delivery timeout"
> messages caused by non-delivery due to "over quota" mailboxes still put
> us in jeopardy of blacklisting by SpamCop and others.
> It would be nice if milter-ahead could be configured to check for other
> events that would prevent delivery to a mailbox. I may be
> underestimating the technical difficulties in being able to check,
> before actual delivery, for things that could prevent delivery. If so, a
> brief explanation as to what these difficulties are would be useful.
> As an alternative to looking ahead for over quota situations I am
> considering deploying milter-cli to reject a message from an internal
> host that was generated because of a delivery timeout failure due to the
> mailbox being "over quota". However this measure merely prevents these
> failure messages being forwarded to spam traps. It does nothing to help
> warn the sender of the original message that her delivery was ultimately
> failed because the recipient mailbox was full.      
> Any comments on these issues would be welcome.
> Thanks
> Quentin
> ---
> PHONE: +44 191 222 8209    Information Systems and Services (ISS),
>                            University of Newcastle,
>                            Newcastle upon Tyne,
> FAX:   +44 191 222 8765    United Kingdom, NE1 7RU.
> ------------------------------------------------------------------
> Opinions expressed above are mine. 

Lists Index Date Thread Search