On Wed, 28 Nov 2012, Todd Lyons wrote:
>
> 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.
>
Good luck with that if there is more than one rcpt, and only one is over
quota ;)
I think you should just accept the message at rcpt_to for any folks still
under quota, and then once they actually go over, block additional mail to
them.
(nice comments followed, but I'm feeling sick today and am headed to bed)
--
--------------------------------------------------------
Dave Lugo dlugo@??? No spam, thanks.
Are you the police? . . . No ma'am, we're sysadmins.
--------------------------------------------------------
