Custom logic

[Michael Menge]

Hi,


Quoting Patrick Ben Koetter <p at sys4.de>:

> 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?
>

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"  
>> <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



--------------------------------------------------------------------------------
M.Menge                                Tel.: (49) 7071/29-70316
Universität Tübingen                   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung          mail:  
michael.menge at zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen