Todd Lyons wrote: > On Fri, Nov 27, 2009 at 4:11 PM, Phil Pennock <[email protected]> wrote: >>> Are there any other ways of doing this? If there are, nothing has >>> come to mind and I welcome suggestions.
*snip* (how-to w/r maildrop and/or routers) > positive experiences with maildrop. I did not realize that I could > use exim to enforce quota (in a router, so I think that will allow me > to defer/reject at SMTP time, which is my ultimate goal). I thought I > had to hand it off to something else in order to get quota > enforcement. Verification-walks aside, (which you can use, per the redacted coverage) .. router/transports are not otherwise really 'at smpt time'. The 'session 'ends as you leave the DATA phase. But you *can* know the actual size while still in acl_smtp_data and *can* use that information to insure that your defer/deny is communicated directly to, and ONLY to, the still-connected entity, thereby eliminating risk that an NDR is abused for any form of backscatter spamming. ISTR there are examples of useful acl snippets in the list archives ... all part of why Exim & its acl's are so effective vs MTA+[milters]+[maildrop|procmail| friends] CAVEATS: - I don't (need to) use quotas, as a message-size limit, large RAID1, and finite b/w on the front-end give me days if not weeks to react to consumption of space with my particular user community. YMOV - BUT... a setup where you publish quota 'n' but actually provide for space for quota 'n+20%' and trigger at quota [n+10%] before defer|deny might reduce your admin load costs more than the extra HDD space costs. A fair bit of slack also reduces the risk of one child-process clearing the session and THEN hitting a router or fs blockage because one or more OTHER children were already using-up the last of the headspace, or conversely, rejecting if the POP/IMAP daemon was clearing more space in the meantime. - Be aware also that there exist sending 'entities' that do not hang-around for 'proper' completion of DATA handshakes. All the more reason, IMNSHO, to NOT generate out-of-session NDR's to such critters, as they are more likely to be maliciously-coded rather than just-plain broken. - Note necessarily a recommended practice, but I also disallow pipelining so as to insure nothing comes onto the box before it has passed all tests prior to acl_smtp_data. Up to that point, there has been nothing exchanged but ephemeral handshakes, no HDD space required for those at all. Do your own due diligence on that issue, as one size does not fit all. Finally - if you are running a hot and heavy MTA, it helps to NOT use the default /var mount-point for mailstore (or even, necessarily for spool). If ~/var ever overflows, the system logger (among other needful things) is stumped, which is not good. As Exim can easily be pointed to use of a bespoke mount (separate hardware RAID recommended) for mailstore and optionally spool, that makes migration, upgrades, or failure recovery a bit cleaner, and helps insure that you can at least ssh into a box that has not dropped into single-user mode due to an 'unable to write..' panic. HTH, Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
