On Nov 28, 2012, at 7:40 PM, Todd Lyons <tlyons@???> wrote:
> 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).
True, but you know when they are hard over quota and to absolutely drop accepting any new mail. Regardless if the message is 1 byte in size. No more, means no more. At this point, its safe to say reject ALL new mail. (5xx error at RCPT time)
> 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.
In my thinking you can't do this at DATA time because you can have several recipients for the same DATA message. So if you have 20 recipients, and only one of them is over quota, if you reject the message there, it will reject it for all.
> 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.
This is perfectly fine. I'm just looking for a way to trap the condition at the transport, ie: just expand a string so I can do a run or readsocket to something. If I can trap the over quota at the transport level somehow, that would work.
>> 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.
Just need a way to call a string expansion if an over quota condition is triggered. I could then use something like readsocket/run/sql call, etc. We currently use readsocket to get/set values in memcached so it can easily be shared with other Exim servers.
> 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. :-/
Right, but you can 4xx the recipient in RCPT to phase, kind of like the way Exim handles excessive recipients per messages now. (setting)
> Dammit I still want to get PRDR working. Would solve it perfectly.
> No time, no time...
Yes, something like that would work but you would still need to be able to check the quota at after the DATA and before the transport.
--
Robert Blayzor
INOC, LLC
rblayzor@???
http://www.inoc.net/~rblayzor/
