transport map from ldap

classic Classic list List threaded Threaded
13 messages Options
ab
Reply | Threaded
Open this post in threaded view
|

transport map from ldap

ab
Hi All.

I would like the transport_maps to be driven from an ldap lookuop
but i am unsure of the format it should be returning

I have the following config


 and my /etc/postfix/ldap-transport.cf looks like this



This returns the output  when doing a postmap vq

but is that correct for a transport_map




--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Wietse Venema
ab:

> Hi All.
>
> I would like the transport_maps to be driven from an ldap lookuop
> but i am unsure of the format it should be returning
>
> I have the following config
>
>
>  and my /etc/postfix/ldap-transport.cf looks like this
>
> This returns the output  when doing a postmap vq
>
> but is that correct for a transport_map

The transport(5) manpage says:
       When the table is provided via other means such as NIS,  LDAP  or  SQL,
       the same lookups are done as for ordinary indexed files.
That text refers to the "TABLE SEARCH ORDER" section above.

And, it also expects the same result format as described in the
"TABLE FORMAT" section above.

        Wietse
ab
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

ab

Wow lots of my post got cut off, this is what i wrote.

As you can see i am returning [hidden email] relay:[smtp.foo.com]
But the mail log is saying transport map error



Hi All.

I would like the transport_maps to be driven from an ldap lookuop
but i am unsure of the format it should be returning

I have the following config

transport_maps = hash:/etc/postfix/transport
                 ldap:/etc/postfix/ldap-transport
 and my /etc/postfix/ldap-transport.cf looks like this

