Technische Infos/E-Mail/FAQ zu Änderungen an Shared Mail: Unterschied zwischen den Versionen

Aus Technische Infos - info.noris.net
Zur Navigation springen Zur Suche springen
(adds English Version)
Zeile 1: Zeile 1:
'''Please see below for the English version'''
Diese Seite soll einige Detailfragen klären zu den Themen: Abschaltung von POP-before-SMTP/SMTP-after-POP, Abschaltung von IMAP und POP (ohne "S", also nicht IMAPS/POP3S) und PlainSMTP-Deprecation
Diese Seite soll einige Detailfragen klären zu den Themen: Abschaltung von POP-before-SMTP/SMTP-after-POP, Abschaltung von IMAP und POP (ohne "S", also nicht IMAPS/POP3S) und PlainSMTP-Deprecation


Zeile 55: Zeile 57:
*POP3S = TLS-on-connect -> POP3
*POP3S = TLS-on-connect -> POP3
*verschlüsseltes POP3 = POP3->STLS
*verschlüsseltes POP3 = POP3->STLS
= English Version =
This page should clarify some detailed questions to the topics: Disable POP-before-SMTP/SMTP-after-POP, disable IMAP and POP (without "S", so not IMAPS/POP3S) and PlainSMTP-Deprecation
If your question is not answered here, please contact us at support@noris.de.
== Disable POP-before-SMTP/SMTP-after-POP ==
=== What is POP-before-SMTP/SMTP-after-POP and why was it used? ===
POP-before-SMTP or SMTP-after-POP is a mechanism that is used to perform indirect authentication for sending emails. It authenticates itself indirectly for sending emails by retrieving emails. In the past, this mechanism was essential for authentication, but today there is a better alternative (SMTP AUTH), which is usually supported by current software. Using the example:
User x retrieves its mails from the incoming mail server. The incoming mail server informs the outgoing mail server that User x has successfully authenticated with a certain IP. The outgoing mail server then remembers for a while if someone wants to send mails with this IP address.
=== Why is that bad? ===
Because the outgoing mail server must trust the IP and knows nothing about the sender, it cannot be ensured that always the same user is behind this IP. Usually multiple users share a public IP behind one Internet connection (this technology is called (S)NAT). This effect is even greater when DualStackLite or CarrierGrade NAT is put into consideration. Here, several customers of an ISP share an IPv4 address. So it can happen that with the retrieval of emails by one user several other unknown users get the possibility to send emails via the outgoing mail server for some time. This also applies to users who authenticate themselves correctly when sending emails, since this information cannot be obtained when retrieving emails from the outgoing mail server. What can happen with an example:
The secretary regularly retrieves his mails with his mail client and uses them to authenticate the IP with which he and his boss go online and send mails. The secretary now goes on vacation. His boss suddenly can't send any more mails because she hasn't configured her mail client to retrieve her email regularly and doesn't authenticate herself at the outgoing mail server.
=== What is SMTP AUTH? ===
SMTP AUTH is an extension of the SMTP protocol (more precisely ESMTP), which makes it possible to log on with user credentials. In most cases you don't need to know about this, your mail client takes care of the details as long as it is configured correctly.
=== How do I know if I have set up my client correctly? ===
Every mail client is a bit different. In your mailbox settings of your client, check whether you have checked the box for authentication when sending mail via SMTP and whether you have entered the correct user name and password. Many clients also have a button to test the correct configuration. Please also make sure that you encrypt the connection when sending, otherwise no authentication will be allowed.
Here you will find details on what to consider when configuring your client (currently only in German with reference picture): [[Technische_Infos/E-Mail/Postfach]]
== Disable IMAP and POP ==
=== What is it and what is it used for? ===
With the IMAP and POP3 protocols you can retrieve your mails from the incoming mail server. Both protocols are also available in an encrypted version IMAPS and POP3S. We will only disable the unencrypted protocol versions. While IMAP uses port 143 and POP3 uses port 110, the encrypted protocols use port 993 for IMAPS and port 995 for POP3S.
=== How do I know if I am using the correct protocol? ===
Go to the settings for the outgoing mail server and verify that the correct protocol and port have been selected. It is also important that the SSL/TLS option is active. More details can be found here (currently only in German with reference picture): [[Technische_Infos/E-Mail/Postfach]]
=== I configured smtp.noris.net and imap.noris.net. Is that wrong? ===
No, both addresses are aliases (CNAMES) for mail.noris.net.
=== When's that gonna happen? ===
Currently, we are only announcing that we would like to stop accepting and sending unencrypted emails. Unfortunately, there is still a part of mails that is not transmitted encrypted because the other side does not set up encryption.
=== Doesn't noris already encrypt? ===
As far as this is supported by the other side, all mails sent and received via our shared infrastructure are encrypted. If this does not work, a fallback to unencrypted / plain is foreseen with SMTP. We only prevent this fallback if this is expressly requested by our customers.
Why don't we want this anymore?
If mails are sent unencrypted, they are also transmitted to the Internet outside our infrastructure. Therefore, there is the possibility that a man-in-the-middle can record and read packets.
=== Does this count for all mails? ===
In principle, we always encrypt the transport of mails as far as this is possible. SMTP provides a fallback to plain text, this is the usual procedure on the Internet. For mails that leave our network, we want to prevent this completely in the future.
=== What about content encryption (S/MIME and PGP) and what is the difference to transport encryption?===
Transport encryption involves communication between two servers. It is about preventing mails from being read between the servers. Content encryption means that the mail is not available in plain text on the servers either. This can be guaranteed by PGP or S/MIME, for example. This is about transport encryption, not content encryption. Since headers and other meta information remain readable even with encrypted content, transport encryption should also be used if the mails are encrypted.
=== What do I have to do if I want to send mails to noris servers or receive mails from noris servers?===
Make sure that your mail server (sending or receiving) always tries to encrypt the transport route with STARTTLS. You should do this now, even if we still offer the possibility to send mails in plain text for a while.
=== Which TLS versions are supported? ===
Currently we support TLS1.1 and upwards TLS 1.3 will be added in the future, but this is not yet implemented.
== Miscellaneous ==
=== What is the difference between SSL, TLS, STARTTLS and STLS? ===
All four technologies are used for encryption when retrieving or sending emails.
TLS is the new name for SSL (SSL 3.0 is followed by TLS 1.0).
SSL/TLS are also used to retrieve web pages (via HTTPS); here HTTP is spoken in a TLS tunnel, i.e. a TLS-encrypted connection is first established and after successful establishment HTTP is spoken.
When sending mail, the encryption is usually set up differently. First a connection is established in which SMTP is spoken, then the connection is upgraded to an encrypted connection by the command STARTTLS, here too the underlying technology is TLS. The sequence is of decisive importance here. In the first case TLS->HTTP in the second SMTP->STARTTLS.
But there is also the possibility to use TLS-on-connect for mail delivery. This means that the TLS tunnel is built first and SMTP communication takes place in it; port 465 (SUBMISSONS RFC8314) is used for this. This is usually not used for server-to-server connections but for client-to-server connections. mail.noris.net also offers this option.
STLS is the STARTTLS equivalent for IMAP or POP3. However, it is rather unusual in practice and IMAPS and POP3S are used directly instead. Simplified:
*IMAPS = TLS-on-connect -> IMAP
*encrypted IMAP = IMAP->STLS
*POP3S = TLS-on-connect -> POP3
*encrypted POP3 = POP3->STLS

Version vom 5. Juni 2019, 10:54 Uhr

Please see below for the English version

Diese Seite soll einige Detailfragen klären zu den Themen: Abschaltung von POP-before-SMTP/SMTP-after-POP, Abschaltung von IMAP und POP (ohne "S", also nicht IMAPS/POP3S) und PlainSMTP-Deprecation

Sollte Ihre Frage hier nicht beantwortet werden, schreiben Sie uns an support@noris.de.

Abschaltung von POP-before-SMTP/SMTP-after-POP

Was ist POP-before-SMTP/SMTP-after-POP und warum wurde es eingesetzt?

Bei POP-before-SMTP beziehungsweise SMTP-after-POP handelt es sich um einen Mechanismus, der dafür eingesetzt wird, eine indirekte Authentifizierung für den E-Mail-Versand durchzuführen. Hierbei authentifiziert man sich indirekt für das Senden von E-Mails durch das Abrufen von E-Mails. Früher war dieser Mechanismus essenziell für das Authentifizierung, heute gibt es dafür eine bessere Alternative (SMTP AUTH), die in der Regel von aktueller Software unterstützt wird. Am Beispiel: User x ruft seine Mails vom Posteingangsserver ab. Der Posteingangsserver teilt dem Postausgangsserver mit, dass sich User x mit einer bestimmten IP erfolgreich authentifiziert hat. Der Postausgangsserver erinnert sich dann eine Zeit lang daran, wenn jemand mit dieser IP Mails versenden möchte.

Warum ist das schlecht?

Dadurch dass der Postausgangsserver der IP vertrauen muss und nichts über den Sender weiß, kann nicht sichergestellt werden, dass hinter dieser IP derselbe Nutzer steckt. So teilen sich in der Regel hinter einem Internetanschluss alle Nutzer eine gemeinsame öffentliche IP (Stichwort NAT). Dieser Effekt wird noch erhöht, wenn es zu DualStackLite bzw. CarrierGrade-NAT kommt. Hier teilen sich mehrere Kunden eines ISPs eine IPv4-Adresse. So kann es passieren, dass mit dem Abrufen von E-Mails mehrere andere Unbekannte für einige Zeit die Möglichkeit bekommen, über den Postausgangsserver Mails zu versenden. Dies betrifft dazu noch auch Nutzer, die sich beim E-Mail-Versand korrekt authentifizieren, da beim Abruf von E-Mails beim Postausgangsserver diese Information nicht vorliegen kann. Was dabei passieren kann an einem Beispiel: Der Sekretär ruft mit Ihrem Mail-Client regelmäßig seine Mails ab und authentifiziert damit die IP, mit der er und seine Chefin ins Internet gehen und auch Mails versenden. Der Sekretär geht nun in den Urlaub. Seine Chefin kann plötzlich keine Mails mehr versenden, da Sie ihren Mail-Client nicht dazu konfiguriert hat regelmäßig Ihre E-Mail abzurufen und sich auch nicht beim Versand am Postausgangsserver authentifiziert.

Was ist SMTP AUTH?

SMTP AUTH ist eine Erweiterung des SMTP-Protokolls (genauer ESMTP), die es ermöglicht sich mit User-Credentials anzumelden. In dem meisten Fällen müssen Sie hierüber nicht genau Bescheid wissen, Ihr Mail-Client kümmert sich um die Details, solange dieser korrekt eingestellt ist.

Woher weiß ich, ob ich meinen Client richtig eingestellt habe?

Jeder Mail-Client ist hier etwas anders. Überprüfen Sie in Ihrem Postfacheinstellungen Ihres Clients, ob Sie beim Mail-Versand via SMTP den Haken für die Authentifizieren beim Versand gestzt haben und den korrekten Benutzernamen und das korrekte Passwort angegeben haben. Viele Clients haben auch einen Button, um die korrekte Konfiguration zu Testen. Achten Sie bitte auch darauf, dass Sie beim Versenden die Verbindung verschlüsseln, da sonst keine Authentifizierung erlaubt wird. Sie finden hier Details, was beim konfigurieren Ihres Clients zu beachten ist: Technische_Infos/E-Mail/Postfach


Abschaltung von IMAP und POP

Was ist das und wofür wird es verwendet?

Mit den Protokollen IMAP und POP3 können Sie Ihre Mails vom Posteingangsserver abholen. Beide Protokolle gibt es auch in einer verschlüsselten Variante IMAPS und POP3S. Wir werden nur die unverschlüsselten Protokollversionen abschalten. Während IMAP Port 143 und POP3 den Port 110 verwendet, verwenden die verschlüsselten Protokolle auf Port 993 für IMAPS und auf Port 995 für POP3S.

Woher weiß ich, ob ich das richtige Protokoll verwende?

Gehen Sie in die Einstellungen für den Postausgangs-Server und überprüfen Sie, dass das richtige Protokoll und der richtige Port ausgewählt wurden. Ebenso ist es wichtig, dass die Option "SSL/TLS" aktiv ist. Genauere Details finden Sie hier: Technische_Infos/E-Mail/Postfach

Ich habe hier smtp.noris.net und imap.noris.net stehen. Ist das falsch?

Nein, beide Adressen sind Aliase (CNAMES) von mail.noris.net.


PlainSMTP-Deprecation

Wann passiert das?

Aktuell kündigen wir nur an, dass wir gerne keine E-Mails mehr unverschlüsselt annehmen und versenden möchten. Es gibt leider immer noch einen Teil von Mails, der nicht verschlüsselt übertragen wird, weil von der Gegenseite keine Verschlüsselung aufgebaut wird.

Verschlüsselt noris denn nicht schon?

So fern dies von der Gegenseite unterstützt/gewünscht, werden alle Mails, die über unsere Shared-Infrastruktur versendet und empfangen werden verschlüsselt. Funktioniert dies nicht, ist bei SMTP ein Fallback auf unverschlüsselt/plain vorgsehen. Diesen Fallback verhindern wir nur, wenn dies von unseren Kunden ausdrücklich gewünscht ist.

Warum wollen wir das nicht mehr?

Wenn Mails unverschlüsselt versendet werden, werden diese auch ins Internet außerhalb unserer Infrastruktur übermittelt. Daher besteht die Möglichkeit, dass ein Man-in-the-Middle, de Pakete mitschneiden und lesen kann.

Zählt dies für alle Mails?

Prinzipiell verschlüsseln wir den Transport von Mails immer, sofern dies möglich ist. SMTP sieht hier einen Fallback auf Klartext vor, dies ist das übliche Vorgehen im Internet. Für Mails, die unser Netz verlassen, wollen wir dies in Zukunft komplett unterbinden.

Was ist mit Inhaltsverschlüsselung (S/MIME und PGP) und was ist der Unterschied zur Transportverschlüsselung?

Bei der Transportverschlüsselung geht es um die Kommunikation zwischen jeweils zwei Servern. Es geht darum zu verhindern, dass Mails zwischen den Servern gelesen werden können. Bei der Inhaltverschlüsselung geht es darum, dass auch auf den Servern die Mail nicht in Klartext vorliegt, dies ässt sich beispielsweise durch PGP oder S/MIME gewährleisten. Hier geht es um die Transportverschlüsselung, nicht um die Inhaltsverschlüsselung. Da auch bei verschlüsseltem Inhalt immer noch Header und andere Meta-Informationen lesbar bleiben, sollte auch dann transportverschlüsselt werden, wenn die Mails inhaltsverschlüsselt ist.

Was muss ich tun, wenn ich an noris-Server Mails schicken oder von noris-Servern Mails bekommen möchte?

Stellen Sie sicher, dass Ihr Mail-Server (sendend oder empfangend) stets versucht den Transportweg mit STARTTLS zu verschlüsseln. Dies sollten Sie auch jetzt schon tun, auch wenn wir noch eine Weile die Möglichkeit bieten, Mails im Klartext zu versenenden.

Welche TLS-Versionen werden unterstützt?

Aktuell unterstützen wir TLS1.1 und aufwärts in Zukunft wird auch TLS 1.3 dazukommen, dies ist jedoch noch nicht implementiert.


Verschiedenes

Was ist der Unterschied zwischen SSL, TLS, STARTTLS und STLS

