Re: [exim] Rejecting over quota at RCPT time - revisited

On Wed, Nov 28, 2012 at 3:29 PM, Robert Blayzor <rblayzor.bulk@???> wrote:

> Ultimately it would be nice to somehow deny/defer at RCPT time.

The single biggest problem is that you don't actually know how big the
email is at RCPT time. You *MAY* have received a SIZE=nnnnnn
parameter in the MAIL FROM, but you don't know if they're being
honest. And if there wasn't a SIZE=nnnnn parameter, you can't really
make an informed decision, only a "policy" decision (similar to
delivering an email that puts it over quota, versus queuing the
message if it would put it over quota).

You do not however, have this issue after the data phase (before the
router/transport) in the DATA ACL. You know exactly how big it is
(aside from the likely negligible size of any added/deleted headers).
So if you're aiming to do something like this, it should be targeted
for the DATA ACL, in my not so humble opinion.

> The logic is obviously in Exim somewhere to check a users quota, but it seems to only exist in the transport level. There are two possible solutions, but how?

It only exists in the transport level because that's the only part
that actually is coded to access the mailstore. There would have to
be a blurring of some lines if you make a router do functions which
were normally only available to a transport.

> 1) Have a function in Exim which can be passed a homedir/maildir and quota to check. (Maildir++ for example). This could then be used in a router condition to fail the recipient verification. (possibly an expensive operation)

This doesn't sound unreasonable.

> 2) Have a way to trap the over quota in the transport level. This could then be used to possibly call something to signal routers in future SMTP transactions that this mailbox is currently full and to back off attempting mail delivery. ie: first message comes in, hits the transport, the mailbox is over quota, the trigger could run an external command, use readsocket to something like memcached to mark the mailbox as "currently over quota". Subsequent new emails coming in for X minutes will be denied in a router.

I would think that is possible now. Have to think about it.

> We have several Exim servers behind a load balancer and use memcached to share data between the servers for things like excessive authentication attempts, limiting the # of messages authenticated users can send in a 24 hour period, etc.. all works via well in a multi server environment.

You've basically described our system.

> Our last sticking point is dealing with over quota NDR's... Option #2 above would be possible if we could somehow trap the over quota condition in the transport.

It does seem like it should be possible. The verify_only flag
configures a router to be used only during address verification and
skipped during message delivery. It seems like you should be able to
a create a router that's used solely for testing maildir size. I
haven't tried this, but it seems doable. Some code would need to be
added to the router to access the transport code which checks quota.
I don't know how complex that would be, and sitting in a McDonald's is
not the place for me to make that guess :-)

The ultimate question here though is what do you do if one person out
of 10 envelope recipients is over quota. Do you reject all? This is
the problem with doing it at the DATA phase. :-/

Dammit I still want to get PRDR working. Would solve it perfectly.
No time, no time...

...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine