Bugzilla

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. He specifically did *not* want this config to be used. We specifically added the username field to fix such configs and make them work, on specific request of this admin. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added this to the software, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the *standard configuration* for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. He specifically did *not* want this config to be used. We specifically added the username field to fix such configs and make them work, on specific request of this admin. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added this to the software, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the *standard configuration* for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

> http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. That's the old config *before* our username field fix. He specifically did *not* want this config to be used. We specifically added the username field to fix such configs and make them work, on specific request of this admin. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added this to the software, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the *standard configuration* for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

> http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. That's the old config *before* our username field fix. He specifically did *not* want this config to be used. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added the username field, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the *standard configuration* for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

> http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. That's the old config *before* our username field fix. He specifically did *not* want this config to be used. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added the username field, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-Domain-login style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the *standard configuration* for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

> http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. That's the old config *before* our username field fix. He specifically did *not* want this config to be used. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added the username field, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-Domain-login style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the **standard configuration** for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** working configs. It will destroy the specific fixes we made for these Exchange servers.

Here's what you're missing: To get the correct config for an Exchange server, you MUST enter the correct username and password. It won't work otherwise.

Any other configs that we might find may not be valid, and may not work.

> http://autoconfig.medma.uni-heidelberg.de/mail/config-v1.1.xml

I've actually personally worked with the admin on that domain. That's the old config *before* our username field fix. He specifically did *not* want this config to be used. What Magnus demands here is in direct contradiction to the expressed wish of the admins of this domain. In this case, I happen to be certain, because I personally spoke to them.

We added the username field, because this is not an edge case, but a very common case for on-premise Exchange server to require Windows-Domain-login style usernames, and to require a login before we can find the correct config. In fact, that is - as far as I know - the **standard configuration** for on-premise Exchange.

That's why I am 100% certain that this bug is not only INVALID as stated, but that Magnus' requests here and in various related bugs (e.g. bug 1593122) will actually **break** currently working configs. It will destroy the specific fixes we made for these Exchange servers.