--- In post...@yahoogroups.com, mouss <mo...@...> wrote: > > jeff_homeip a écrit : > > --- In postfix-us...@yahoogroups.com, Sahil Tandon <sahil@> wrote: > >> jweinbergerhj wrote: > >> > >>> I know it's a simple question...but doea any know if this: > >>> > >>> content_filter=hash:/path/to/table (or mysql:/path/to/filters.cf) > >>> > >>> will work? > >> No. From postconf(5): > >> > >> content_filter (default: empty) > >> > >> The name of a mail delivery transport that filters mail after it is > >> queued. > >> > >> This parameter uses the same syntax as the right-hand side of a > >> Postfix transport(5) table. This setting has a lower precedence > >> than a content filter that is specified with an access(5) table or > >> in a header_checks(5) or body_checks(5) table. > >> > >>> I'm trying to test some new content filters and want to be able to > > apply them per > >>> domain or per address (recipient) for my test and personal domains > > before I make them > >>> standard. > >> You could use check_recipient_access; example: > >> > >> /etc/postfix/main.cf: > >> smtpd_recipient_restrictions = > >> .. > >> check_recipient_access hash:/etc/postfix/filters > >> .. > >> > >> /etc/postfix/filters > >> recipient@ FILTER foo:bar > >> > >> There are some caveats and limitations; for more information see: > >> http://www.postfix.org/access.5.html > >> http://www.postfix.org/FILTER_README.html > >> > >> -- > >> Sahil Tandon <sahil@> > >> > > Sahil > > > > Thanks!! > > > > I read "This parameter uses the same syntax as the right-hand side of > > a Postfix transport(5) table" as meaning it can take the same syntax > > as transport_maps, i.e. a table. Maybe not. > > no. the syntax is that of the RIGHT-HAND SIDE of transport_maps. > content_filter isn't a map.
thank you! > > > > > check_recipient_access works fine, > > > I hope you are aware that per-recipient FILTER is "fragile": if the > message is sent to multiple recipients, the last FILTER is used (a > message is passed to a single filter. it is not split). > > > but it is problematic for me, as > > the messages get passed to the content filter before alias > > translation, which causes problems with aliases that map to virtual > > mailboxes. > > > > you can expand aliases before or after the filter. it's your choice. but > make sure to only enable rewrite once in a mail path (otherwise, you may > get duplicates if a virtual alias is expanded twice) When I used the check_recipient_access it passed the message to the content filter before alias expansion, and when I used the content_filter it passed it after. Can you tell me (or point me to resources) that show me how to control this? it might help me achieve my goal...thanks. > > > Also I would need check_recipient_access to be a mysql: table (which > > it can be), but I don't know how to control the matching order in a > > mysql table lookup - any ideas? > > > > postfix lookup order is independent of the map type. OK, got that. But the question isn't whether it's different for mysql maps, but how I can make sure that when addr...@domain.tld is matched it matches "addr...@domain.tld" before it matches "domain.tld" and that before it matches "/./" (all). This way I can specify per user, per domain and have a catch-all (default) It did not work this way with transport_maps, but that might be because I specified two different maps (transport_maps=mysql:/path/to/one.cf, mysql:/path/to/two.cf). In that case if something matched in one.cf, then it never checked two.cf. > > > Do you (or anyone) have any ideas on how to overcome this? > > > > I also came up with another way to do this...does anyone have any > > thoughts on how this will work? > > > > Make the content filter into the transport using transport_maps. Then > > when the content filter injects the messages back into postfix, use > > master.cf -o transport_maps to override and make the actual transport > > maps effective. > > > > Will that work? > > > > not with a single instance. transport_maps are global in an instance. so > you would create a loop. > > but if you want per recipient filtering, then your best choice is to use > different postfix instances (run postfix twice. not add smtpd listeners > to a single master.cf). then you don't need content_filter at all. you > can use transport_maps instead. the advantage is that this works "as > intended" in the case of multiple recipients. Multiple postfix instances on one machine might be the best answer to this. Can you point me to something on how to do this? I'm not at all familiar with how this might work and be sure they don't interfere with one another. Thank you so much for your help! > > > Thanks for your help! > > > > --Jeff > > >
