dovecot - Apr 2021 - Sv: What imap ssl/auth settings work best with MS Outlook?

On 29 Apr 2021, at 19:48, Adi Pircalabu <adi at ddns.com.au>
wrote:
> <rant importance=low noise_level=medium>
> 
> Fact: Exchange (especially hosted) is 2010-ish, Office365 is the buzzword
these days. Microsoft have been trying their best for quite some time now to
cripple the IMAP support in Outlook as much as they can so that the email users
will move their email business with o365 which - surprise surprise! - is soooo
easy to autodiscover, autoconfigure, autothis, autothat. It's all about
integrated services run by few well known powerful monopolies and it's only
gonna get worse.
As an example of how MSFT (and others) make configuring real emails accounts
more difficult:

When you enter your email address, it would be TRIVIAL to check the MX records
for the domain and fill those in for the SMTP and IMAP servers, allowing users
to more easily add (if needed) the domain prefix.

No one does this.

Not a big thing, of course, but a silly omission that is best explained by
"Nah, if they are going to use real servers, let's not make it any
easier."
> </rant>

-- 
'You know what the greatest tragedy is in the whole world?' said
	Ginger, not paying him the least attention. 'It's all the people
	who never find out what it is they really want to do or what it
	is they're really good at. It's all the sons who become
	blacksmiths because their fathers were blacksmiths. It's all the
	people who could be really fantastic flute players who grow old
	and die without ever seeing a musical instrument, so they become
	bad ploughmen instead. It's all the people with talents who never
	even find out. Maybe they are never born in a time when it is
	possible to find out.'

But whats specified for MX isn't neccessarly the endpoint endusers should
use as their incoming/outgoing servers, especially if the MX is routed
through a external spamfiltering service.

-----Ursprungligt meddelande-----
Fr?n: dovecot-bounces at dovecot.org <dovecot-bounces at dovecot.org> F?r
@lbutlr
Skickat: den 30 april 2021 09:14
Till: dovecot mailing list <dovecot at dovecot.org>
?mne: Re: What imap ssl/auth settings work best with MS Outlook?

On 29 Apr 2021, at 19:48, Adi Pircalabu <adi at ddns.com.au>
wrote:
> <rant importance=low noise_level=medium>
> 
> Fact: Exchange (especially hosted) is 2010-ish, Office365 is the buzzword
these days. Microsoft have been trying their best for quite some time now to
cripple the IMAP support in Outlook as much as they can so that the email
users will move their email business with o365 which - surprise surprise! -
is soooo easy to autodiscover, autoconfigure, autothis, autothat. It's all
about integrated services run by few well known powerful monopolies and it's
only gonna get worse.

As an example of how MSFT (and others) make configuring real emails accounts
more difficult:

When you enter your email address, it would be TRIVIAL to check the MX
records for the domain and fill those in for the SMTP and IMAP servers,
allowing users to more easily add (if needed) the domain prefix.

No one does this.

Not a big thing, of course, but a silly omission that is best explained by
"Nah, if they are going to use real servers, let's not make it any
easier."
> </rant>

-- 
'You know what the greatest tragedy is in the whole world?' said
	Ginger, not paying him the least attention. 'It's all the people
	who never find out what it is they really want to do or what it
	is they're really good at. It's all the sons who become
	blacksmiths because their fathers were blacksmiths. It's all the
	people who could be really fantastic flute players who grow old
	and die without ever seeing a musical instrument, so they become
	bad ploughmen instead. It's all the people with talents who never
	even find out. Maybe they are never born in a time when it is
	possible to find out.'


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5715 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20210430/77f623a8/attachment-0001.p7s>

Citeren "@lbutlr" <kremels at kreme.com>:
> When you enter your email address, it would be TRIVIAL to check the  
> MX records for the domain and fill those in for the SMTP and IMAP  
> servers, allowing users to more easily add (if needed) the domain  
> prefix.
>
> No one does this.
Rightfully so. There is absolutely no guarantee that the server on the  
inbound (MX) record also handles outbound and/or IMAP. In many cases,  
these will be different systems.

On 30/04/2021 08:13, @lbutlr wrote:
> When you enter your email address, it would be TRIVIAL to check the MX
records for the domain and fill those in for the SMTP and IMAP servers, allowing
users to more easily add (if needed) the domain prefix.
Better to use DNS SVR records than guess from MX or domain.  I provide 
email SVRs but does any mail client use them?

https://tools.ietf.org/html/rfc6186


There is config-v1.1.xml, again I do not know which clients use, hence 
what I should provide, maybe I carry on providing as many methods as I can.

On 2021-04-30 09:13, @lbutlr wrote:
> When you enter your email address, it would be TRIVIAL to check the MX
> records for the domain and fill those in for the SMTP and IMAP
> servers, allowing users to more easily add (if needed) the domain
> prefix.
checking mx is simple, but it might not be the right server for imap, 
smtps, submission, this data would be better to check mx domain, and 
then use the mx domain to find srv ports used one this main domain, to 
find what server hosts is for imap, imaps, pop3, pop3s, smtps, 
submission, all that is custommer only ports, and plenty of vps hosters 
abuse this from ther mta setups
> No one does this.
automx2 exists on github trying to be better world, but it needs ssl 
certs for all maildomains, with is imho more complicated then using srv 
dns

this would be more simple for the dns hoster to have all this then add 
all this to hosted domains
> Not a big thing, of course, but a silly omission that is best
> explained by "Nah, if they are going to use real servers, let's
not
> make it any easier."
agree, take my hat off as a small esp