From smeier at webster.edu Sun Jan 3 22:49:21 2016 From: smeier at webster.edu (Steve Meier) Date: Sun, 3 Jan 2016 21:49:21 +0000 Subject: Custom logic In-Reply-To: References: Message-ID: Is this listserv dead? If there is no community for AUTOMX then I will probably just create a custom application than use it since that was my original plan. -SM On Fri, Dec 18, 2015 at 5:51 PM -0800, "Steve Meier" > wrote: Hello, I am evaluating automx for potential use within our environment. I have set up an instance of automx for testing and am looking into how we can implement some programming logic needed to get a correct response needed to support our different use-cases. The general logic needed is- 1) User has provided a "username at domain.edu" address 2) Query our LDAP server by the uid=username and retrieve the mailRoutingAddress attribute. 3) mailRoutingAddress will follow one of three rules- a) the "username at servername.domain.edu" b) an external "forwarding address" that has been assigned by the user (for example a gmail, a yahoo, etc) c) "username at tenant.onmicrosoft.com" (in other words, an institution-specific Office 365 instance) 4) Based on the rules above, we need to send the correct response, respectively a) respond with settings for IMAP+SMTP email service (based off username, servername) b) don't send a response (or possibly fall back to settings using a different LDAP attribute) c respond with a redirect to Microsoft O365 autodiscover.outlook.com I have read through the documentation and it appears it may be possible to do this using automx, but I am not sure yet. The documentation referenced this listserv, so I thought I would ask. Can anyone provide some insight into whether or not above would be possible, and if so, the general approach to go about it? I can see it may require a combination of things (filters, custom scripts, LDAP, etc). Thanks and Happy Holidays =) -SteveM -------------- next part -------------- An HTML attachment was scrubbed... URL: From p at sys4.de Mon Jan 4 00:05:41 2016 From: p at sys4.de (Patrick Ben Koetter) Date: Mon, 4 Jan 2016 00:05:41 +0100 Subject: Custom logic In-Reply-To: References:

Message-ID: <20160103230541.GC21170@sys4.de> Steve, the listserv is not dead. I don't believe automx can do what you want out of the box. automx may include script logic to return results. Christian, author of automx, may let you in on the details. p at rick * Steve Meier : > Is this listserv dead? > > If there is no community for AUTOMX then I will probably just create a custom application than use it since that was my original plan. > > -SM > > > > On Fri, Dec 18, 2015 at 5:51 PM -0800, "Steve Meier" > wrote: > > > Hello, > > > I am evaluating automx for potential use within our environment. I have set up an instance of automx for testing and am looking into how we can implement some programming logic needed to get a correct response needed to support our different use-cases. > > > The general logic needed is- > > > 1) User has provided a "username at domain.edu" address > > 2) Query our LDAP server by the uid=username and retrieve the mailRoutingAddress attribute. > > 3) mailRoutingAddress will follow one of three rules- > > a) the "username at servername.domain.edu" > > b) an external "forwarding address" that has been assigned by the user (for example a gmail, a yahoo, etc) > > c) "username at tenant.onmicrosoft.com" (in other words, an institution-specific Office 365 instance) > > > 4) Based on the rules above, we need to send the correct response, respectively > > a) respond with settings for IMAP+SMTP email service (based off username, servername) > > b) don't send a response (or possibly fall back to settings using a different LDAP attribute) > > c respond with a redirect to Microsoft O365 autodiscover.outlook.com > > > > I have read through the documentation and it appears it may be possible to do this using automx, but I am not sure yet. The documentation referenced this listserv, so I thought I would ask. > > > Can anyone provide some insight into whether or not above would be possible, and if so, the general approach to go about it? I can see it may require a combination of things (filters, custom scripts, LDAP, etc). > > > Thanks and Happy Holidays =) > > -SteveM -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From smeier at webster.edu Mon Jan 4 04:36:02 2016 From: smeier at webster.edu (Steve Meier) Date: Mon, 4 Jan 2016 03:36:02 +0000 Subject: Custom logic In-Reply-To: <20160103230541.GC21170@sys4.de> References:

, <20160103230541.GC21170@sys4.de> Message-ID: Patrick, Thank you for giving me hope that the automx community still exists! I understand there is ability to implement custom scripting to incorporate the logic required for our situation. To go back to my original question, where is the most appropriate place to implement the custom logic I require without interfering with the automx source/design too much? Then you in advance, and Happy New Year to you! -SM On Sun, Jan 3, 2016 at 3:05 PM -0800, "Patrick Ben Koetter"

> wrote: Steve, the listserv is not dead. I don't believe automx can do what you want out of the box. automx may include script logic to return results. Christian, author of automx, may let you in on the details. p at rick * Steve Meier : > Is this listserv dead? > > If there is no community for AUTOMX then I will probably just create a custom application than use it since that was my original plan. > > -SM > > > > On Fri, Dec 18, 2015 at 5:51 PM -0800, "Steve Meier" > wrote: > > > Hello, > > > I am evaluating automx for potential use within our environment. I have set up an instance of automx for testing and am looking into how we can implement some programming logic needed to get a correct response needed to support our different use-cases. > > > The general logic needed is- > > > 1) User has provided a "username at domain.edu" address > > 2) Query our LDAP server by the uid=username and retrieve the mailRoutingAddress attribute. > > 3) mailRoutingAddress will follow one of three rules- > > a) the "username at servername.domain.edu" > > b) an external "forwarding address" that has been assigned by the user (for example a gmail, a yahoo, etc) > > c) "username at tenant.onmicrosoft.com" (in other words, an institution-specific Office 365 instance) > > > 4) Based on the rules above, we need to send the correct response, respectively > > a) respond with settings for IMAP+SMTP email service (based off username, servername) > > b) don't send a response (or possibly fall back to settings using a different LDAP attribute) > > c respond with a redirect to Microsoft O365 autodiscover.outlook.com > > > > I have read through the documentation and it appears it may be possible to do this using automx, but I am not sure yet. The documentation referenced this listserv, so I thought I would ask. > > > Can anyone provide some insight into whether or not above would be possible, and if so, the general approach to go about it? I can see it may require a combination of things (filters, custom scripts, LDAP, etc). > > > Thanks and Happy Holidays =) > > -SteveM -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -------------- next part -------------- An HTML attachment was scrubbed... URL: From p at sys4.de Mon Jan 4 08:53:29 2016 From: p at sys4.de (Patrick Ben Koetter) Date: Mon, 4 Jan 2016 08:53:29 +0100 Subject: Custom logic In-Reply-To: References: <20160103230541.GC21170@sys4.de> Message-ID: <20160104075329.GA29492@sys4.de> Steve, * Steve Meier : > Patrick, > > Thank you for giving me hope that the automx community still exists! I don't know when you sent your original posting. All that comes to mind is: x-mas time is the best time to experience low reply rates. > I understand there is ability to implement custom scripting to incorporate the logic required for our situation. To go back to my original question, where is the most appropriate place to implement the custom logic I require without interfering with the automx source/design too much? Let me break this down into distinct steps: Step 1: input automx offers 3 different input methods - one for autodisover, one for autoconfig and one or iOS queries. Step 2: decision Depending on the mail address submitted it then decides if it should serve that mail domain and then - if it should - it chooses a profile. Step 3: calculation Once it has decided on a profile it uses whatever method has been configured within that profile. Step 4: output It generates a profile and sends it back via the input method used by the client. I take it we agree, if you decide to use automx, it makes sense to leave steps 1 and 4 as they are (reuse) and only work on 2 or 3 (modify). The challenge, I think, is in the decision part. As I understand your description you seem to have 3 reply cases: - Yes, we provide profiles for that (sub)domain - No, we don't provide profiles for remote domains - No, we don't provide profiles that (sub)domain, but someone else does If we're lucky you will only have to configure automx for the first use case and the other use cases will be handled outside of automx. This depends on the level where you decide which system should serve profile data. On which level do you decide/separate mail services within your organisation? Do all accounts use the same domain, e.g. example.com, and you need to decide which account should receive a profile for either your own or a remote mail service (here: Microsoft O365) within the same domain? Or do the accounts use different (sub)domains that show up in different mail adresses, e.g. account at sub1.example.com and account at sub2.example.com. We're lucky if we can tell the accounts apart by different (sub)domains. Here's what you would do: Yes, we provide profiles for that (sub)domain Configure automx for the (sub)domains you serve inhouse. No, we don't provide profiles for remote domains If the user enters a mail address for e.g. yahoo.com, the mail client will not contact automx. It will send the profile request to e.g. autodiscover.yahoo.com. It will never contact automx on your plattform. No, we don't provide profiles that (sub)domain, but someone else does The client will search via DNS in your subdomain. Configure your DNS to send a redirect (CNAME) to e.g. autodiscover.outlook.com. The mail client will note it, notify the user it should be redirected, let the user decide and finally ask autodiscover.outlook.com for appropriate profile data. p at rick > > Then you in advance, and Happy New Year to you! > > -SM > > > > On Sun, Jan 3, 2016 at 3:05 PM -0800, "Patrick Ben Koetter"

: > Steve, > > * Steve Meier : >> Patrick, >> >> Thank you for giving me hope that the automx community still exists! > > I don't know when you sent your original posting. All that comes to mind is: > x-mas time is the best time to experience low reply rates. > > >> I understand there is ability to implement custom scripting to >> incorporate the logic required for our situation. To go back to my >> original question, where is the most appropriate place to implement >> the custom logic I require without interfering with the automx >> source/design too much? > the need to redirect some autodiscover request to an other server based on the mail address and not per subdomain has come up lately. > Let me break this down into distinct steps: > > Step 1: input > automx offers 3 different input methods - one for autodisover, one for > autoconfig and one or iOS queries. > > Step 2: decision > Depending on the mail address submitted it then decides if it > should serve > that mail domain and then - if it should - it chooses a profile. > As far as I understand Steve, and what we need, the decision is based on the full mailaddress so usera at mai.domain receives a configuration, userb at mail.domain gets redirected to https://external.server in step 4. > Step 3: calculation > Once it has decided on a profile it uses whatever method has been > configured within that profile. > > Step 4: output > It generates a profile and sends it back via the input method used by the > client. > > > I take it we agree, if you decide to use automx, it makes sense to > leave steps > 1 and 4 as they are (reuse) and only work on 2 or 3 (modify). > Step 4 needs the ability to send an redirect response > The challenge, I think, is in the decision part. As I understand your > description you seem to have 3 reply cases: > > - Yes, we provide profiles for that (sub)domain > > - No, we don't provide profiles for remote domains > > - No, we don't provide profiles that (sub)domain, but someone else does > > If we're lucky you will only have to configure automx for the first use case > and the other use cases will be handled outside of automx. This > depends on the > level where you decide which system should serve profile data. > > On which level do you decide/separate mail services within your organisation? > Do all accounts use the same domain, e.g. example.com, and you need to decide > which account should receive a profile for either your own or a remote mail > service (here: Microsoft O365) within the same domain? Or do the accounts use > different (sub)domains that show up in different mail adresses, e.g. > account at sub1.example.com and account at sub2.example.com. > > We're lucky if we can tell the accounts apart by different (sub)domains. > Here's what you would do: > > Yes, we provide profiles for that (sub)domain > Configure automx for the (sub)domains you serve inhouse. > > No, we don't provide profiles for remote domains > If the user enters a mail address for e.g. yahoo.com, the mail > client will > not contact automx. It will send the profile request to e.g. > autodiscover.yahoo.com. It will never contact automx on your plattform. > > No, we don't provide profiles that (sub)domain, but someone else does > The client will search via DNS in your subdomain. Configure your DNS to > send a redirect (CNAME) to e.g. autodiscover.outlook.com. The mail client > will note it, notify the user it should be redirected, let the > user decide > and finally ask autodiscover.outlook.com for appropriate profile data. > > p at rick > We thought to implement this feature our self, but I didn't have time to look into it. > > >> >> Then you in advance, and Happy New Year to you! >> >> -SM >> >> >> >> On Sun, Jan 3, 2016 at 3:05 PM -0800, "Patrick Ben Koetter" >>

