ITBlog

jippie endlich: public class Test { public void main(String args[]) { Sytem.out.println("Bla\"bla\"" + i); } } ... was gefunden für das dpSyntaxHighliter in S9Y. Und weil die Doku nicht beschreibt wie man es benutzt, hier ein Beispiel: <textarea name="code" class="java">public class Test { public void main(String args[]) { Sytem.out.println("Bla\"bla\"" + i); } }</textarea>

Mit Hilfe des TPM kann auf moderner Hardware auf sichere Art und Weise Verschlüsselungmaterial abgelegt werden oder die idendität des Gerätes nachgewiesen zu werden. Windows ab Vista und 2008 Server unterstützt dies auch für Bitlocker Festplattenverschlüsselung. Aber das TPM kann auch für andere Anwendungen genutzt werden. Verwaltet wird es mit dem Management Consolen Plugin "tpm.msc". Die meisten Funktionen wie das übernehmen des Besitzes oder das Erzeugen von Keys kann aber über die Windows Management Instrumentation (WMI) auch gespcriptet werden. Dabei bietet sich insbesondere die Powershell an: PS> $tpm = Get-WMIObject -Class Win32_Tpm -Namespace "root/CMIv2/Security/MicrosoftTPM" PS> $tpm IsActivated_InitialValue : False IsEnabled_InitialValue : False IsOwned_InitialValue : False ManufacturerId : 1112687437 ManufacturerVersion : 7.11 ManufacturerVersionInfo : Not Supported PhysicalPresenceVersionInfo : 1.0 SpecVersion : 1.2, 2, 1 Wenn man das Owner Passwort hat, so kann man das TPM auch mit der Powershell zurücksetzen: PS> $tpm.Clear($tpm.ConvertToOwnerAuth('PASSWORT'.OwnerValue)) ReturnValue : 0 Wenn das TPM dies nicht zulässt, oder das Owner Passwort nicht bekannt ist, so ist es auch möglich über den Nachweis einer physischen Präsenz das TPM zu initialisieren oder zurückzusetzen. Die Methode SetPhysicalPresenceRequest kann dazu mit dem Wert 5 (zurücksetzen) aufgerufen werden. Und GetPhysicalPresenceTransition liefert dann die Aktion die der Benutzer durchführen muss. Im Fall des Wertes 2 wäre dies ein Soft-Reboot und eine Bestätigung der Aktion im BIOS. PS> $tpm.SetPhysicalPresenceRequest(5) ReturnValue : 0 PS> $tpm.GetPhysicalPresenceTransition() ReturnValue : 0 Transition : 2 Und wie erwarten funktioniert dies auch (ohne das Owner Passwort abzufragen). Getestet habe ich dies unter Windows 7 auf einem Dell Latitude E6510 mit einem TPM von Broadcomm.

Passwörter haben eine Menge Probleme. Deswegen gibt es jede Menge best-practice um diese Probleme etwas zu reduzieren. Eine einfache Regel ist, dass man Passwörter von Benutzern so abspeichern sollte, dass diese nicht wiederhergestellt werden können. Der Grund dafür ist insbesondere dass die Passwörter die ggf. in unterschiedlichen Diensten genutzt werden nicht eventuellen Hackern (oder unehrlichen Administratoren) in die Hände fallen können. Dazu werden die Passwörter durch eine Hash Funktion einwegverschlüsselt. Bei der Prüfung des Passwortes wird dann nicht das eingegebene Passwort mit der gespeicherten Version vergleichen, sondern die Einweg-Funktion darauf angewendet und dann verglichen. Eine Konsequenz dieses Verfahren ist es, dass das Passwort von der Anwendung nicht wieder angezeigt oder per Mail an den User gesendet werden kann. Bei mehr oder weniger öffentlichen Diensten ist es üblich, dass es dort eine Passwort-vergessen Funktion gibt die eine Reset Mail an den Benutzer versendet. Dieses Verfahren verlässt sich auf die Sicherheit des E-Mail Verkehrs - ist somit keine sonderlich sichere Option - aber bei Diensten die mehr oder weniger öffentlich angeboten werden ist die E-Mail Adresse sowieso die einzige zusätzliche Möglichkeit den User zu erreichen. Es gibt im wesentlichen 3 Möglichkeiten für solche Passwort-Zurücksetzungsmails: a) aktuelles Passwort per E-Mail zusenden. Das hat den ganz großen Nachteil, dass das Passwort dazu wiederhergestellt werden muss (also nicht Einweg-verschlüsselt sein kann). Außerdem wird das aktuelle Passwort unverschlüsselt per E-Mail versendet. Was besonders problematisch ist wenn dieses wiederverwendet wurde oder weiterverwendet wird. b) neues Passwort erzeugen und zumailen. Nachteil bei dieser Methode: jeder kann eine beliebige E-Mail Adresse eingeben um deren Besitzer mit nicht funktionierenden Passwörtern zu nerven. c) Reset-Link erzeugen und zumailen. Wenn der Benutzer den Link benutzt, so wird er um Eingabe eines neues Passwortes gebeten. Dies bietet den Vorteil, dass das alte Passwort weiterhin gültig bleibt wenn die Funktion jemand unberechtigt benutzt. Außerdem wird kein Passwort per (unverschlüsselter) Mail versendet. Man sieht hier schnell, dass die Methode a) nicht nur die unsicherste und unpraktische ist, sondern auch dass man daraus auch als Endanwender (ohne den Quelltext zu analysieren oder die Datenbank zu kennen) sofort ablesen kann, dass die Web Anwendung eine unsichere Passwort Speicherung verwendet. Immer wenn ich eine Passwort Recovery Mail mit einem bestehenden Passwort bekomme regt mich das auf, deswegen muss ich jetzt mal einfach hier im Blog "Fingerpointint" betreiben:

