Fehlermeldungen bei Exchange Postfachverschiebungen vermeiden

Es kann Sinn machen beim Verschieben von Postfächern bei einer Exchange Server Migration größere Werte für Mailgrößen anzugeben, damit der Vorgang möglichst reibungslos läuft.

Hier sind die wesentlichen Punkte beschrieben: https://blogs.technet.microsoft.com/sbs/2008/10/28/how-do-i-change-message-size-limits-in-sbs-20082011-standard/

Die wichtigsten Aufrufe hier am Beispiel einer SBS Migration sind:

Set-TransportConfig -MaxReceiveSize 30MB -MaxSendSize 30MB

Set-Sendconnector "Windows SBS Internet Send yourservername" -MaxMessageSize 30MB

Set-ReceiveConnector -Identity "Windows SBS Internet Receive yourservername" -MaxMessageSize 30MB

Um die aktuellen Werte abzufragen verwendet man:

Get-TransportConfig| select max*size

Get-Receiveconnector  | fl Name,MaxMessagesize

Get-Sendconnector  | fl Name,MaxMessageSize

E-Mails mit SSL/TLS-Unterstützung mittels Powershell versenden

Die Powershell Funktion Send-MailMessage https://msdn.microsoft.com/de-de/powershell/reference/5.1/microsoft.powershell.utility/send-mailmessage hat so ihre Tücken und hilft leider nicht, wenn es Probleme beim E-Mailversand gibt. Teilweise reagiert sie auch nicht wie erwartet. In der heutigen Zeit, vor allem wegen der TLS-Pflicht reagiert sie oft zickig in Bezug auf den UseSSL Parameter. Aus diesem Grund hier eine einfache Methode E-Mails mittels TLS per Powershell versenden zu können.

Wer Probleme beim E-Mailversand hat, der schaue sich https://newyear2006.wordpress.com/2015/08/23/probleme-mit-transportverschlsselung-zertifikaten-oder-passwrtern-bei-smtp-servern-mittels-powershell-berprfen/ an, dort wird im Detail beschrieben, wie dieses Skript funktioniert.

Gleichzeitig benutzt diese Routine nicht mehr die Test-NetConnection Funktion, da diese komischerweise nicht mehr den Socket öffnet. Statt dessen wird der benötigte TCP-Socket zu beginn manuell geöffnet. Der Rest sind nur Anpassungen für diese Änderung.

Man muss nur die im ersten Block aufgeführten Parameter eintragen und schon kann die Spammerei losgehen…

Hier der ganze Code:

$smtp = "smtp.web.de"
$smtpPort = 587
$user = "meinewebdeadresse@web.de"
# $userPass kann auch leer gesetzt werden, dann wird nachgefragt
$userPass = "meinPasswort"
$Subject = "Test Betreff"
$Body = "Test Body"
$from = "meinewebdeadresse@web.de"
$to = "meinewebdeadresse@web.de"
$xmailer = "Powershell v1"

$c=New-Object System.Net.Sockets.TcpClient
$c.Connect($smtp, $smtpPort)

# Antwort vom SMTP-Server holen und ausgeben
[byte[]]$buffer= @(0) * $c.Client.Available
$c.Client.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# Begrüßung durchführen
$buffer=[System.Text.Encoding]::ASCII.GetBytes("EHLO $Env:Computername`r`n")
$c.Client.Send($buffer)
Sleep -Seconds 1

# Antwort vom SMTP-Server holen
[byte[]]$buffer= @(0) * $c.Client.Available
$c.Client.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# STARTTLS-Anfrage starten
$buffer=[System.Text.Encoding]::ASCII.GetBytes("STARTTLS`r`n")
$c.Client.Send($buffer)
Sleep -Seconds 1

# Bei dieser Antwort sollte 220 rauskommen,
# sonst gibt es ein Problem
[byte[]]$buffer= @(0) * $c.Client.Available
$c.Client.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# für den weiteren Gang ist entscheidend, dass man einen Stream braucht
# vom Socket erhält man einen Stream, durch Weitergabe an NetworkStream-Klasse
$n=New-Object System.Net.Sockets.NetworkStream $c.Client

# über den Networkstream kann man nun SslStream aktivieren:
$ssl = New-Object System.Net.Security.SslStream $n, $true

