Re: combining ldap and smtp-lookahead for recipient validation
Thank you!
The only thing that's a little odd is that the embedded-space construct:
static:{reject 5.1.1 user unknown} doesn't seem to work in this context. I
get:
... postfix/smtpd[31453]: generic_checks: name={reject
... postfix/smtpd[31453]: warning: unknown smtpd restriction: "{reject"
Changing this to static:reject works well enough for my purposes here, so
that's excellent. Thanks again.
On Thu, 4 Jun 2020 at 14:36, Wietse Venema wrote:
> Jonathan Engbrecht:
> > I route mail for a number of relay_domains - recipient addresses are
> > validated using verify via address_verify_transport
> >
> > For *one* of these domains, I'd like to validate addresses using an ldap
> > map configured with relay_recipient_maps rather than smtp lookahead.
> >
> > I have the ldap connection working based on postmap -q ..., but I'm not
> > sure how to configure to make some domains work using the lookahead, and
> > one to work using relay_recipient_maps.
>
> This should be easier, but 1) relay_recipient_maps is global, so you
> have to leave that 'empty' and use check_recipient_access instead
> (*); and 2) restriction_classes is needed for a nested table lookup.
>
> Untested example!
>
> restriction_classes = verify_with_lookup
> verify_with_lookup =
> check_recipient_access ldap:/some/file static:{reject 5.1.1 user
> unknown}
> # Where the LDAP returns 'permit' or 'ok' for a user that exists.
>
> smtpd_recipient_restrictions =
> ...
> reject_unauth_destination
> ...
> # Needs to go last, because verify_with_lookup returns permit or
> reject.
> check_recipient_access pcre:/etc/postfix/rcpt_access
>
> /etc/postfix/rcpt_access:
>/@example\.com$/ verify_with_lookup
>/./ reject_unverified_recipient
>
> More at http://www.postfix.org/RESTRICTION_CLASS_README.html
>
> (*) relay_recipient_maps can be changed to be not global,
> but doing that would complicate other things.
>
> Wietse
>
combining ldap and smtp-lookahead for recipient validation
I route mail for a number of relay_domains - recipient addresses are validated using verify via address_verify_transport For *one* of these domains, I'd like to validate addresses using an ldap map configured with relay_recipient_maps rather than smtp lookahead. I have the ldap connection working based on postmap -q ..., but I'm not sure how to configure to make some domains work using the lookahead, and one to work using relay_recipient_maps. help?/thanks Jonathan
Re: silent drop from sender *unless* to...
static:discard is exactly what I needed. Thanks. This isn't a production system and we're just using this for testing a new application where we don't want users that aren't part of the test receiving email until we're ready to go live. On Wed, 4 Dec 2019 at 15:29, Noel Jones wrote: > On 12/4/2019 1:55 PM, Jonathan Engbrecht wrote: > > thanks all. Looks like I can mostly do this with restriction > > classes, though the drop ends up being a 5xx reject rather than a > > silent drop, which is a bit too bad. > > > > tester = check_recipient_access > > hash:/etc/postfix/maps/privileged_recipients, *reject* > > * > > * > > being able to use "discard" here would be great, but doesn't appear > > to be possible > > You can use static:discard there. > > Caution: discard is a permanent action that loses data; use > sparingly. Reject is almost always more appropriate. > > > >-- Noel Jones >
Re: silent drop from sender *unless* to...
thanks all. Looks like I can mostly do this with restriction classes, though the drop ends up being a 5xx reject rather than a silent drop, which is a bit too bad. tester = check_recipient_access hash:/etc/postfix/maps/privileged_recipients, *reject* being able to use "discard" here would be great, but doesn't appear to be possible On Tue, 3 Dec 2019 at 17:38, Ralph Seichter wrote: > * Jonathan Engbrecht: > > > If From: f...@example.com > > AND NOT To: (bar|baz|quux)@mydomain.com > > DISCARD > > Milter-regex (https://www.benzedrine.ch/milter-regex.html) can do this, > and more. The actual syntax for your example would be something like > this (untested because I am typing from memory): > > discard > header /^From$/ /foo@example\.com/ and not \ > header /^To$/ /(bar|baz|quux)@mydomain\.com/ > > You can also use variables in milter-regex to easily re-use complex > expressions. I can heartily recommend it. > > -Ralph >
silent drop from sender *unless* to...
Can I make a header_check rule (or equivalent) somehow that does the following: If From: f...@example.com AND NOT To: (bar|baz|quux)@mydomain.com DISCARD
Re: rewrite envelope-sender but *not* from address
This seemed initially promising, but one of our primary internal mail systems won't validate the +/=-style address extension, and with the Return-path/envelope-sender encoded as host-tag+user=valid address@valid domain, any bounces just die with recipient unknown. (postfix 2.3.3 is unfortunately the most recent version provided in Red Hat's enterprise repository. I could update it, of course, but we try to stick with core packages where possible). On Fri, May 2, 2014 at 11:30 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Fri, May 02, 2014 at 10:15:45PM -0500, /dev/rob0 wrote: On Fri, May 02, 2014 at 05:26:02PM -0400, Jonathan Engbrecht wrote: postfix 2.3.3 Note that Viktor's suggestion of multiple instances assumes a slightly less ancient Postfix version; postmulti(1) began with Postfix 2.6. Time to upgrade? I was not suggesting multiple instances, merely the rewriting methodology of the nullclient configuration described in the document. This said Postfix 2.3 is rather old, and if the OP gets a chance, running something more recent (2.9 or later) is not a bad idea. -- Viktor.
rewrite envelope-sender but *not* from address
I'm working on a generic postfix configuration for servers. I want messages to have a From: address of user@server fqdn, but an envelope-sender/bounce address that's different. in main.cf: canonical_maps=hash:/etc/postfix/canonical canonical_classes = envelope_sender in canonical: @server fqdn some other address Messages sent from this server have the right envelope-sender (rewritten), but the header From: is also rewritten (as if canonical_classes is being ignored). What am I missing? Is there a different way I should be doing this?
Re: ldap-attribute-based routing question
Yes, I have the ability to make the required changes to our ldap. I was mostly curious if it was possible to set up a mapping in a non-hackish manner that didn't necessitate directory changes. Thanks all for the responses. On Thu, Aug 15, 2013 at 9:18 AM, jeffrey j donovan dono...@beth.k12.pa.uswrote: On Aug 14, 2013, at 1:37 PM, Jonathan Engbrecht jengb...@ryerson.ca wrote: there is no mailHost attribute in ldap (or *any* attribute that is the next hop dns name). I need to map an attribute in ldap to something that *isn't* in ldap. (yes, this could be done with ldap modifications (and probably will have to be). I'd just like to confirm that I can't do it without Im going to assume to have access to the ldap directory. You can use any open attribute. it doesn't have to be mailHost. I use mailHost because it was already defined in my schema. You could use any attribute , just fill in the desired result. -j
ldap-attribute-based routing question
We have an attribute in our ldap that I'd like to use to determine the next hop for mail transport. The attribute is not itself the name of the next transport. Is there a way to set up a mapping for this? ie: dn: xxx... routingattribute: foo route messages with this attribute to smtp:bar.com:25 dn: yyy... routingattribute: baz route messages with this attribute to smtp:qux.com:25
Re: ldap-attribute-based routing question
there is no mailHost attribute in ldap (or *any* attribute that is the next hop dns name). I need to map an attribute in ldap to something that *isn't* in ldap. (yes, this could be done with ldap modifications (and probably will have to be). I'd just like to confirm that I can't do it without). On Wed, Aug 14, 2013 at 12:34 PM, jeffrey j donovan dono...@beth.k12.pa.uswrote: On Aug 14, 2013, at 11:29 AM, Jonathan Engbrecht jengb...@ryerson.ca wrote: We have an attribute in our ldap that I'd like to use to determine the next hop for mail transport. The attribute is not itself the name of the next transport. Is there a way to set up a mapping for this? ie: dn: xxx... routingattribute: foo route messages with this attribute to smtp:bar.com:25 dn: yyy... routingattribute: baz route messages with this attribute to smtp:qux.com:25 greetings first make sure postfix is built with ldap support. postconf -m create a ldap_transport map looks something like this: /etc/postfix/ldap_transport server_host = 10.1.1.1 search_base = dc=ldap,dc=server,dc=dot,dc=com query_filter = (mail=%s) result_attribute = mailHost result_filter = smtp:[%s] bind = no postmap /etc/postfix/ldap_transport edit your main.cf transport_maps = ldap:/etc/postfix/ldap_transport postfix reload hope this helps. -j