> wrote: > > Steve, > > the listserv is not dead. > > I don't believe automx can do what you want out of the box. automx may > include script logic to return results. > > Christian, author of automx, may let you in on the details. > > p at rick > > > > * Steve Meier : > > Is this listserv dead? > > > > If there is no community for AUTOMX then I will probably just create a custom application than use it since that was my original plan. > > > > -SM > > > > > > > > On Fri, Dec 18, 2015 at 5:51 PM -0800, "Steve Meier" > wrote: > > > > > > Hello, > > > > > > I am evaluating automx for potential use within our environment. I have set up an instance of automx for testing and am looking into how we can implement some programming logic needed to get a correct response needed to support our different use-cases. > > > > > > The general logic needed is- > > > > > > 1) User has provided a "username at domain.edu" address > > > > 2) Query our LDAP server by the uid=username and retrieve the mailRoutingAddress attribute. > > > > 3) mailRoutingAddress will follow one of three rules- > > > > a) the "username at servername.domain.edu" > > > > b) an external "forwarding address" that has been assigned by the > > user (for example a gmail, a yahoo, etc) > > > > c) "username at tenant.onmicrosoft.com" (in other words, an > > institution-specific Office 365 instance) > > > > > > 4) Based on the rules above, we need to send the correct response, > > respectively > > > > a) respond with settings for IMAP+SMTP email service (based off > > username, servername) > > > > b) don't send a response (or possibly fall back to settings using > > a different LDAP attribute) > > > > c respond with a redirect to Microsoft O365 > > autodiscover.outlook.com > > > > > > > > I have read through the documentation and it appears it may be possible to do this using automx, but I am not sure yet. The documentation referenced this listserv, so I thought I would ask. > > > > > > Can anyone provide some insight into whether or not above would be possible, and if so, the general approach to go about it? I can see it may require a combination of things (filters, custom scripts, LDAP, etc). > > > > > > Thanks and Happy Holidays =) > > > > -SteveM > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstra?e 15, 81669 M?nchen > > Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: From p at sys4.de Wed Jan 6 00:05:19 2016 From: p at sys4.de (Patrick Ben Koetter) Date: Wed, 6 Jan 2016 00:05:19 +0100 Subject: Custom logic In-Reply-To: References: <20160103230541.GC21170@sys4.de> <20160104075329.GA29492@sys4.de> Message-ID: <20160105230519.GA4588@sys4.de> * Steve Meier : > Thank you very much for your response, this is helpful for me to think through how to possibly accomplish this. > > In answer to the question, all of the email addresses (queried from the client) would have the same domain that we host for (webster.edu). The key is to perform the attribute lookup in our directory to determine the mailRoutingAddress which will then appear as "username at server.webster.edu" (or the other two possibilities). And then send the response back. > > As you mention this needs to occur in steps 2 and 3. It is looking like to accomplish this I will likely need to customize some pieces of the automx source. > > I hope to look into this more but I have been pulled in some other work, and this was going to be a "side project" for me so we will see! Christian and I are busy, too. We're here to pick up whenever you are ready. p at rick > > -SM > > > -----Original Message----- > From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of Patrick Ben Koetter > Sent: Monday, January 4, 2016 1:53 > To: automx-users at sys4.de > Subject: Re: Custom logic > > Steve, > > * Steve Meier : > > Patrick, > > > > Thank you for giving me hope that the automx community still exists! > > I don't know when you sent your original posting. All that comes to mind is: > x-mas time is the best time to experience low reply rates. > > > > I understand there is ability to implement custom scripting to incorporate the logic required for our situation. To go back to my original question, where is the most appropriate place to implement the custom logic I require without interfering with the automx source/design too much? > > Let me break this down into distinct steps: > > Step 1: input > automx offers 3 different input methods - one for autodisover, one for > autoconfig and one or iOS queries. > > Step 2: decision > Depending on the mail address submitted it then decides if it should serve > that mail domain and then - if it should - it chooses a profile. > > Step 3: calculation > Once it has decided on a profile it uses whatever method has been > configured within that profile. > > Step 4: output > It generates a profile and sends it back via the input method used by the > client. > > > I take it we agree, if you decide to use automx, it makes sense to leave steps > 1 and 4 as they are (reuse) and only work on 2 or 3 (modify). > > The challenge, I think, is in the decision part. As I understand your description you seem to have 3 reply cases: > > - Yes, we provide profiles for that (sub)domain > > - No, we don't provide profiles for remote domains > > - No, we don't provide profiles that (sub)domain, but someone else does > > If we're lucky you will only have to configure automx for the first use case and the other use cases will be handled outside of automx. This depends on the level where you decide which system should serve profile data. > > On which level do you decide/separate mail services within your organisation? > Do all accounts use the same domain, e.g. example.com, and you need to decide which account should receive a profile for either your own or a remote mail service (here: Microsoft O365) within the same domain? Or do the accounts use different (sub)domains that show up in different mail adresses, e.g. > account at sub1.example.com and account at sub2.example.com. > > We're lucky if we can tell the accounts apart by different (sub)domains. > Here's what you would do: > > Yes, we provide profiles for that (sub)domain > Configure automx for the (sub)domains you serve inhouse. > > No, we don't provide profiles for remote domains > If the user enters a mail address for e.g. yahoo.com, the mail client will > not contact automx. It will send the profile request to e.g. > autodiscover.yahoo.com. It will never contact automx on your plattform. > > No, we don't provide profiles that (sub)domain, but someone else does > The client will search via DNS in your subdomain. Configure your DNS to > send a redirect (CNAME) to e.g. autodiscover.outlook.com. The mail client > will note it, notify the user it should be redirected, let the user decide > and finally ask autodiscover.outlook.com for appropriate profile data. > > p at rick > > > > > > > Then you in advance, and Happy New Year to you! > > > > -SM > > > > > > > > On Sun, Jan 3, 2016 at 3:05 PM -0800, "Patrick Ben Koetter"