# nun kann man den eigentlichen TLS Handshake starten, dazu muss nochmal der Host angegeben werden
$ssl.AuthenticateAsClient($smtp)

# für die weitere Kommunikation richtet man sich am besten zusätzliche Streams ein:
$reader = New-Object System.IO.StreamReader $ssl
$writer = New-Object System.IO.StreamWriter $ssl
$writer.AutoFlush = $true

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("EHLO $Env:Computername")
while ($reader.Peek() -gt -1) {
    $reader.ReadLine()
}

$writer.WriteLine("AUTH LOGIN")
$reader.ReadLine()

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("VXNlcm5hbWU6"))

If ($UserPass) {
  $Spass = ConvertTo-SecureString -String $UserPass -AsPlainText -Force
  $cred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $User, $SPass } else {
  $cred = Get-Credential –UserName $User –Message "Bitte Passwort eingeben"
}
$pass = $cred.GetNetworkCredential().Password
$userBytes = [System.Text.Encoding]::ASCII.GetBytes($user)
$userBase64 = [System.Convert]::ToBase64String($userBytes)
$writer.WriteLine($userBase64)
$reader.ReadLine()

$passBytes = [System.Text.Encoding]::ASCII.GetBytes($pass)
$passBase64 = [System.Convert]::ToBase64String($passBytes)
$writer.WriteLine($passBase64)
$reader.ReadLine()

$writer.WriteLine("MAIL FROM:$from")
$writer.WriteLine("RCPT TO:$to")
$writer.WriteLine("DATA")
#$writer.WriteLine("")
$writer.WriteLine("From: $from")
$writer.WriteLine("To: $to")
$writer.WriteLine("Date: {0}", (Get-Date).ToString("ddd, d M y H:m:s z"))
$writer.WriteLine("Subject: $Subject")
$writer.WriteLine("X-Mailer: $xmailer")
$writer.WriteLine("")
$writer.WriteLine("$Body")
$writer.WriteLine(".")
$writer.WriteLine("")
$writer.WriteLine("")
$reader.ReadLine()

# Streams und Sockets schließen
$ssl.Close()
$n.Close()
$c.Close()

Probleme mit Exchange, IMAP, POP3, SMTP, Outlook, Office365 usw. mit dem Microsoft Remote Connectivity Analyzer aufspühren

Mittels diesem Link kann man bei Microsoft verschiedene Dienste testen, ob diese generell funktionieren. Man muss zwar sein Zugangsdaten eingeben, aber was macht man nicht alles in verzweifelten Situationen, wenn gar nichts mehr geht.

https://testconnectivity.microsoft.com/

Telekom Speedport W 724V und das Problem mit dem E-Mailversand über SMTP, der blockt einfach alle Benutzerdomains

Im Grunde ist es ja gut, wenn man für Sicherheit sorgt. Ich verstehe auch, dass die Telekom, als mit größter Anbieter in Deutschland, sich aktiv am Schutz gegen SPAM und Konsorten beteiligt. Aber muss es dann auf dem Rücken der Benutzer, bzw. kleineren Firmen sein?

Der Speedport W 724V kommt scheinbar im Auslieferungszustand mit einer Einstellung, welche sich “Liste der sicheren E-Mail-Server” nennt. Dabei wird jegliche Kommunikation aus dem lokalen Netz von Port 25 und 587 ins Internet blockiert. Sei es Handy oder Computer spielt keine Rolle. Alles was den Speedport als Gateway eingetragen hat und über die SMTP-Ports rausgeht, wird blockiert.

Beim Testen äußert sich das Phänomen dadurch, das keine Telnet-Verbindung auf Port 587 zum Mailserver aufgebaut werden kann. Man verwendet

telnet mailserver.domain 587

Zunächst passiert ewig nichts und nach dem Timeout von ca. 20 Sekunden wird als Fehlermeldung

Verbindungsaufbau zu mailserver.domain…Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 587: Verbindungsfehler

dargestellt.

Von Erfahrenen Benutzern wird nun zunächst die Firewall oder der Virenscanner als Schuldiger in Betracht gezogen. Aber in diesem Fall ist es wie gesagt der Speedport.

Es werden wirklich auch nur bestimmte Ports geblockt. Wahrscheinlich neben 25 und 587 auch 465, welchen ich aber nicht getestet hatte. DNS-Abfragen und ICMP-Pakete vom Ping gehen jedoch problemlos durch. D. h. ein

