[milters] Archive

Lists Index Date Thread Search

Article: 986
From: Grant Taylor
Date: 2006-06-28 15:46:20 -0400
Subject: Re: Looking ahead for "over quota" mailboxes

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

Quentin Campbell wrote:
> 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.

Hum, I believe I have asked similar questions in the past and gotten responses, though I
can not cite them at the moment.  Suffice it to say that rejecting email during the SMTP
transaction is not an easy process.  Basically the problem comes down to the fact that
Sendmail will accept the message in to it's queue system and then attempt to deliver the
message locally afterwards.  Seeing as how Sendmail has accepted the message it is too
late to cause a DSN which will cause the sending server to handle the return of the error
message.

> 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"
failure
> 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.

I do believe that you are underestimating the difficulties involved.  Now it sounds like
you are wanting a relay server to be able to find out if a mail box on a destination
server is over quota.  To start with the destination server would have to be able to tell
if a mail box is over quota or not, which by default Sendmail can not.  Then you are
wanting that destination server to report to the relay server such condition.  Keeping the
fact that Sendmail will accept messages in to queue and then try to deliver there would be
little gain in having your relay find out that the mail box on the destination server is
over quota.  When the relay server has found out that the mail box is over quota it will
have to bounce the message back to the sender, so you are back to where you started.  In
order for the relay server to be able to reject the inbound message stating that the
recipient mail box is over quota you would have to put the inbound SMTP transaction on
hold and initiate an
 outbound SMTP transaction to the destination server to get the answer before you could
pass it back to the inbound server.

> 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.      

It sounds like you are trying to help prevent back scatter.  A noble cause for sure, but a
difficult one.  I would be more inclined to try to set something up to make sure that
messages that are originally coming in are indeed from who they say they are from, i.e.
SPF filtering.  Even SPF filtering will not solve all your problems, and in fact it will
make a few others.  True that if everyone set up SPF DNS records and ran SPF filters on
their mail server a LOT of crap would be cut out, especially spoofed crap.

> Any comments on these issues would be welcome.

There are some obscure things that you might be able to try.  For instance set up
milter-cli on the relay to (somehow) communicate with the destination server and ask it if
a mail box is over quota or not and accept or reject messages based on that.  You may also
be able to get your relay to act more like a destination mail server that shares a file
system with the real destination server so it can detect if the destination mail box is
over quota or not its self.  Depending on how often your mail boxes go over quot and then
back under quota you may be able to set up some sort of a map that your relay(s) could
query to find out if the mail box is over quota or not.  Namely, set up a virtusertable as
an LDAP map where you change the mail box to be "error:550:5.??? Mail box is over
quota" to cause the relay to reject the message.



Grant. . . .

Lists Index Date Thread Search