Alle vier Technologien werden beim Abruf oder beim Versenden von Mails zur Verschlüsselung eingesetzt.
TLS ist die neue Bezeichnung für SSL (nach SSL 3.0 kommt TLS 1.0).
SSL/TLS werden unter anderem auch beim Abruf von Webseiten verwendet (via HTTPS); hier wird HTTP in einem TLS-Tunnel gesprochen, d.h. es wird erst eine mit TLS verschlüsselte Verbindung aufgebaut und nach erfolgreichem Aufbau HTTP gesprochen.
Beim Mail-Versand wird die Verschlüsselung in der Regel anders aufgebaut. Zunächst wird eine Verbindung aufgebaut in der SMTP gesprochen wird, dann wird durch den Befehl STARTTLS die Verbindung aufgewertet zu einer verschlüsselten Verbindung, auch hier ist die zugrunde liegende Technologie TLS. Die Reihenfolge ist hier von entscheidender Rolle. Im ersten Fall TLS->HTTP im zweiten SMTP->STARTTLS.
Es gibt aber auch bei Mail die Möglichkeit für das einliefern von Mails TLS-on-connect zu verwenden. Das bedeutet, dass hier erst der TLS-Tunnel aufgebaut wird und in diesem die SMTP-Kommunikation stattfindet; hierfür ist der Port 465 (SUBMISSONS RFC8314). Dies wird üblicherweise nicht für Server-zu-Server-Verbindungen genutzt sondern von Client-zu-Server-Verbindungen. Auch mail.noris.net bietet diese Möglichkeit.
Bei STLS handelt es sich um das STARTTLS-Äquivalent für IMAP bzw POP3. Ist aber in der Praxis eher unüblich und es werden stattdessen direkt IMAPS und POP3S verwendet. Vereinfacht:

  • IMAPS = TLS-on-connect -> IMAP
  • verschlüsseltes IMAP = IMAP->STLS
  • POP3S = TLS-on-connect -> POP3
  • verschlüsseltes POP3 = POP3->STLS


English Version

This page should clarify some detailed questions to the topics: Disable POP-before-SMTP/SMTP-after-POP, disable IMAP and POP (without "S", so not IMAPS/POP3S) and PlainSMTP-Deprecation

If your question is not answered here, please contact us at support@noris.de.

Disable POP-before-SMTP/SMTP-after-POP

What is POP-before-SMTP/SMTP-after-POP and why was it used?

POP-before-SMTP or SMTP-after-POP is a mechanism that is used to perform indirect authentication for sending emails. It authenticates itself indirectly for sending emails by retrieving emails. In the past, this mechanism was essential for authentication, but today there is a better alternative (SMTP AUTH), which is usually supported by current software. Using the example: User x retrieves its mails from the incoming mail server. The incoming mail server informs the outgoing mail server that User x has successfully authenticated with a certain IP. The outgoing mail server then remembers for a while if someone wants to send mails with this IP address.

Why is that bad?

Because the outgoing mail server must trust the IP and knows nothing about the sender, it cannot be ensured that always the same user is behind this IP. Usually multiple users share a public IP behind one Internet connection (this technology is called (S)NAT). This effect is even greater when DualStackLite or CarrierGrade NAT is put into consideration. Here, several customers of an ISP share an IPv4 address. So it can happen that with the retrieval of emails by one user several other unknown users get the possibility to send emails via the outgoing mail server for some time. This also applies to users who authenticate themselves correctly when sending emails, since this information cannot be obtained when retrieving emails from the outgoing mail server. What can happen with an example: The secretary regularly retrieves his mails with his mail client and uses them to authenticate the IP with which he and his boss go online and send mails. The secretary now goes on vacation. His boss suddenly can't send any more mails because she hasn't configured her mail client to retrieve her email regularly and doesn't authenticate herself at the outgoing mail server.

What is SMTP AUTH?

SMTP AUTH is an extension of the SMTP protocol (more precisely ESMTP), which makes it possible to log on with user credentials. In most cases you don't need to know about this, your mail client takes care of the details as long as it is configured correctly.

How do I know if I have set up my client correctly?

Every mail client is a bit different. In your mailbox settings of your client, check whether you have checked the box for authentication when sending mail via SMTP and whether you have entered the correct user name and password. Many clients also have a button to test the correct configuration. Please also make sure that you encrypt the connection when sending, otherwise no authentication will be allowed. Here you will find details on what to consider when configuring your client (currently only in German with reference picture): Technische_Infos/E-Mail/Postfach

Disable IMAP and POP

What is it and what is it used for?

With the IMAP and POP3 protocols you can retrieve your mails from the incoming mail server. Both protocols are also available in an encrypted version IMAPS and POP3S. We will only disable the unencrypted protocol versions. While IMAP uses port 143 and POP3 uses port 110, the encrypted protocols use port 993 for IMAPS and port 995 for POP3S.

How do I know if I am using the correct protocol?

Go to the settings for the outgoing mail server and verify that the correct protocol and port have been selected. It is also important that the SSL/TLS option is active. More details can be found here (currently only in German with reference picture): Technische_Infos/E-Mail/Postfach

I configured smtp.noris.net and imap.noris.net. Is that wrong?

No, both addresses are aliases (CNAMES) for mail.noris.net.

When's that gonna happen?

Currently, we are only announcing that we would like to stop accepting and sending unencrypted emails. Unfortunately, there is still a part of mails that is not transmitted encrypted because the other side does not set up encryption.

Doesn't noris already encrypt?

As far as this is supported by the other side, all mails sent and received via our shared infrastructure are encrypted. If this does not work, a fallback to unencrypted / plain is foreseen with SMTP. We only prevent this fallback if this is expressly requested by our customers. Why don't we want this anymore?

If mails are sent unencrypted, they are also transmitted to the Internet outside our infrastructure. Therefore, there is the possibility that a man-in-the-middle can record and read packets.

Does this count for all mails?

In principle, we always encrypt the transport of mails as far as this is possible. SMTP provides a fallback to plain text, this is the usual procedure on the Internet. For mails that leave our network, we want to prevent this completely in the future.

What about content encryption (S/MIME and PGP) and what is the difference to transport encryption?

Transport encryption involves communication between two servers. It is about preventing mails from being read between the servers. Content encryption means that the mail is not available in plain text on the servers either. This can be guaranteed by PGP or S/MIME, for example. This is about transport encryption, not content encryption. Since headers and other meta information remain readable even with encrypted content, transport encryption should also be used if the mails are encrypted.

What do I have to do if I want to send mails to noris servers or receive mails from noris servers?

Make sure that your mail server (sending or receiving) always tries to encrypt the transport route with STARTTLS. You should do this now, even if we still offer the possibility to send mails in plain text for a while.

Which TLS versions are supported?

Currently we support TLS1.1 and upwards TLS 1.3 will be added in the future, but this is not yet implemented.


Miscellaneous

What is the difference between SSL, TLS, STARTTLS and STLS?

All four technologies are used for encryption when retrieving or sending emails. TLS is the new name for SSL (SSL 3.0 is followed by TLS 1.0). SSL/TLS are also used to retrieve web pages (via HTTPS); here HTTP is spoken in a TLS tunnel, i.e. a TLS-encrypted connection is first established and after successful establishment HTTP is spoken. When sending mail, the encryption is usually set up differently. First a connection is established in which SMTP is spoken, then the connection is upgraded to an encrypted connection by the command STARTTLS, here too the underlying technology is TLS. The sequence is of decisive importance here. In the first case TLS->HTTP in the second SMTP->STARTTLS. But there is also the possibility to use TLS-on-connect for mail delivery. This means that the TLS tunnel is built first and SMTP communication takes place in it; port 465 (SUBMISSONS RFC8314) is used for this. This is usually not used for server-to-server connections but for client-to-server connections. mail.noris.net also offers this option. STLS is the STARTTLS equivalent for IMAP or POP3. However, it is rather unusual in practice and IMAPS and POP3S are used directly instead. Simplified:

  • IMAPS = TLS-on-connect -> IMAP
  • encrypted IMAP = IMAP->STLS
  • POP3S = TLS-on-connect -> POP3
  • encrypted POP3 = POP3->STLS