ping mailserver.domain

wird klappen auch eine Abfrage bei nslookup liefert den passenden Mailserver.

Die Lösung ist am Ende den zugehörigen mailserver.domain in die Liste der sicheren SMTP-Server des Speedport aufzunehmen. Dabei macht es teilweise auch Sinn, wenn man die IP-Adresse des Servers mit aufnimmt, da diese in der Regel fix ist. Auch muss man teilweise mit Namensvarianten rechnen.

Für unbedarfte Benutzer ist sicher das Abschalten des Punktes im Speedport unter Internet, Liste der sicheren E-Mail-Server und entfernen des Häkchen bei “Liste der sicheren E-Mail-Server verwenden” die einfachste Lösung.

Zum Thema interessant ist noch folgender Thread bei der Telekom: https://telekomhilft.telekom.de/t5/Ger%C3%A4te-Zubeh%C3%B6r/W-724-V-blockt-Zugang-zu-smtp-Server/td-p/1050002

Hier bringt es auch Benutzer @Elgreco1900 schön auf den Punkt:

Ich weiß, wie ich das im Speedport ändern kann. Das ist nicht das Problem.

Das Problem ist, dass ich tätig bin für einen Hosting-Provider, der E-Mail-Dienste anbietet. Wir haben nun massenhaft Annrufe von Kunden, die keine E-Mails mehr versenden können. Die rufen bei uns an, nicht bei der Telekom, Und die sind sauer auf uns, nicht auf die Telekom. Und wir müssen denen dann erklären, wie sie den Speedport der Telekom umkonfigurieren müssen. Und wir müssen ihnen erklären, dass unsere Mailserver sicher sind, auch wenn die nicht auf der Liste der sicheren Mailserver der Telekom stehen. Die Telekom benachteiligt hier die E-Mail-Anbieter, die nicht auf der Liste stehen.

Womöglich sind von dem tollen Feature noch weitere Speedport betroffen: https://telekomhilft.telekom.de/t5/Ger%C3%A4te-Zubeh%C3%B6r/Speedport-W921V-SMTP-blockiert/td-p/464718.

Zum Testen sind diese Artikel hilfreich:
https://newyear2006.wordpress.com/2011/10/01/telnet-auf-die-schnelle-aktiveren-bzw-deaktivieren/
https://newyear2006.wordpress.com/2015/08/22/der-kleine-telnet-client-in-powershell/

Probleme mit Transportverschlüsselung, Zertifikaten oder Passwörtern bei SMTP-Servern mittels Powershell überprüfen

Gestern hatte ich schon im Artikel um den Telnet-Client-Ersatz https://newyear2006.wordpress.com/2015/08/22/der-kleine-telnet-client-in-powershell/ ein Beispiel angeführt, wie man einen SMTP-Server anfahren kann. Am entscheidenden Punkt mit dem TLS-Handshake hatte ich aber aufgehört. In der heutigen Zeit, wo im Prinzip alles über ein abgesichertes Transportprotokoll übertragen werden sollte, ein absolutes NoGo. Aus diesem Grund hier die Fortsetzung, wie der TLS-Handshake durchgeführt werden kann.

Vorab noch eines: Die Skripte sind Testskripte um entweder die Funktion oder einen einzelnen Problemfall nachvollziehen zu können. Sie sind nicht dazu gedacht bei irgendwelchen Automationsprojekten eingesetzt zu werden. Denn es fehlen Fehlerabfragen und die ordentliche Freigabe der verwendeten Ressourcen. In diesem Zusammenhang sei auch darauf hingewiesen, wenn mal etwas nicht klappt, einfach das Powershellfenster schließen und ein neues aufmachen, damit die belegten Ressourcen beim Prozessbeenden freigegeben werden. Hier nochmal der Link zum STARTTLS-Kommando und was dabei zu beachten ist: https://tools.ietf.org/html/rfc3207. So nun aber los.

Zunächst nochmal der grundsätzliche Verbindungsaufbau:

# Verbindung zu Web.de aufbauen
$c=Test-NetConnection smtp.web.de -Port 587

# Antwort vom SMTP-Server holen und ausgeben
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# Begrüßung durchführen
$buffer=[System.Text.Encoding]::ASCII.GetBytes("EHLO $Env:Computername`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Antwort vom SMTP-Server holen
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

# STARTTLS-Anfrage starten
$buffer=[System.Text.Encoding]::ASCII.GetBytes("STARTTLS`r`n")
$c.TcpClientSocket.Send($buffer)
Sleep -Seconds 1

# Bei dieser Antwort sollte 220 rauskommen,
# sonst gibt es ein Problem
[byte[]]$buffer= @(0) * $c.TcpClientSocket.Available
$c.TcpClientSocket.Receive($buffer)
[System.Text.Encoding]::ASCII.GetString($buffer)

An diesem Punkt kommt wieder der TLS-Handshake ins Spiel, der nun erfolgen sollte. Wenn man sich so die üblichen Dokus durchschaut, dann würde man meinen, man könnte direkt SslStream-Konstruktor mit dem TcpClientSocket aufrufen. Doch dies klappt leider nicht. Statt dessen muss zunächst ein Networkstream für den Socket erzeugt werden  https://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx. Dieser Punkt ist minimal aber der entscheidende Baustein, denn danach ist alles einfach. Sobald man dann den Socket als SslStream https://msdn.microsoft.com/en-us/library/system.net.security.sslstream.aspx hat, findet man wieder massig Informationen im Netz wie es weitergeht.

# für den weiteren Gang ist entscheidend, dass man einen Stream braucht
# vom Socket erhält man einen Stream, durch Weitergabe an NetworkStream-Klasse
$n=New-Object System.Net.Sockets.NetworkStream $c.TcpClientSocket

# über den Networkstream kann man nun SslStream aktivieren:
$ssl = New-Object System.Net.Security.SslStream $n, $true

Fast geschafft, der eigentliche Handshake https://msdn.microsoft.com/en-us/library/system.net.security.negotiatestream.authenticateasclient(v=vs.110).aspx beginnt hiermit:

# nun kann man den eigentlichen TLS Handshake starten, dazu muss nochmal der Host angegeben werden
$ssl.AuthenticateAsClient($c.ComputerName)

Ab jetzt hat man im Normalfall in $ssl alle Informationen, die man braucht. Somit lässt sich die Verbindung nun grob debuggen. Apropos debuggen, man kann bei Problemen auch das .Net-Tracing-System aktivieren, um mehr Infos bei Problemen zu erhalten, hier hab ich schon mal etwas darüber geschrieben: https://newyear2006.wordpress.com/2014/12/13/fr-powershell-net-framework-tracing-aktivieren/. Wer sich konkret dafür interessiert, was beim TLS-Handshake alles passiert, der möchte diesen Artikel lesen: https://www.simple-talk.com/dotnet/.net-framework/tlsssl-and-.net-framework-4.0/.

Hier nun die Ausgabe von $ssl:

TransportContext          : System.Net.SslStreamContext
IsAuthenticated           : True
IsMutuallyAuthenticated   : False
IsEncrypted               : True
IsSigned                  : True
IsServer                  : False
SslProtocol               : Tls
CheckCertRevocationStatus : False
LocalCertificate          :
RemoteCertificate         : System.Security.Cryptography.X509Certificates.X509Certificate
CipherAlgorithm           : Aes256
CipherStrength            : 256
HashAlgorithm             : Sha1
HashStrength              : 160
KeyExchangeAlgorithm      : 44550
KeyExchangeStrength       : 256
CanSeek                   : False
CanRead                   : True
CanTimeout                : True
CanWrite                  : True
ReadTimeout               : -1
WriteTimeout              : -1
Length                    :
Position                  :
LeaveInnerStreamOpen      : True

Die interessanten Eigenschaften hab ich mal gelb markiert. Hier fällt vor allem auf, dass beim KeyExchangeAlgorithm momentan 44550 steht, welche selbst im .Net-Framework 4.6 nicht dokumentiert ist. Allerdings gibt es eine Erklärung dazu: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d0298622-a7cc-40e8-a4bf-8b74696ff548/sslstreamkeyexchangealgorithm-44550?forum=netfxbcl. Kurz: Beim Wert 44550 handelt es sich um einen ECDH Ephermal. Weitere Infos dazu: https://tools.ietf.org/html/rfc5753#section-3.1.

Weiter wäre zu bemerken, dass die Eigenschaft SslProtocol auf Tls steht, was gleichbedeutend mit TLS 1.0 ist. Aktuell sollte immer TLS 1.2 verwendet werden. Hier stellt sich die Frage, liegt es am Server oder liegt es am Client, sprich in diesem Fall am .Net Framework? Diese Frage wollen wir ein anderes Mal betrachten.

Man kann auch das erhaltene Zertifikat abfragen:

$ssl.RemoteCertificate.ToString($true)
[Subject]
  CN=smtp.web.de, E=server-certs@1und1.de, L=Montabaur, S=Rhineland-Palatinate, OU=WEB.DE, O=1&1 Mail & Media GmbH, C=DE

[Issuer]
  CN=TeleSec ServerPass DE-1, STREET=Untere Industriestr. 20, L=Netphen, PostalCode=57250, S=NRW, OU=T-Systems Trust Center, O=T-Systems Internatio
nal GmbH, C=DE

[Serial Number]
  00A684C2D320436B39

[Not Before]
  21.08.2013 10:35:51

[Not After]
  27.08.2016 01:59:59

[Thumbprint]
  40051058DE6797D8ACFAF55224CF5282F44E0B5D

Falls beim TLS-Handshake etwas schief gehen sollte, dann hat dies meist mit den Zertifikaten zu tun. Wie man diesem Problem auf den Grund gehen kann, habe ich in einem früheren Blogartikel bereits beschrieben: https://newyear2006.wordpress.com/2014/01/04/ssltls-fehler-in-powershell-bzw-wie-man-zertifikatsprobleme-unter-windows-analysieren-kann/.

OK jetzt sind wir schon so weit gekommen, wäre schön, wenn man jetzt noch prüfen könnte, ob der Benutzer tatsächlich seine SMTP-Zugangsdaten kennt. Dazu richten wir einen Reader- und Writer- vom SSL-Stream ein, senden nochmals das obligatorische EHLO und anschließend die gewünschte Authentifizierungsmethode, hier LOGIN:

# für die weitere Kommunikation richtet man sich am besten zusätzliche Streams ein:
$reader = New-Object System.IO.StreamReader $ssl
$writer = New-Object System.IO.StreamWriter $ssl
$writer.AutoFlush = $true

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("EHLO $Env:Computername")
while ($reader.Peek() -gt -1) {
    $reader.ReadLine()
}

$writer.WriteLine("AUTH LOGIN")
$reader.ReadLine()

Nun liefert der Server ein kryptisches VXNlcm5hbWU6, was ganz einfach Base64 kodiert für Username: steht. Man kann dies ganz einfach prüfen, wenn man diesen Befehl ausführt:

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("VXNlcm5hbWU6"))

Man sollte nun also den Benutzernamen liefern, z. B. so:

$user = "meinewebdeadresse@web.de"
$cred = Get-Credential -UserName $user -Message "Bitte Passwort eingeben"
$pass = $cred.GetNetworkCredential().Password
$userBytes = [System.Text.Encoding]::ASCII.GetBytes($user)
$userBase64 = [System.Convert]::ToBase64String($userBytes)
$writer.WriteLine($userBase64)
$reader.ReadLine()

$passBytes = [System.Text.Encoding]::ASCII.GetBytes($pass)
$passBase64 = [System.Convert]::ToBase64String($passBytes)
$writer.WriteLine($passBase64)
$reader.ReadLine()

Es wird noch mittels UGFzc3dvcmQ6 nach dem Passwort gefragt, welches, wie der Benutzername auch per Base64 Kodierung geliefert wird. Am Ende sollte man ein

235 Authentication succeeded

sehen, dann weiß man, dass alles korrekt ist.

Möchte man die Verbindung ordentlich beenden, schiebt man noch dieses hinterher:

# damit wird die weitere Kommunikation einfacher und das Spiel beginnt von vorne:
$writer.WriteLine("QUIT")
$reader.ReadToEnd();

# Streams und Sockets schließen
$ssl.Close()
$n.Close()
$c.TcpClientSocket.Close()

Hier nochmal alles als GIST zur besseren Lesbarkeit, bzw. bei Erweiterungen: https://gist.github.com/newyear2006/2a6a3fb0cea8dc1063ba

Durch all diese Möglichkeiten zum Debuggen erübrigt sich langsam der Griff nach OpenSSL s_client https://www.openssl.org/docs/manmaster/apps/s_client.html zum Testen von SMTP-Verbindungen.