Das SMTP Protokoll im Detail betrachtet
Vor einem Jahr habe ich bereits das IMAP-Protokoll näher betrachtet, nun soll das SMTP Protokoll folgen. Jeder versendet und empfängt E-Mails, und viele von euch werden auch eigene Mailserver betreiben, es kann also nicht schaden das Protokoll näher zu kennen. SMTP steht für Simple Mail Transport Protocol, und genau das ist es auch: Simple. Mit einer Hand voll Befehlen kann man E-Mails auf den Weg bringen. SMTP wird von Mailservern gesprochen die E-Mails empfangen oder an andere Mailserver weitergeben, zur E-Mail-Abholung durch einen Client wird IMAP oder POP3 genutzt.
Nehmen wir erstmal den einfachsten Fall: Wir möchten eine E-Mail an meine E-Mail Adresse schicken. Dazu müssen wir zuerst herausfinden welcher Server für diese E-Mail-Adresse zuständig ist. Wir befragen den DNS-Server nach dem sogenannten MX-Eintrag (Mail Exchange) und erhalten den oder die Server, an die wir uns wenden müssen:
dig -t MX phpgangsta.de +short 10 mail.phpgangsta.de.
Hier könnten auch mehrere Ergebnisse erscheinen wenn ich mehrere Mailserver betreiben würde. Wir schauen also als nächstes, wer hinter mail.phpgangsta.de steckt:
dig mail.phpgangsta.de +short 85.214.28.26
In diesem Fall ist es mein Server mit der IP 85.214.28.26, wir müssen unsere E-Mail also dort abgeben. Der SMTP Port ist TCP 25, wohin wir uns ganz einfach mittels Telnet verbinden können:
telnet 85.214.28.26 25 Trying 85.214.28.26... Connected to 85.214.28.26. Escape character is '^]'. 220 h1440682.stratoserver.net ESMTP Postfix (Debian/GNU)
Der Server begrüßt uns mit seinem Namen und verrät auch gleichzeitig, dass er nicht nur SMTP spricht, sondern auch Extended SMTP (ESMTP). Mittlerweile sollten alle dieses neue Protokoll unterstützen, das 1995 eingeführt wurde um spezielle Fähigkeiten (Extensions) hinzuzufügen wie beispielsweise Authentifizierung. Vorher gab es die nicht, daran hatte wohl niemand gedacht früher *tzz*. Aber auch TLS ist erst mit ESMTP möglich, heutzutage gibt es auch wahrscheinlich keine Server mehr, die kein ESMTP anbieten.
Da der Server auch TLS unterstützt können wir uns auch verschlüsselt verbinden, indem wir erst eine normale Verbindung (wie oben) aufbauen und dann direkt mit dem STARTTLS Befehl in den verschlüsselten Modus wechseln. Da man das in Telnet schlecht eintippen kann nutzen wir den openssl-Client, der genau dies macht:
Continuous Testing mit PHP?
Continuous Integration ist einigen eventuell ein Begriff. Dabei geht es darum, einen Server zu haben der bei jedem Commit (bzw. Push) des Quelltextes Dinge ausführt wie Unit Tests, Akzeptanz-Tests, PHP Lint, CodeSniffer oder auch ein Deployment auf einen Test-Rechner. Wenn man nun also häufig pushed kann man sicher sein dass (bei genügend guten Tests) die Software läuft und nichts kaputtgegangen ist. Und wenn doch, weiß man wann es ungefähr passiert ist.
Continuous Testing geht nun noch einen Schritt weiter. Hierbei werden nicht erst bei jedem Push die Unit-Tests gestartet sondern bei jedem Abspeichern einer Datei auf dem Entwicklungsrechner. Da gibt es nun mehrere Ansätze wie man das erreichen kann. Vielleicht kennt ihr andere und bessere Tools, um kontinuierlich auf der Workstation zu testen.
Möglichkeit 1: Die IDE bietet einen „On-Save“ Einstellung, wo man einen Befehl eingeben kann der ausgeführt wird sobald die IDE eine Datei abspeichert. Dort trägt man dann sein Shell-Script ein das die Unit-Tests startet. in PHPStorm kann man zum Beispiel auch einstellen dass nach 15 Sekunden IDLE automatisch gespeichert wird, oder wenn PHPStorm den Fokus verliert (weil man gerade in den Browser wechselt). Ein Garant für häufiges Testen.
IPC 2011, Very Early Bird, 200 Euro sparen + Netbook
Erstmal vorweg: Happy Birthday zum Geburtstag an PHP hates me und seinem Autor Nils zum 3-jährigen Bestehen! Mach weiter so, wir sehen uns auf der Unconference in Hamburg und auch auf der IPC!
Es ist DIE Konferenz in Deutschland, die International PHP Conference, die in diesem Jahr vom 9.-12. Oktober stattfinden wird. Der Zeitplan der 4 Tage ist vollgepackt mit 48 Sessions/Keynotes und 3 Power Workshops, es können auch nur einzelne Tage gebucht werden.
Zeitgleich findet die WebTech Conference 2011 statt, und all diese Sessions können auch besucht werden, 48+16 = 64 Sessions!
Bis zum 12.08. läuft noch die Very-Early-Bird Phase, sodass man 200 Euro des Ticketpreises spart und ein Netbook gratis erhält. Bis zum 9. September sind es immerhin noch 100 Euro plus Netbook. Aber wer weiß wie lange es noch Karten gibt?!
Also, rüberlaufen zum Chef und Weiterbildungsmaßnahme beantragen!
Die letzten Tickets für die PHP-Unconference in Hamburg
Wenn ich es richtig sehe sind von gestern Abend noch ca. 20 Tickets übrig, dann sind die 300 voll. Falls ihr also für 35 Euro an der PHP Unconf in Hamburg teilnehmen möchtet ist jetzt die letzte Chance.
Dieser Schlüssel zerstört sich in 30 Sekunden selbst
Gastartikel von Oliver Sperke.
Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.
Nachdem ich ja in den letzten Wochen über den sicheren Umgang mit Passwörtern in Webprojekten erzählt habe, soll es heute mal um etwas anderes gehen (aber trotzdem um das Thema Sicherheit). Wenn man oft auf fremden oder eigenen Servern arbeitet, kommt man an OpenSSH eigentlich nicht vorbei. Und wenn man dazu noch so faul ist wie ich (und vermutlich die meisten von Euch auch), hat man keine dutzenden Dateien mit Passwörtern, sondern wickelt die gesamten Loginvorgänge mit Hilfe von öffentlichen und privaten Schlüsseln ab. Dieses Verfahren ist nicht nur bequem, es bietet auch zusätzliche Sicherheit, da man nicht in Versuchung kommt, einfache Passwörter zu verwenden. Ausserdem ist die eigene Passwortliste schon von Haus aus verschlüsselt.
Das Verfahren hat aber für einen Serverbetreiber Nachteile. Der öffentliche Schlüssel muss auf dem Server hinterlegt werden. Ausserdem muss man sobald der Zugang nicht mehr benötigt wird, nachsehen, ob ein Benutzer sich vielleicht eigene Schlüssel hinterlegt hat und natürlich muss man ihm den Zugang manuell sperren.