> wrote: > > > > Steve, > > > > the listserv is not dead. > > > > I don't believe automx can do what you want out of the box. automx may > > include script logic to return results. > > > > Christian, author of automx, may let you in on the details. > > > > p at rick > > > > > > > > * Steve Meier : > > > Is this listserv dead? > > > > > > If there is no community for AUTOMX then I will probably just create a custom application than use it since that was my original plan. > > > > > > -SM > > > > > > > > > > > > On Fri, Dec 18, 2015 at 5:51 PM -0800, "Steve Meier" > wrote: > > > > > > > > > Hello, > > > > > > > > > I am evaluating automx for potential use within our environment. I have set up an instance of automx for testing and am looking into how we can implement some programming logic needed to get a correct response needed to support our different use-cases. > > > > > > > > > The general logic needed is- > > > > > > > > > 1) User has provided a "username at domain.edu" address > > > > > > 2) Query our LDAP server by the uid=username and retrieve the mailRoutingAddress attribute. > > > > > > 3) mailRoutingAddress will follow one of three rules- > > > > > > a) the "username at servername.domain.edu" > > > > > > b) an external "forwarding address" that has been assigned by the > > > user (for example a gmail, a yahoo, etc) > > > > > > c) "username at tenant.onmicrosoft.com" (in other words, an > > > institution-specific Office 365 instance) > > > > > > > > > 4) Based on the rules above, we need to send the correct response, > > > respectively > > > > > > a) respond with settings for IMAP+SMTP email service (based off > > > username, servername) > > > > > > b) don't send a response (or possibly fall back to settings using > > > a different LDAP attribute) > > > > > > c respond with a redirect to Microsoft O365 > > > autodiscover.outlook.com > > > > > > > > > > > > I have read through the documentation and it appears it may be possible to do this using automx, but I am not sure yet. The documentation referenced this listserv, so I thought I would ask. > > > > > > > > > Can anyone provide some insight into whether or not above would be possible, and if so, the general approach to go about it? I can see it may require a combination of things (filters, custom scripts, LDAP, etc). > > > > > > > > > Thanks and Happy Holidays =) > > > > > > -SteveM > > > > -- > > [*] sys4 AG > > > > https://sys4.de, +49 (89) 30 90 46 64 > > Franziskanerstra?e 15, 81669 M?nchen > > > > Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 > > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > > Aufsichtsratsvorsitzender: Florian Kirstein > > > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstra?e 15, 81669 M?nchen > > Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From hans.moser at ofd-z.niedersachsen.de Wed Jan 6 09:09:56 2016 From: hans.moser at ofd-z.niedersachsen.de (Marc Patermann) Date: Wed, 6 Jan 2016 09:09:56 +0100 Subject: Custom logic In-Reply-To: References: Message-ID: <568CCBD4.8000003@ofd-z.niedersachsen.de> Steve, Am 19.12.2015 um 02:51 Uhr schrieb Steve Meier: > The general logic needed is- > > > 1) User has provided a "*username at domain.edu*" address > > 2) Query our LDAP server by the *uid=username* and retrieve the > *mailRoutingAddress *attribute. > > 3) *mailRoutingAddress *will follow one of *three rules*- > > a) the "username@*servername*.domain.edu" > > b) an external "forwarding address" that has been assigned by the > user (for example a gmail, a yahoo, etc) > > c) "username@*tenant.onmicrosoft.com*" (in other words, an > institution-specific Office 365 instance) so this is coming out of your directory directly, right? > 4) Based on the rules above, we need to send the correct response, > respectively > > a) respond with settings for IMAP+SMTP email service (based off > *username, servername*) > > b) don't send a response (or possibly fall back to settings using a > different LDAP attribute) > > c respond with a *redirect to Microsoft O365 autodiscover.outlook.com* If I understood correctly, you do not have the values for LDAP- and SMTP-server in your directory, so you cannot just sends this information to automx, right? This is the problem? > I have read through the documentation and it appears it may be possible > to do this using automx, but I am not sure yet. The documentation > referenced this listserv, so I thought I would ask. If the answer form LDAP is if $addresse ~= *tenant.onmicrosoft.com then smptserver = microsoftserver then imapserver = microsoftserver > Can anyone provide some insight into whether or not above would be > possible, and if so, the general approach to go about it? I can see it > may require a combination of things (filters, custom scripts, LDAP, etc). The easiest way would be to store the information directly in your LDAP and send it back to automx. Marc From smeier at webster.edu Wed Jan 6 23:21:43 2016 From: smeier at webster.edu (Steve Meier) Date: Wed, 6 Jan 2016 22:21:43 +0000 Subject: Custom logic In-Reply-To: <568CCBD4.8000003@ofd-z.niedersachsen.de> References: <568CCBD4.8000003@ofd-z.niedersachsen.de> Message-ID: It seems like I could accomplish this by use of section filters. I would write a script that can return the correct section that matches the required profile. I also read somewhere that you can specify "backend=script" but I'm not seeing that plainly documented. -SM """ section_filter (default: domainpart, optional) Specifies a list of one or more filters whose result outputs a section name. The filters will be used in order specified. The first match ends execution of subsequent filters. These filters will be used instead of the hard coded, internal domainpart filter, which strictly uses the domainpart taken from the email address the client submitted in its configuration request: section_filters = server_1, server_2 server_1 = /usr/sbin/postmap -q "%u" hash:/etc/postfix/virtual_alias_domains | \ sed -e 's/^.*@$\.*$/\1/g' | grep internal.example.com server_2 = /usr/sbin/postmap -q "%u" hash:/etc/postfix/virtual_alias_domains | \ sed -e 's/^.*@$\.*$/\1/g' | grep dmz.example.com """ """ automx_script.5.rst: Specifies the absolute path to the script which should be run by the backend automx_script(5) backend:: automx_script.5.rst: script = /usr/local/bin/example_com.sh "%s" """ -----Original Message----- From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of Marc Patermann Sent: Wednesday, January 6, 2016 2:10 To: automx-users at sys4.de Subject: Re: Custom logic Steve, Am 19.12.2015 um 02:51 Uhr schrieb Steve Meier: > The general logic needed is- > > > 1) User has provided a "*username at domain.edu*" address > > 2) Query our LDAP server by the *uid=username* and retrieve the > *mailRoutingAddress *attribute. > > 3) *mailRoutingAddress *will follow one of *three rules*- > > a) the "username@*servername*.domain.edu" > > b) an external "forwarding address" that has been assigned by the > user (for example a gmail, a yahoo, etc) > > c) "username@*tenant.onmicrosoft.com*" (in other words, an > institution-specific Office 365 instance) so this is coming out of your directory directly, right? > 4) Based on the rules above, we need to send the correct response, > respectively > > a) respond with settings for IMAP+SMTP email service (based off > *username, servername*) > > b) don't send a response (or possibly fall back to settings using a > different LDAP attribute) > > c respond with a *redirect to Microsoft O365 > autodiscover.outlook.com* If I understood correctly, you do not have the values for LDAP- and SMTP-server in your directory, so you cannot just sends this information to automx, right? This is the problem? > I have read through the documentation and it appears it may be > possible to do this using automx, but I am not sure yet. The > documentation referenced this listserv, so I thought I would ask. If the answer form LDAP is if $addresse ~= *tenant.onmicrosoft.com then smptserver = microsoftserver then imapserver = microsoftserver > Can anyone provide some insight into whether or not above would be > possible, and if so, the general approach to go about it? I can see > it may require a combination of things (filters, custom scripts, LDAP, etc). The easiest way would be to store the information directly in your LDAP and send it back to automx. Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: From smeier at webster.edu Fri Jan 8 03:35:45 2016 From: smeier at webster.edu (Steve Meier) Date: Fri, 8 Jan 2016 02:35:45 +0000 Subject: Custom logic In-Reply-To: References: <568CCBD4.8000003@ofd-z.niedersachsen.de> Message-ID: I have created a python script that will perform the required logic and is capable of returning any necessary parameters, I just need to figure out how best to tie it into the automx program. I saw references that "SCRIPT" backend can be used, but I did not see how to config SCRIPT backend in the CONF (or an example). I also thought possibly using section filters but did not want to try that if the SCRIPT backend option is available. root at testVM:/root# python getMailConfig.py smeier LDAP search FOR uid=smeier IN ou=people,dc=webster,dc=edu.. Returned user- uid=smeier,ou=people,dc=webster,dc=edu Mail Routing address- smeier at websteru.onmicrosoft.com Email TYPE is- WebsterU O365 Email Address Response- should redirect root at testVM:/root# python getMailConfig.py test3 LDAP search FOR uid=test3 IN ou=people,dc=webster,dc=edu.. Returned user- uid=test3,ou=people,dc=webster,dc=edu Mail Routing address- test3 at bailey.webster.edu Email TYPE is- Webster U Internal Mail Address Response- config Incoming server- bailey.webster.edu Outgoing server- smtp.webster.edu root at testVM:/root# python getMailConfig.py test2 LDAP search FOR uid=test2 IN ou=people,dc=webster,dc=edu.. Returned user- uid=test2,ou=people,dc=webster,dc=edu Mail Routing address- someone at gmail.com Email TYPE is- Unknown/fallthrough (external forwarding address or other issue) Response- reject -----Original Message----- From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of Steve Meier Sent: Wednesday, January 6, 2016 16:22 To: Marc Patermann ; automx-users at sys4.de Subject: RE: Custom logic It seems like I could accomplish this by use of section filters. I would write a script that can return the correct section that matches the required profile. I also read somewhere that you can specify "backend=script" but I'm not seeing that plainly documented. -SM """ section_filter (default: domainpart, optional) Specifies a list of one or more filters whose result outputs a section name. The filters will be used in order specified. The first match ends execution of subsequent filters. These filters will be used instead of the hard coded, internal domainpart filter, which strictly uses the domainpart taken from the email address the client submitted in its configuration request: section_filters = server_1, server_2 server_1 = /usr/sbin/postmap -q "%u" hash:/etc/postfix/virtual_alias_domains | \ sed -e 's/^.*@$\.*$/\1/g' | grep internal.example.com server_2 = /usr/sbin/postmap -q "%u" hash:/etc/postfix/virtual_alias_domains | \ sed -e 's/^.*@$\.*$/\1/g' | grep dmz.example.com """ """ automx_script.5.rst: Specifies the absolute path to the script which should be run by the backend automx_script(5) backend:: automx_script.5.rst: script = /usr/local/bin/example_com.sh "%s" """ -----Original Message----- From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of Marc Patermann Sent: Wednesday, January 6, 2016 2:10 To: automx-users at sys4.de Subject: Re: Custom logic Steve, Am 19.12.2015 um 02:51 Uhr schrieb Steve Meier: > The general logic needed is- > > > 1) User has provided a "*username at domain.edu*" address > > 2) Query our LDAP server by the *uid=username* and retrieve the > *mailRoutingAddress *attribute. > > 3) *mailRoutingAddress *will follow one of *three rules*- > > a) the "username@*servername*.domain.edu" > > b) an external "forwarding address" that has been assigned by the > user (for example a gmail, a yahoo, etc) > > c) "username@*tenant.onmicrosoft.com*" (in other words, an > institution-specific Office 365 instance) so this is coming out of your directory directly, right? > 4) Based on the rules above, we need to send the correct response, > respectively > > a) respond with settings for IMAP+SMTP email service (based off > *username, servername*) > > b) don't send a response (or possibly fall back to settings using a > different LDAP attribute) > > c respond with a *redirect to Microsoft O365 > autodiscover.outlook.com* If I understood correctly, you do not have the values for LDAP- and SMTP-server in your directory, so you cannot just sends this information to automx, right? This is the problem? > I have read through the documentation and it appears it may be > possible to do this using automx, but I am not sure yet. The > documentation referenced this listserv, so I thought I would ask. If the answer form LDAP is if $addresse ~= *tenant.onmicrosoft.com then smptserver = microsoftserver then imapserver = microsoftserver > Can anyone provide some insight into whether or not above would be > possible, and if so, the general approach to go about it? I can see > it may require a combination of things (filters, custom scripts, LDAP, etc). The easiest way would be to store the information directly in your LDAP and send it back to automx. Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: From smeier at webster.edu Fri Jan 8 15:56:52 2016 From: smeier at webster.edu (Steve Meier) Date: Fri, 8 Jan 2016 14:56:52 +0000 Subject: Custom logic In-Reply-To: <0D760444-E651-49F4-A647-8B50D0BF4D6C@extremeshok.com> References: <568CCBD4.8000003@ofd-z.niedersachsen.de> <0D760444-E651-49F4-A647-8B50D0BF4D6C@extremeshok.com> Message-ID: The only input domain we will accept will be our own @webster.edu. So I will be fine regardless of whether I need to use the entire email address or just the username. We have 11 possible incoming mail servers on our internally hosted email, so I'd rather avoid trying to do a series of 11 (+2) section filters if the SCRIPT backend is possible. Anything that resolves to a non @webster.edu address is essentially a forward to another domain which we would reject configuration. Below covers all of the use cases. The "action" represents what I would need automx to do. (I know for Outlook Autodiscover there is a REDIRECT although I'm pretty sure that is not yet supported in automx but I think I could trick it using a "STATIC" config and maybe a custom XML template for redirect when it comes to that. -SM root at testVM:/root# python getMailConfig.py test2 LDAP search FOR uid=test2 IN ou=people,dc=webster,dc=edu.. Returned user object- uid=test2,ou=people,dc=webster,dc=edu test2 at webster.edu resolves to test2 at auden.webster.edu Email TYPE is- Webster U Internal Mail Action- config Incoming server- auden.webster.edu Outgoing server- smtp.webster.edu root at testVM:/root# python getMailConfig.py test3 LDAP search FOR uid=test3 IN ou=people,dc=webster,dc=edu.. Returned user object- uid=test3,ou=people,dc=webster,dc=edu test3 at webster.edu resolves to test3 at bailey.webster.edu Email TYPE is- Webster U Internal Mail Action- config Incoming server- bailey.webster.edu Outgoing server- smtp.webster.edu root at testVM:/root# python getMailConfig.py test4 LDAP search FOR uid=test4 IN ou=people,dc=webster,dc=edu.. Returned user object- uid=test4,ou=people,dc=webster,dc=edu test4 at webster.edu resolves to test4 at websteru.onmicrosoft.com Email TYPE is- WebsterU O365 Mail Action- should redirect to autodiscover.outlook.com root at testVM:/root# python getMailConfig.py test5 LDAP search FOR uid=test5 IN ou=people,dc=webster,dc=edu.. Returned user object- uid=test5,ou=people,dc=webster,dc=edu test5 at webster.edu resolves to personal at gmail.com Email TYPE is- Unknown/fallthrough (external forwarding address or other issue) Action- reject for test5 at webster.edu -> personal at gmail.com -----Original Message----- From: admin at extremeshok.com [mailto:admin at extremeshok.com] Sent: Friday, January 8, 2016 7:18 To: Steve Meier Subject: Re: Custom logic What if u have test at 123 and test at xyz and search for test? Sent from my iPhone > On 08 Jan 2016, at 4:35 AM, Steve Meier wrote: > > I have created a python script that will perform the required logic > and is capable of returning any necessary parameters, I just need to > figure out how best to tie it into the automx program. > > I saw references that "SCRIPT" backend can be used, but I did not see > how to config SCRIPT backend in the CONF (or an example). > > I also thought possibly using section filters but did not want to try > that if the SCRIPT backend option is available. > > > root at testVM:/root# python getMailConfig.py smeier LDAP search FOR > uid=smeier IN ou=people,dc=webster,dc=edu.. > Returned user- uid=smeier,ou=people,dc=webster,dc=edu > Mail Routing address- smeier at websteru.onmicrosoft.com Email TYPE is- > WebsterU O365 Email Address > Response- should redirect > > root at testVM:/root# python getMailConfig.py test3 LDAP search FOR > uid=test3 IN ou=people,dc=webster,dc=edu.. > Returned user- uid=test3,ou=people,dc=webster,dc=edu > Mail Routing address- test3 at bailey.webster.edu Email TYPE is- Webster > U Internal Mail Address > Response- config > Incoming server- bailey.webster.edu > Outgoing server- smtp.webster.edu > > root at testVM:/root# python getMailConfig.py test2 LDAP search FOR > uid=test2 IN ou=people,dc=webster,dc=edu.. > Returned user- uid=test2,ou=people,dc=webster,dc=edu > Mail Routing address- someone at gmail.com Email TYPE is- > Unknown/fallthrough (external forwarding address or other > issue) > Response- reject > > > -----Original Message----- > From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of > Steve Meier > Sent: Wednesday, January 6, 2016 16:22 > To: Marc Patermann ; > automx-users at sys4.de > Subject: RE: Custom logic > > It seems like I could accomplish this by use of section filters. I > would write a script that can return the correct section that matches > the required profile. > > I also read somewhere that you can specify "backend=script" but I'm > not seeing that plainly documented. > > -SM > > > """ > section_filter (default: domainpart, optional) > > Specifies a list of one or more filters whose result outputs a section > name. The filters will be used in order specified. The first match ends > execution of subsequent filters. > > These filters will be used instead of the hard coded, internal > domainpart > filter, which strictly uses the domainpart taken from the email > address the > client submitted in its configuration request: > > section_filters = server_1, server_2 > server_1 = /usr/sbin/postmap -q "%u" > hash:/etc/postfix/virtual_alias_domains | \ > sed -e 's/^.*@$\.*$/\1/g' | grep internal.example.com > server_2 = /usr/sbin/postmap -q "%u" > hash:/etc/postfix/virtual_alias_domains | \ > sed -e 's/^.*@$\.*$/\1/g' | grep dmz.example.com """ > > """ > automx_script.5.rst: Specifies the absolute path to the script which > should be run by the backend automx_script(5) backend:: > automx_script.5.rst: script = /usr/local/bin/example_com.sh > "%s" > """ > > -----Original Message----- > From: automx-users [mailto:automx-users-bounces at sys4.de] On Behalf Of > Marc Patermann > Sent: Wednesday, January 6, 2016 2:10 > To: automx-users at sys4.de > Subject: Re: Custom logic > > Steve, > >> Am 19.12.2015 um 02:51 Uhr schrieb Steve Meier: >> The general logic needed is- >> >> >> 1) User has provided a "*username at domain.edu*" address >> >> 2) Query our LDAP server by the *uid=username* and retrieve the >> *mailRoutingAddress *attribute. >> >> 3) *mailRoutingAddress *will follow one of *three rules*- >> >> a) the "username@*servername*.domain.edu" >> >> b) an external "forwarding address" that has been assigned by the >> user (for example a gmail, a yahoo, etc) >> >> c) "username@*tenant.onmicrosoft.com*" (in other words, an >> institution-specific Office 365 instance) > so this is coming out of your directory directly, right? > >> 4) Based on the rules above, we need to send the correct response, >> respectively >> >> a) respond with settings for IMAP+SMTP email service (based off >> *username, servername*) >> >> b) don't send a response (or possibly fall back to settings using a >> different LDAP attribute) >> >> c respond with a *redirect to Microsoft O365 >> autodiscover.outlook.com* > If I understood correctly, you do not have the values for LDAP- and > SMTP-server in your directory, so you cannot just sends this > information to automx, right? > This is the problem? > >> I have read through the documentation and it appears it may be >> possible to do this using automx, but I am not sure yet. The >> documentation referenced this listserv, so I thought I would ask. > If the answer form LDAP is > if $addresse ~= *tenant.onmicrosoft.com > then smptserver = microsoftserver > then imapserver = microsoftserver > >> Can anyone provide some insight into whether or not above would be >> possible, and if so, the general approach to go about it? I can see >> it may require a combination of things (filters, custom scripts, >> LDAP, > etc). > The easiest way would be to store the information directly in your > LDAP and send it back to automx. > > > Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: From smeier at webster.edu Wed Jan 13 23:15:33 2016 From: smeier at webster.edu (Steve Meier) Date: Wed, 13 Jan 2016 22:15:33 +0000 Subject: multiple section_filters Message-ID: Can someone tell me if this is correct? It seems like the first filter in the section_filter list is being applied no matter what.. [webster.edu] backend = filter section_filter = o365, wumail wumail = /root/getMailConfig.py "%u" | egrep "@\w+\.webster\.edu$" o365 = /root/getMailConfig.py "%u" | egrep "@websteru\.onmicrosoft\.com$" [wumail] backend = script script = /usr/bin/python /root/getMailConfig.py "%u" result_attrs = wuserver action = settings sign_mobileconfig = yes sign_cert = /etc/nginx/server.crt sign_key = /etc/nginx/server.key smtp = yes smtp_server = smtp.webster.edu smtp_port = 587 smtp_encryption = ssl smtp_auth = plaintext smtp_refresh_ttl = 6 smtp_default = yes imap = yes imap_server = ${wuserver} imap_port = 995 imap_encryption = ssl imap_auth = plaintext imap_refresh_ttl = 6 pop = no pop_server = ${wuserver} pop_port = 993 pop_encryption = ssl pop_auth = plaintext pop_refresh_ttl = 6 [o365] backend = file action = settings autodiscover = /usr/share/automx/o365.xml I have checked my getMailConfig script and it is behaving properly.. [1149] root at testVM:/usr/share/automx# /root/getMailConfig.py "test4" | egrep "@\w+\.webster\.edu$" [1150] root at testVM:/usr/share/automx# /root/getMailConfig.py "test4" | egrep "@websteru\.onmicrosoft\.com$" test4 at websteru.onmicrosoft.com [1151] root at testVM:/usr/share/automx# /root/getMailConfig.py "test3" | egrep "@\w+\.webster\.edu$" test3 at bailey.webster.edu [1152] root at testVM:/usr/share/automx# /root/getMailConfig.py "test3" | egrep "@websteru\.onmicrosoft\.com$" When o365 is first in section_filter, it is applied for both test4 and test3. When wumail is first, it is being applied for both. I am trying to follow information supplied here: https://github.com/sys4/automx/blob/master/doc/txt/automx.conf.5.txt https://github.com/sys4/automx/blob/master/src/conf/automx.conf.example-comp lex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: From smeier at webster.edu Fri Jan 15 03:06:52 2016 From: smeier at webster.edu (Steve Meier) Date: Fri, 15 Jan 2016 02:06:52 +0000 Subject: multiple section_filters Message-ID: Well I am pleased to report I have gotten it working as required for our environment. After taking a closer look in config.py, and adding some additional debugging lines to gain a better understanding of the processing of the section filters, I adjusted my script to work the way automx needed. Here is what I found happening- 2016-01-14 16:11:31,625 DEBUG: *** Going to process the filter list- ['o365', 'wumail'] 2016-01-14 16:11:31,626 DEBUG: *** Going to run filter- o365 2016-01-14 16:11:31,626 DEBUG: *** Going to run filter- /root/getMailConfig.py ['/root/getMailConfig.py', 'test2', '|', 'egrep', '@websteru\\.onmicrosoft\\.com$'] 2016-01-14 16:11:31,668 DEBUG: Email address from filter: test2 at auden.webster.edu 2016-01-14 16:11:31,669 DEBUG: ***Current search domain is- webster.edu 2016-01-14 16:11:31,669 DEBUG: ***New search domain is- o365 The result of this filter was not correct because test2 at auden.webster.edu should have never been returned from the filter. In particular it is clear the pipe and shell commands are not being parsed as such.. perhaps with proper quoting and/or escaping this could be made to work, but in my case it is simple to modify my python script rather than try to figure that out. Here is the result after modifying my script to accept specific test cases- 2016-01-14 16:20:19,228 DEBUG: *** Going to process the filter list- ['o365', 'wumail', 'other'] 2016-01-14 16:20:19,229 DEBUG: *** Going to run filter- o365 2016-01-14 16:20:19,229 DEBUG: *** Going to run filter- /root/getMailConfig.py ['/root/getMailConfig.py', 'O365', 'test2'] 2016-01-14 16:20:19,289 DEBUG: *** Going to run filter- wumail 2016-01-14 16:20:19,289 DEBUG: *** Going to run filter- /root/getMailConfig.py ['/root/getMailConfig.py', 'WUMAIL', 'test2'] 2016-01-14 16:20:19,332 DEBUG: Email address from filter: test2 at auden.webster.edu 2016-01-14 16:20:19,332 DEBUG: ***Current search domain is- webster.edu 2016-01-14 16:20:19,332 DEBUG: ***New search domain is- wumail As you can see I modified my script so that I can make a simple call from automx without the need for any "shell-like" commands. Funny thing is, originally I thought of doing this, but I chose to more closely follow the example instead. Here's what it ends up looking like for me in automx.conf: [webster.edu] backend = filter section_filter = o365, wumail, other wumail = /root/getMailConfig.py WUMAIL "%u" o365 = /root/getMailConfig.py O365 "%u" other = /root/getMailConfig.py OTHER "%u" [wumail] backend = script script = /usr/bin/python /root/getMailConfig.py WUMAIL "%u" result_attrs = wuserver action = settings smtp = yes smtp_server = smtp.webster.edu smtp_port = 587 smtp_encryption = ssl smtp_auth = plaintext smtp_refresh_ttl = 6 smtp_default = yes imap = yes imap_server = ${wuserver} imap_port = 995 imap_encryption = ssl imap_auth = plaintext imap_refresh_ttl = 6 [o365] backend = file action = settings autodiscover = /usr/share/automx/o365.xml [other] #TODO- gracefully not do things for "OTHER" Works great! Now it can fully handle the three use-cases required for our environment and we will be able to prepare to build for production implementation. Thanks for the help and support guys! -SteveM Steve Meier Enterprise Architect - Middleware Services Webster University 470 E. Lockwood Avenue St. Louis, MO 63119 smeier at webster.edu / +1-314-246-8604 From: Steve Meier Sent: Wednesday, January 13, 2016 16:16 To: automx-users at sys4.de Subject: multiple section_filters Can someone tell me if this is correct? It seems like the first filter in the section_filter list is being applied no matter what.. [webster.edu] backend = filter section_filter = o365, wumail wumail = /root/getMailConfig.py "%u" | egrep "@\w+\.webster\.edu$" o365 = /root/getMailConfig.py "%u" | egrep "@websteru\.onmicrosoft\.com$" [wumail] backend = script script = /usr/bin/python /root/getMailConfig.py "%u" result_attrs = wuserver action = settings sign_mobileconfig = yes sign_cert = /etc/nginx/server.crt sign_key = /etc/nginx/server.key smtp = yes smtp_server = smtp.webster.edu smtp_port = 587 smtp_encryption = ssl smtp_auth = plaintext smtp_refresh_ttl = 6 smtp_default = yes imap = yes imap_server = ${wuserver} imap_port = 995 imap_encryption = ssl imap_auth = plaintext imap_refresh_ttl = 6 pop = no pop_server = ${wuserver} pop_port = 993 pop_encryption = ssl pop_auth = plaintext pop_refresh_ttl = 6 [o365] backend = file action = settings autodiscover = /usr/share/automx/o365.xml I have checked my getMailConfig script and it is behaving properly.. [1149] root at testVM:/usr/share/automx# /root/getMailConfig.py "test4" | egrep "@\w+\.webster\.edu$" [1150] root at testVM:/usr/share/automx# /root/getMailConfig.py "test4" | egrep "@websteru\.onmicrosoft\.com$" test4 at websteru.onmicrosoft.com [1151] root at testVM:/usr/share/automx# /root/getMailConfig.py "test3" | egrep "@\w+\.webster\.edu$" test3 at bailey.webster.edu [1152] root at testVM:/usr/share/automx# /root/getMailConfig.py "test3" | egrep "@websteru\.onmicrosoft\.com$" When o365 is first in section_filter, it is applied for both test4 and test3. When wumail is first, it is being applied for both. I am trying to follow information supplied here: https://github.com/sys4/automx/blob/master/doc/txt/automx.conf.5.txt https://github.com/sys4/automx/blob/master/src/conf/automx.conf.example-comp lex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19271 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4827 bytes Desc: not available URL: