* Noel Jones <njo...@megan.vbhcs.org> [2012-09-10 23:23 -0400]: > On 9/10/2012 9:20 PM, David J. Weller-Fahy wrote: > > 1) Am I correct that blocking recipient addresses which consist of > > an existing user with an extension not defined by that user (in a > > .forward-extension file) is not possible using Postfix using just > > the configuration options available in main.cf? > > A few things I can think of (although neither of them perfect) > > - a regexp or pcre check_recipient_access map that lists valid > extensions and rejects all others. This could be created periodically > by a not-terribly-complex shell/perl/whatever script.
This could work, indeed...
> - a TCP check_recipient_access map that queries some external program
> that verifies the extension. There is sample perl code for the TCP
> part floating around the web, and I don't think {look in the
> recipient's directory for .forward+foo} would be overly complex.
... although I think this option would be the best bet for my use case.
Heck, even a unix socket might work depending on how postfix is running
(chrooted or not), and the daemon required to check user directories for
new forward+foo files wouldn't be complicated. One could even do an
initial scan to build a db of valid extensions, then use logic such as:
- extension exists in db? permit
- doesn't exist in db? check filesystem
- exists in filesystem? permit
- doesn't exist in filesystem? reject
The only real sticky point there would be extension addresses which are
removed... I guess a once per hour/day run would be sufficient to remove
invalid extensions.
Regardless, that path looks fruitful, thanks!
<snip>
> all the above get considerably more complex if the envelope
> recipient is an alias.
Indeed - trying to deal with the vagaries of alias translation/rewriting
would not be my idea of fun. :)
> > 2) Has anyone done something similar to what I want with a
> > milter/plugin which my search-fu and documentation reading has not
> > uncovered?
>
> Not that I am aware of. This generally isn't much of a problem.
> I think the usual action is to accept whatever, then add specific
> unwanted/abused extensions to a blacklist.
Yep, that's been my impression as well. If I do pursue this path and
come up with a solution, I'll put it up here for future reference.
Again, thanks!
--
dave [ please don't CC me ]
pgpNzDG6hy7G2.pgp
Description: PGP signature
