Custom logic

Patrick Ben Koetter p at sys4.de
Wed Jan 6 00:05:19 CET 2016


* Steve Meier <smeier at webster.edu>:
> 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 <smeier at webster.edu>:
> > 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" <p at sys4.de<mailto:p at sys4.de>> 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 <smeier at webster.edu>:
> > > 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" <smeier at webster.edu<mailto:smeier at webster.edu>> 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
 


More information about the automx-users mailing list