• Intel Software Network: speichert und mailt Passwörter an Benutzer
• BMC Servicedesk Express: speichert und mailt Passörter an Benutzer. (Beispiel)
• Open Application Group (OAGi) Portal. (Beispiel)
• RosettaNet.org (Beispiel)
• kontent.de (Beispiel)
• mailman Die GNU Mailing-List-Manager-Software weist wenigstens beim Anlegen eines Kontos schon drauf hin (einfacher wäre es die Eingabe generell zu entfernen und nur zufällige Passwörter zuzusenden)

Update: OAGi und Rosettanet.org (danke Christian) hinzugefügt. kontent.de hinzugefügt (danke Robin). Added mailman.

Wie ich bereits berichtet hatte kann es für einen Anwender der IaaS Cloud Amazon EC2 Sinn ergeben den Simple Email Service (SES) von Amazon zu verwenden um E-Mails zu versenden. Dabei kann man entweder die Amazon API/Tools verwenden, oder inzwischen auch die Mails per smtps an den Amazon Smarthost liefern. Amazon selbst bietet nur einen SMTP-SSL Server auf Port 465 an. Die meisten MTAs können dieses Protokoll nicht mehr sprechen und ziehen STARTTLS vor, deswegen empfiehlt Amazon in seiner Anleitung die Verwendung von stunnel als zwischengeschaltenen Proxy. Diese Indirektion ist aber unschön, und kann mit einer aktuellen Exim Version vermieden werden. Ab der Version 4.77 unterstützt der SMTP Transport von Exim auch das smtps Protokoll (für ausgehende Verbindungen). Mit folgenden Exim Einstellungen (Auszug) kann also ein EC2 Linux Rechner direkt an den Amazon Dienst die E-Mail ausliefern (wichtig: die Envelop-From und From: Addresse der versendeten Mails müssen in der Liste der verifizierten SES Absender sein. Als Empfänger kommen nur dann beliebige E-Mail Addressen in Frage, wenn man diese Funktion bei Amazon explizit freischalten hat lassen. 1. Alle Mails an dem Amazon Server leiten (dnslookup entfernen):

smarthost:
  driver = manualroute
  domains = ! +local_domains
  transport = remote_smtps
  route_data = email-smtp.us-east-1.amazonaws.com
  no_more

2. Einen neuen SMTP/SSL Transport definieren:

remote_smtps:
  driver = smtp
  protocol = smtps
  #port = 465
  hosts_require_auth = *
  hosts_require_tls = *

3. Zusätzlich einen Authenticator mit dem SES User/Passwort definieren:

client_login:
  driver = plaintext
  public_name = LOGIN
  client_send = : xxxxI6CIH2YIWSNxxxxx : Agcq00AEvA2ZDiQHNrDvTEODE3FWa1rxxxxx

Ich habe das ganze unter Amazon Linux mit Exim 4.77 aus dem AltCent Repository getestet:

wget http://centos.alt.ru/repository/centos/6/i386/exim-4.77-1.el6.i686.rpm
rpm -i exim-4.77-1.el6.i686.rpm

Es bietet sich an Exim so zu konfigurieren, dass nur auf localhost auf dem Submission Port E-Mails angenommen werden:

daemon_smtp_ports = 587
local_interfaces = 127.0.0.1

Dies stellt sicher, dass der Dienst nicht für Spam oder Sicherheitsangriffe ausgenutzt werden kann.

Mit Java 7 sind in den SSL/TLS Provider von Oracle einige neue Funktionen eingezogen. Darunter der schon lange erwartete Support für TLSv1.1 und TLSv1.2, aber auch die Unterstützung der TLS Extensions u.A. für die Server Name Indication(SNI). Letzteres wird dazu verwendet virtuelle Hosts auf einem SSL Port zu unterstützen: Bisher konnte ein SSL Server nämlich nicht wissen an welchen (der potentiell vielen) virtuellen Dienste hinter einer IP Adresse sich der SSL Client wenden will. Besonders ärgerlich ist dies im Fall von HTTP/s, dort ist es die Regel dass Hoster sehr viele Kunden-Domains hinter ein und der selben IP-Adresse betreiben. In HTTP/1.1 wird der gewünschte Servername in der Anfrage mitgegeben (Host: Header). So kann der HTTP Server entscheiden welche Webseiten er ausliefern soll. Im Falle des SSL Server Zertifikats (welches im SSL Handshake schon vor der HTTP Anfrage ausgetauscht wird), kann dies der Webserver aber nicht. Er muss raten welches Zertifikat er dem Client präsentieren soll, und das schlägt natürlich in der Regel fehl. Mit der Extension wird der Servername auch im Handshake mitgeschickt, und der Server kann sein Zertifikat passend auswählen. Problem bei der Geschichte ist: der Server darf auf eine solche Namensanfrage mit einem SSL Alert (Warning) reagieren. In dieser sagt er, dass er sich für den angefragten Host nicht zuständig fühlt. Das kommt bei aktuellen Webserver Installationen häufig vor, weil diese einfach nicht korrekt eingerichtet sind (und die modernen Browser die SNI unterstützen diese Warnung auch einfach ignorieren). Da das zurückgelieferte Default Zertifikat oftmals den richtigen Hostnamen (in einer der Attribute) enthält, klappt der gesicherte Handschlag im Alltag dennoch. Nicht jedoch mit Java 7 SSL Clients, JSSE macht daraus eine fatale Exception:

javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
	at sun.security.ssl.ClientHandshaker.handshakeAlert
	at sun.security.ssl.SSLSocketImpl.recvAlert
	at sun.security.ssl.SSLSocketImpl.readRecord
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake
	at sun.security.ssl.SSLSocketImpl.startHandshake
	at sun.security.ssl.SSLSocketImpl.startHandshake
	at sun.net.www.protocol.https.HttpsClient.afterConnect
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream

Ich habe deswegen einen Bugreport aufgemacht, jedoch wurde dieser wieder kommentarlos geschlossen. Falls Sie nun trotz Oracle's widerstreben die Notwendigkeit haben mit einem Web Server zu kommunizieren der SNI nicht richtig eingerichtet hat, so bleiben nur 2 Möglichkeiten über: a) TLS aus der Liste der unterstützten Protokolle entfernen - mit einem SSLv3 Handshake wird kein Extension Record übertragen, und entsprechend klappt auch der Handshake (solange der Server SNI nicht benötigt). b) den SSL Socket so initialisieren, dass die SSLEngine den Host nicht kennt. Dieser sogenannte Host hint wird für mehrere Dinge verwendet, kann aber auch weggelassen werden. Erreichen kann man dies, indem man den Socket statt mit s=factory.createSocket(name, port); mit "s=factory.createSocket(); s.connect(name,port);" erzeugt. Übrigens ist dies ein ziemlich unerwartetes Verhalten: SSL mit Kerberos Authentifizierung würde nur auf die erste Art und Weise funktionieren, da hierfür die Identität des Servers bekannt sein muss. Der Punkt a) ist ein schneller Fix, kommt aber in der Praxis eigentlich nicht in Frage, da man mit Java 7 ja eher daran Interesse hat TLSv1.1 oder TLSv1.2 zu verwenden um Lücken wie z.B. den BEAST-Angriff auszuschließen. Daher bleibt es nur übrig entweder den Anwendungscode zu ändern (oder wenn man diesen nicht selbst geschrieben hat, wie im Falle einer häufig verwendeten URLConnection oder beim Apache HTTPClient) oder aber mindestens eine eigene SSLSocketFactory zu implementieren, die auf die 2-stufige Erzeugung des SSLSockets aufsetzt. Update: Ich habe in den Sourcen grade eine System Property gefunden, mit der man abschalten kann, dass der ClientHandshaker die SNI Extention sendet. Dies lässt sich als Work around gut verwenden: System.setProperty("jsse.enableSNIExtension", "false"); (muss vor der Verwendung von SSL Klassen im Programm, oder auf der Command Line gesetzt werden).

Die Bundesnetzagentur hat ein Eckpunktepapier zum Thema Smart Grids und Markets veröffentlicht. Damit will die Bundesbehörde

durch dieses Papier eine intensivere Diskussion der Thematik anstoßen zu können und die Veränderungen des Energieversorgungssystems weiter voran zu bringen. Dieses Eckpunktepapier soll die Diskussion zu dieser Thematik weiter befördern und besser strukturieren.

Das "Eckpunktepapier der Bundesnetzagentur zu den Aspekten des sich verändernden Energieversorgungssystems" enthält Leitgedanken und Begriffsdefinitionen und ist schon aus diesem Grund sehr lesenswert. Ob die einzelnen Thesen (Abnahme des Gesamtenergieverbrauchs) nun zutreffen wird sich zeigen, von einer Zunahme der Stromabnahme wird aber ausgegangen. Auch bei intelligenteren Verbrauchern (da zunehmend andere Energieformen verdrängt werden, was angesichts der Endlichkeit von fossilen Energieträgern nur logisch ist). Das Paper baut darauf, dass Verbraucher sich über Marktsignale (Preise) steuern lassen. Das wird sich zeigen wie gut das funktioniert... Ein wenig sehr optimistisch dürfte die Annahme der Transaktionskostensenkung bei "kleinteiliger Interaktion" sein (Fehlschläge im Smartmeter Markt wie in den Niederlanden oder Großbritannien deuten ja eher darauf hin, dass es sinnvoll sein kann alternative Lösungswege anzustreben und nicht alles über Informationstechnologie lösen zu wollen. Größtenteils wird der Smartmetermarkt von Anbietern getrieben die sich neue Einnahmequellen versprechen und die Vorteile werden in den meisten Haushalten weder gesehen - noch existieren diese). Das BNetzA Papier sieht dies aber auch (Leitgedanke 4). Was mir persönlich im Papier fehlt ist ein klarere Fokus auf das Thema Datenschutz, Schutz von kritischen Infrastrukturen und Monokultur. Die Notwendigkeit von Datendrehscheiben wird nicht hinterfragt, und eine Vermischung der Messdaten von Prosumenten oder Industrieabnehmern mit den Messstellen in Haushalten führt meiner Meinung nach zu einer Übertechnisierung der Haushalte. Für eine zuverlässige Demand-Site Prognose ist meiner Meinung nach nicht notwendig den Tagesverlauf jedes einzelnen Haushaltes zu betrachten - ganz im Gegenteil das ist eher schädlich. Der Nutzen von mehr Transparenz beim Stromverbrauch eines einzelnen Haushaltes kann auch durch eine rein lokale Informationsanwendung (deutlich besser) gelöst werden. Eine feingranulare Übermittlung von Messwerten erscheint mir nicht zwingend notwendig und vor allem nicht Ökonomisch. In dem Zusammenhang verweise ich auch auf den Artikel in der aktuellen Datenschleuder #95 (Power to the People, Das Stromnetz der Zukunft, Mathias Dalheimer, Seite 35-48) und die Projekte mySmartGrid sowie volkszaehler.org.

Von den Änderungen in Java SE 6.0 Update 29 zum Schutz vor SSL BEAST Angriffen hatte ich schon berichtet. Ein Opfer dieser Kompatibilitätsänderung sind die JDBC Treiber für den Microsoft SQL Server (jTDS und Microsoft JDBC Driver for SQL Server sind betroffen). Beim Aufbau der Verbindung (TCP) direkt mit dem jTDS Treiber kommt es zu folgendem Fehler:

java.sql.SQLException: I/O Error: Software caused connection abort: recv failed
  State  : 08S01
  Error  : 0

Und die folgende Exception wirft der Microsoft JDBC Driver for SQL Server:

com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset
  State  : 08S01
  Error  : 0

Wenn die Treiber durch einen Connection Pool benutzt werden, oder innerhalb einer Datasource, so kann es sogar zum Hängen (wegen Endlosschleife) kommen. Eine Möglichkeit ist es, beim jTDS Treiber anzugeben, dass man kein SSL machen möchte (sollte aber eigentlich auch der default sein, laut jTDS FAQ). Dies kann man mit dem JDBC URL Property ";ssl=no" erreichen. Wenn der Server allerdings auf "Force Encryption" konfiguriert ist, so wird er dann die Logins ablehnen. Beim Microsoft Treiber würde das property "encrypt=false" lauten, dies half aber in meinen Versuchen (mit MS SQL Server 2008 R2 Express) nicht. Eine weitere Möglichkeit ist es den SSL/TLS CBC-Fix per Java System Property abzuschalten: -Djsse.enableCBCProtection=false Dies wirkt sich aber auf alle anderen SSL Verbindungen innerhalb dieser VM ebenfalls aus. Es gibt Berichte, dass dieses Problem mit JavaSE 6.0 Update 30 behoben sei, das kann ich aber weder nachvollziehen, noch lassen die ReleaseNotes darauf schließen. Ich habe mal einen Fehlerbericht bei jTDS dazu geöffnet.

Wer ein Smartphone mit sich rumschleppt wird schon auf die Idee gekommen sein einen Web Kalender wie z.B. Google Calendar zu synchronisieren, um immer alle Termine im Blick zu haben. In meinem Fall habe ich einen Google Calendar Account in dem ich einige andere Kalender zusammenfasse, dieser wird dann per CalDAV auf dem iPhone eingebunden. So sehe ich zum Beispiel die Karlsruher IT Termine, die Familientermine und die Termine der Karlsruher Piraten.

Was mir bisher noch gefehlt hat, waren meine Facebook Events, da hier immer auch mal wieder eine Einladung dabei ist, der ich zwar bei Facebook zusage, diese dann aber nicht in einen der Google Calender übernehme. Es gibt hier aber eine einfache Möglichkeit, man kann die Events in Facebook als webcal/ical Feed exportieren. Diese URL kann man dann in Google als neuen Kalender von einer URL importieren.

Das hat aber leider das Problem, dass Google bei einigen Einträgen kein Titel oder Beschreibung anzeigt. Das ist ein bekanntes Problem, und es gibt im Web auch Anleitungen wie man das beheben kann. Bei mir hat das auch geklappt (allerdings musste ich nicht CLASS:CONFIDENTIAL in CLASS:PUBLIC ändern, sondern bei mir waren es CLASS:PRIVATE Einträge die Facebook produziert hat: <?php $ical="http://www.facebook.com/ical/u.php?uid=XXX&key=XXX"; $file=file_get_contents($ical); $replace="CLASS:PUBLIC"; $output=str_replace("CLASS:CONFIDENTIAL",$replace,$file); $output=str_replace("CLASS:PRIVATE",$replace,$output); header("Content-Type: text/Calendar"); // Give the file a name and force download header("Content-Disposition: inline; filename=events.ics"); print_r($output); ?> Diese Lösung setzt allerdings voraus, dass man irgendwo ein PHP Script ablegen kann. Damit muss man jetzt nur die Export-URL von Facebook in dem PHP Script hinterlegen ("webcal:" in "http:" ändern), und in Google die PHP URL als Kalender importieren. Dabei ist zu beachten, dass jeder der das Script kennt und aufrufen kann so an alle Facebook Termine rankommt (auch die privaten).

Wer das mit dem eigenen PHP Script nicht machen will, der kann auch Yahoo! Pipes verwenden. Das ist ein Dienst bei den man eine Verarbeitungspipeline für Feeds zusammenstellen kann. Im Falle von ICS Dateien reicht es bei Yahoo aus diese nur als Source zu definieren, und dann direkt wieder zurückzugeben, denn die Yahoo Quelle für Feeds (die ICS versteht) filtert automatisch die CLASS Attribute ganz raus.

Bei Yahoo Pipes muss man immer etwas tricksen wenn man einzelne Komponenten verbinden möchte (auf den Typ achten), deswegen hat die von mir verwendete Pipe noch den Zwischenschritt mit dem URL-Builder. Die URL selbst ist in einem "Private String" abgelegt, damit niemand der die Sourcen sehen kann an meine Facebook Events herankommt. (Leider lässt sich aber die Pipe trotzdem nicht sinnvoll Sharen, aber ich denke mit dem Screenshot könnt Ihr Euch leicht eine eigene zusammenbauen). Beim Aufruf der Pipe ist es wichtig den Parameter "_render=ical" mitzugeben. Früher gab es hierfür wohl einen Menueintrag bei Yahoo, der scheint aber entfernt worden zu sein. Auch hier gilt, wer die Addresse Eurer Pipe kennt, kann Eure Facebook Terminzusagen lesen.

Amazon EC2 ist ein IaaS Anbieter bei dem man eigene virtuelle Systeme starten kann. Diese Systeme können dann alle Systemfunktionen die eine Anwendung benötigt bereitstellen. Dazu gehört zum Beispiel auch der E-Mail Versand (z.B. root Mails oder eben E-Mails der Anwendung wie z.B. Passwort Reminder oder Notifications). Um sicherzustellen, dass die E-Mails die von einem Amazon EC2 System abgeschickt werden auch ankommen, und nicht in Spam Filter der Provider hängenbleiben sind folgende Punkte zu beachten: a) wenn man einen Mailserver (MTA) verwendet der die Mails versendet so sollte dieser natürlich sicher konfiguriert sein, und kein Relaying von E-Mails zulassen - da sonst der EC2 Server zur Spamschleuder wird (was nicht nur Ärger mit Amazon nach sich zieht). b) Der SMTP Server meldet sich mit einem Rechnername. Dort sollte er nicht den internen Amazon EC2 Namen verwenden der dem Rechner zugewiesen wird, denn dir dort verwendete .internal Domain wird von vielen E-Mail Empfängern als ungültig abgelehnt. c) Die E-Mail Adresse des SMTP Servers (also in dem Fall der virtuelle EC2 Host) sollte in einen gültigen Hostnamen aufgelöst werden, denn sonst springt der Spamschutz der Empfänger an. Dies ist bei Amazon nur sinnvoll machbar wenn man eine Elastic IP verwendet. Dieses Verfahren wird PTR oder auch "reverse DNS" checks genannt. d) Der Envelop-From (im Falle von Cron Mails z. B. root@host) der versendeten E-Mails sollte eine gültige E-Mail Adresse sein. Insbesondere prüfen E-Mail Server beim Empfang, ob die Domain existiert. Hier sollte also auch nicht der .internal Hostname von AWS verwendet werden. e) Die Domain einer Absender E-Mail Adresse sollten nicht nur gültig sein, sondern mit dem SPF Mechanismus (Sender Policy Framework) kann der Betreiber der Domain auch angeben von welchen Rechnern legalerweise Mails mit dem Absender versendet werden. Einige Empfänger benutzen das, um das Spamaufkommen zu reduzieren. In der Regel kommt in der Liste der zugelassenen Server nur die MX Server der Domain vor, und eben nicht beliebige IP-Adressen aus den Amazon AWS Netzen. Es bietet sich auch nicht an das komplette EC2 Netz in die Liste aufzunehmen, da sonst alle Amazon Kunden wiederum E-Mails am SPF Filter vorbei versenden können (das ist zwar weniger ein Problem aber eben unschön). Aus diesen Punkten ergeben sich zwar einige Konfigurationen die man vornehmen kann um von einem EC2 Host direkt an Endempfänger Mails zu versenden. Die Wahrscheinlichkeit dass diese aber häufig als Spam erkannt werden ist groß. Deshalb ist es anzuraten, dass ein Smarthost verwendet wird. (Das hat auch administrative Vorteile wenn die EC2 Hosts Ihre Mails schnell loswerden und man nicht mehrere Mailwarteschlangen überwachen muss). Um kein eigenes Relay betreiben zu müssen bietet es sich z.B. an den Simple E-Mail Service (SES) von Amazon zu verwenden. Dann muss man nur die SES E-Mail Server von Amazon AWS zusätzlich in die SPF Liste der Absenderdomain aufnehmen. Dies ist hier beschrieben: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPF.html. Im Gegensatz zum kompletten IP-Subnetz von Amazon EC2 hat man bei dieser Vorgehensweise den Vorteil, dass Amazon ein hohes Interesse daran hat, dass nur autorisierte Benutzer die Absenderadresse verwenden. (Gleiches gilt übrigens auch für Google App Engine, hier kann man auch Mail Relays in die SPF Liste aufnehmen). Zudem kann man sich danke Amazon IAM ein Benutzername/Passwort erzeugen der außer dem E-Mail Versand keine weiteren Rechte hat. Dieser kann man dann bedenkenlos im EC2 Image hinterlegen - zumindest solange man dieses nicht mit anderen Amazon Anwendern teilt. Sonst bietet es sich eher an diese Credentials beim Start mit anzugeben. Im nächsten Post beschreibe ich, wie man bei einem AMI auf Basis von Amazon Linux diese Varianten realisieren kann.