[BlueOnyx:27159] Re: IMAP with Outllok

[Michael Stauber]

Hi Taco,

> That is an interesting suggestion, I will have a look at it on my sandbox.

Larry's suggestion is probably the way to go:

/etc/dovecot/conf.d/10-auth.conf

auth_username_format = %n

This allows both plain usernames and full email addresses. PROVIDED the 
part left of the @ is a valid username and NOT an alias.

 > But this would likely cause e-mail sending problems….

Probably not. Dovecot is just for POP3/IMAP and the above changes don't 
affect email sending.

OTOH: Postfix's SMTP-Auth (as we use it) uses SASL as authentication 
backend. As is we use Cyrus SASL, but could switch it to use Dovecot as 
SASL backend if need be. But that would require that Dovecot is always 
on or SMTP-Auth won't work. That's why I defaulted it to use Cyrus-SASL 
instead as it gives us that extra flexibility to optionally have Dovecot 
disabled.

I just checked on a 5211R with "swaks" (from a Debian) how our current 
Postfix handles username/password and email-addy/password logins:

swaks --to user at example.com --from user at example.com --server 
smtp.example.com --auth-user username --auth-password password --auth

Email-addy/password:
swaks --to user at example.com --from user at example.com --server 
smtp.example.com --auth-user user at example.com --auth-password password 
--auth

Postfix actually already supports both. Even WITH Cyrus SASL as backend.

So on *that* front SMTP-Auth (if Postfix is the MTA) we are good and 
already accept both email-address and username.

But yeah: The Dovecot modification would require some additional testing 
to make sure it works and doesn't cause ill side effects.

The thing here is: That way we can perhaps indeed get SMTP-Auth and 
POP3/IMAP logins with username AND email-address working. But NOT with 
email-aliases. Because just stripping off the @ of an email address and 
anything on the righthand side of that would leave just the alias and 
that in itself is not a valid username. Or it may belong to an entirely 
different user.

If we don't also allow the email alias, it'll confuse the heck out of 
some people.

And in order to also allow the aliases things would get REALLY 
complicated. Like we'd need an SQL database with a table that maps all 
usernames to their email-addresses AND aliases and then use SQL backed 
authentication in Dovecot.

> Michael, did you ever look at the serverside“autoconfiguration” script possibility?

I looked at it and did a static prototype where the credential page 
wasn't (yet) auto-generated, but a hand crafted file. Just to see how 
and if it works.

On one hand you'd need DNS SRV records:

_imap._tcp.example.com.       IN SRV 0 1 143 mail.example.com.
_imaps._tcp.example.com.      IN SRV 0 1 993 mail.example.com.
_submission._tcp.example.com. IN SRV 0 1 587 mail.example.com.

And then a CNAME record:

autodiscover.example.com.     IN CNAME mail.example.com.

That would prompt email clients with autodiscovery to check this URL for 
the XML file with the autodiscovery config:

https://autodiscover.example.com/autodiscover/autodiscover.xml

The idea being that if we integrate this, the GUI would dynamically 
create the autodiscover.xml for us and present it. Which may require 
some redirects from HTTP/HTTPs on Apache to 
https://<server>:81/autodiscovery/autodiscover.xml

And that file would then need to look like this:

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover 
xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
   <Response>
     <Account>
       <AccountType>email</AccountType>
       <Action>settings</Action>
       <Protocol>
         <Type>IMAP</Type>
         <Server>mail.example.com</Server>
         <Port>993</Port>
         <LoginName>username</LoginName>
         <SSL>true</SSL>
       </Protocol>
       <Protocol>
         <Type>SMTP</Type>
         <Server>mail.example.com</Server>
         <Port>587</Port>
         <LoginName>username</LoginName>
         <SSL>true</SSL>
       </Protocol>
     </Account>
   </Response>
</Autodiscover>


Now here is the stupid part of the whole setup:

The typical autodiscover.xml has username and password in it. Naturally 
we can't and won't fill those in, because it would be stupid to expose 
valid usernames. And as far as the passwords go? We don't know them 
(only the hash) and even if we did? We wouldn't expose them. The fact 
that the specifications for this setup have provisions for exposing the 
passwords in them already make it obvious that it is a brain-dead 
Mickey-Mouse-Software idea that can't be ridiculed enough.

Anyway: If I omit the username/password fields in the XML, the email 
client will still auto-configure IMAP and SMTP and the user has to fill 
in the blanks such as username and password.

While that's fine it won't get us around the username vs. email-address 
issue. When I tried it on a borrowed laptop which had Outlook it still 
insisted that only the email address was a valid username.

-- 
With best regards

Michael Stauber