server_host = ldap://zimbra:389
server_port = 389
search_base =
query_filter =
(&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
result_attribute = mail,zimbraMailAlias
version = 3
result_format=%s relay:[smtp.foo.com]
start_tls = no
timeout = 30

This returns the output  when doing a postmap vq
[hidden email] relay:[smtp.foo.com]
but is that correct for a transport_map



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Wietse Venema
ab:

>
> Wow lots of my post got cut off, this is what i wrote.
>
> As you can see i am returning [hidden email] relay:[smtp.foo.com]
> But the mail log is saying transport map error
>
>
>
> Hi All.
>
> I would like the transport_maps to be driven from an ldap lookuop
> but i am unsure of the format it should be returning
>
> I have the following config
>
> transport_maps = hash:/etc/postfix/transport
>                  ldap:/etc/postfix/ldap-transport
>  and my /etc/postfix/ldap-transport.cf looks like this
>
> server_host = ldap://zimbra:389
> server_port = 389
> search_base =
> query_filter =
> (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
> result_attribute = mail,zimbraMailAlias
> version = 3
> result_format=%s relay:[smtp.foo.com]
> start_tls = no
> timeout = 30
>
> This returns the output  when doing a postmap vq
> [hidden email] relay:[smtp.foo.com]
> but is that correct for a transport_map

The transport(5) manpage says:
RESULT FORMAT
       The  lookup  result  is  of  the form transport:nexthop.  The transport
       field specifies a mail delivery transport such as smtp  or  local.  The
       nexthop field specifies where and how to deliver mail.

"relay:[smtp.foo.com]" is a valid result.

More information in the manpage!

        Wietse
ab
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

ab
um...

I have tried both

[hidden email] relay:[smtp.foo.com]

and

relay:[smtp.foo.com]

as the the output of the ldap lookup and i just get

status=deferred (mail transport unavailable) error

Thanks





--
______________________
Adam Barnett
Systems Engineer
Double Negative
160 Great Portland Street,W1W 5QA
T: 020-7268-5000
[ http://www.dneg.com/ | www.dneg.com ]
______________________

----- Original Message -----
| From: "Wietse Venema" <[hidden email]>
| To: "Postfix users" <[hidden email]>
| Sent: Thursday, 19 September, 2019 14:51:52
| Subject: Re: transport map from ldap

| ab:
|>
|> Wow lots of my post got cut off, this is what i wrote.
|>
|> As you can see i am returning [hidden email] relay:[smtp.foo.com]
|> But the mail log is saying transport map error
|>
|>
|>
|> Hi All.
|>
|> I would like the transport_maps to be driven from an ldap lookuop
|> but i am unsure of the format it should be returning
|>
|> I have the following config
|>
|> transport_maps = hash:/etc/postfix/transport
|>                  ldap:/etc/postfix/ldap-transport
|>  and my /etc/postfix/ldap-transport.cf looks like this
|>
|> server_host = ldap://zimbra:389
|> server_port = 389
|> search_base =
|> query_filter =
|> (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
|> result_attribute = mail,zimbraMailAlias
|> version = 3
|> result_format=%s relay:[smtp.foo.com]
|> start_tls = no
|> timeout = 30
|>
|> This returns the output  when doing a postmap vq
|> [hidden email] relay:[smtp.foo.com]
|> but is that correct for a transport_map
|
| The transport(5) manpage says:
| RESULT FORMAT
|       The  lookup  result  is  of  the form transport:nexthop.  The transport
|       field specifies a mail delivery transport such as smtp  or  local.  The
|       nexthop field specifies where and how to deliver mail.
|
| "relay:[smtp.foo.com]" is a valid result.
|
| More information in the manpage!
|
| Wietse
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Matus UHLAR - fantomas
>I have tried both
>
>[hidden email] relay:[smtp.foo.com]
>
>and
>
>relay:[smtp.foo.com]
>
>as the the output of the ldap lookup and i just get
>
>status=deferred (mail transport unavailable) error

any other error in logs? IS the smtp.foo.com reachable?

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines.
ab
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

ab
Hi,

That is the only error

Sep 19 14:59:54 foo postfix/error[103706]: 3C10828C082: to=<[hidden email]>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)

This is a MTA relay host

Thanks

--
______________________
Adam Barnett
Systems Engineer
Double Negative
160 Great Portland Street,W1W 5QA
T: 020-7268-5000
[ http://www.dneg.com/ | www.dneg.com ]
______________________

----- Original Message -----
| From: "Matus UHLAR - fantomas" <[hidden email]>
| To: "Postfix users" <[hidden email]>
| Sent: Thursday, 19 September, 2019 16:00:03
| Subject: Re: transport map from ldap

|>I have tried both
|>
|>[hidden email] relay:[smtp.foo.com]
|>
|>and
|>
|>relay:[smtp.foo.com]
|>
|>as the the output of the ldap lookup and i just get
|>
|>status=deferred (mail transport unavailable) error
|
| any other error in logs? IS the smtp.foo.com reachable?
|
| --
| Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
| Warning: I wish NOT to receive e-mail advertising to this address.
| Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
| Eagles may soar, but weasels don't get sucked into jet engines.
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Wietse Venema
Adam Barnett:
> Hi,
>
> That is the only error
>
> Sep 19 14:59:54 foo postfix/error[103706]: 3C10828C082: to=<[hidden email]>, relay=none, delay=0.01, delays=0/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)
>

There is more than this.

        Wietse

http://www.postfix.org/DEBUG_README.html#logging

Postfix logs all failed and successful deliveries to a logfile.

When Postfix uses syslog logging (the default), the file is usually
called /var/log/maillog, /var/log/mail, or something similar; the
exact pathname is configured in a file called /etc/syslog.conf,
/etc/rsyslog.conf, or something similar.

When Postfix uses its own logging system (see MAILLOG_README), the
location of the logfile is configured with the Postfix maillog_file
parameter.

When Postfix does not receive or deliver mail, the first order of
business is to look for errors that prevent Postfix from working
properly:

% egrep '(warning|error|fatal|panic):' /some/log/file | more Note:
the most important message is near the BEGINNING of the output.
Error messages that come later are less useful.

The nature of each problem is indicated as follows:

"panic" indicates a problem in the software itself that only a
programmer can fix. Postfix cannot proceed until this is fixed.

"fatal" is the result of missing files, incorrect permissions,
incorrect configuration file settings that you can fix. Postfix
cannot proceed until this is fixed.

"error" reports an error condition. For safety reasons, a Postfix
process will terminate when more than 13 of these happen.

"warning" indicates a non-fatal error. These are problems that you
may not be able to fix (such as a broken DNS server elsewhere on
the network) but may also indicate local configuration errors that
could become a problem later.
ab
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

ab
There was this error as well

Sep 19 14:59:47 foo postfix/qmgr[103420]: warning: connect to transport private/[hidden email]    relay: No such file or directory


--
______________________
Adam Barnett
Systems Engineer
Double Negative
160 Great Portland Street,W1W 5QA
T: 020-7268-5000
[ http://www.dneg.com/ | www.dneg.com ]
______________________

----- Original Message -----
| From: "Wietse Venema" <[hidden email]>
| To: "Postfix users" <[hidden email]>
| Sent: Thursday, 19 September, 2019 16:19:41
| Subject: Re: transport map from ldap

| Adam Barnett:
|> Hi,
|>
|> That is the only error
|>
|> Sep 19 14:59:54 foo postfix/error[103706]: 3C10828C082: to=<[hidden email]>,
|> relay=none, delay=0.01, delays=0/0/0/0, dsn=4.3.0, status=deferred (mail
|> transport unavailable)
|>
|
| There is more than this.
|
| Wietse
|
| http://www.postfix.org/DEBUG_README.html#logging
|
| Postfix logs all failed and successful deliveries to a logfile.
|
| When Postfix uses syslog logging (the default), the file is usually
| called /var/log/maillog, /var/log/mail, or something similar; the
| exact pathname is configured in a file called /etc/syslog.conf,
| /etc/rsyslog.conf, or something similar.
|
| When Postfix uses its own logging system (see MAILLOG_README), the
| location of the logfile is configured with the Postfix maillog_file
| parameter.
|
| When Postfix does not receive or deliver mail, the first order of
| business is to look for errors that prevent Postfix from working
| properly:
|
| % egrep '(warning|error|fatal|panic):' /some/log/file | more Note:
| the most important message is near the BEGINNING of the output.
| Error messages that come later are less useful.
|
| The nature of each problem is indicated as follows:
|
| "panic" indicates a problem in the software itself that only a
| programmer can fix. Postfix cannot proceed until this is fixed.
|
| "fatal" is the result of missing files, incorrect permissions,
| incorrect configuration file settings that you can fix. Postfix
| cannot proceed until this is fixed.
|
| "error" reports an error condition. For safety reasons, a Postfix
| process will terminate when more than 13 of these happen.
|
| "warning" indicates a non-fatal error. These are problems that you
| may not be able to fix (such as a broken DNS server elsewhere on
| the network) but may also indicate local configuration errors that
| could become a problem later.
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Wietse Venema
Adam Barnett:
> There was this error as well
>
> Sep 19 14:59:47 foo postfix/qmgr[103420]: warning: connect to transport private/[hidden email]    relay: No such file or directory
>

Right. That was for the malformed transport result with an email
address at the beginning.

What about the other one?

        Wietse
ab
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

ab
When i changed the LDAP response to

server_host = ldap://zimbraldap:389
server_port = 389
search_base =
query_filter = (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
result_attribute = mail,zimbraMailAlias
version = 3
result_format=relay:[smtp.foo.com]
start_tls = no
timeout = 30


Sep 19 16:51:53 natter postfix/smtp[111518]: fatal: garbage after "]" in server description: [smtp.foo.com],relay:[smtp.foo.com],relay:[smtp.foo.com]
Sep 19 16:51:54 natter postfix/qmgr[111506]: warning: private/relay socket: malformed response
Sep 19 16:51:54 natter postfix/qmgr[111506]: warning: transport relay failure -- see a previous warning/fatal/panic logfile record for the problem description
Sep 19 16:51:54 natter postfix/master[84677]: warning: process /usr/lib/postfix/sbin/smtp pid 111518 exit status 1
Sep 19 16:51:54 natter postfix/master[84677]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling


--
______________________
Adam Barnett
Systems Engineer
Double Negative
160 Great Portland Street,W1W 5QA
T: 020-7268-5000
[ http://www.dneg.com/ | www.dneg.com ]
______________________

----- Original Message -----
| From: "Wietse Venema" <[hidden email]>
| To: "Postfix users" <[hidden email]>
| Sent: Thursday, 19 September, 2019 16:32:48
| Subject: Re: transport map from ldap

| Adam Barnett:
|> There was this error as well
|>
|> Sep 19 14:59:47 foo postfix/qmgr[103420]: warning: connect to transport
|> private/[hidden email]    relay: No such file or directory
|>
|
| Right. That was for the malformed transport result with an email
| address at the beginning.
|
| What about the other one?
|
| Wietse
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Bill Cole-3
On 19 Sep 2019, at 11:54, Adam Barnett wrote:

> When i changed the LDAP response to
>
> server_host = ldap://zimbraldap:389
> server_port = 389
> search_base =
> query_filter =
> (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
> result_attribute = mail,zimbraMailAlias

See the ldap_table(5) man page:

     After applying the result format, multiple values
     are concatenated as  comma  separated  strings.

If your records can contain both mail and zimbraMailAlias attributes (or
may contain multiples of either,) see the documentation of
"expansion_limit" in the same man page. If they all contain both
attributes, pick one.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: transport map from ldap

Viktor Dukhovni
> On Sep 19, 2019, at 2:37 PM, Bill Cole <[hidden email]> wrote:
>
>> server_host = ldap://zimbraldap:389
>> server_port = 389
>> search_base =
>> query_filter = (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
>> result_attribute = mail,zimbraMailAlias
>
> See the ldap_table(5) man page:
>
>    After applying the result format, multiple values
>    are concatenated as  comma  separated  strings.
>
> If your records can contain both mail and zimbraMailAlias attributes (or may contain multiples of either,) see the documentation of "expansion_limit" in the same man page. If they all contain both attributes, pick one.

Yes, the LDAP table result for transport resolution must be "single-valued",
and a comma-separated list is unlikely to work.  That said, one might
hypothetically be able to chain the LDAP reply with some sort of PCRE-based
table via "pipemap", to extract a single transport value.  I'd advise against
that, and base the transport result on a single LDAP attribute.  If it needs
some post-processing to give an answer in the correct format, then consider
"pipemap".

    ldap = proxy:ldap:${config_directory}/
    pcre = pcre:{$config_directory}/
    transport_maps = pipemap:{
        ${ldap}ldap-transport.cf,
        ${pcre}ldap-transport.pcre
        }

The PCRE table can do simple substitutions, perhaps

        /(.*)/ relay:[$1]

if, e.g., the user's mailstore host is returned from LDAP as just
the hostname.

That said, I actually strongly discourage LDAP/SQL-based transport
tables.  Transport lookups are done sequentially in the queue
manager, and any interruption in service severely disrupts all
mail delivery, and lookup latency hampers performance.

My advice is to do virtual alias rewriting, and then resolve
to a transport on just the domain part of the address via
local indexed files.  If necessary, the rewriting can be
reversed in smtp_generic_maps for delivery to the mailstore
in the original primary public address form.

--
        Viktor.