Postfix auf Mac einrichten
Einstellungen bei verschiedenen Anbietern
Googlemail
Die Konfigurationsanleitung für IMAP gilt auch für den Fall, dass Sie einen anderen als die aufgelisteten Clients verwenden. Wenden Sie sich bei Problemen an den Support für Ihren E-Mail-Client und erbitten Sie eine genaue Anleitung.
Posteingangsserver (IMAP) – SSL erforderlich: imap.gmail.com Port: 993 SSL erforderlich: Ja Postausgangsserver (SMTP) – TLS erforderlich: smtp.gmail.com Port: 465 oder 587 SSL erforderlich: Ja Authentifizierung erforderlich: Ja Gleiche Einstellungen wie für den Posteingangsserver verwenden Vollständiger Name oder Anzeigename: [Ihr Name] Konto- oder Nutzername: Ihre vollständige Gmail-Adresse (nutzername@gmail.com). Google Apps-Nutzer geben bitte nutzername@ihre_domain.de ein. E-Mail-Adresse: Ihre vollständige Gmail-Adresse (nutzername@gmail.com). Google Apps-Nutzer geben bitte nutzername@ihre_domain.de ein. Passwort: Ihr Gmail-Passwort
E-Mail auf all-inkl
DNS Einträge für Outlook Exchange konfigurieren
Für Exchange, Office 365 etc. benötigt man DNS Einträge hier gibts mehr Info:
All-inkl
Konfiguration für SSL
Die Zertifikate sind auf kasserver.com ausgestellt, deshalb muß man für sichere Übertragung die richtigen Daten verwenden um Zertifikatsfehler zu vermeiden. Der Mailserver für IMAP und POP3 heißt dann:
accountname.kasserver.com korockt.kasserver.com ...
Mails aus Thunderbird exportieren
Für Updates kann man einfach die Ordnerstruktur in der die Mails liegen kopieren und wieder in der neuen Version abspeichern. Bei neueren Versionen funktioniert das Update automatisch.
Export nach Outlook Express
- Die betreffenden Mails als Anhang an sich selbst weiterleiten (die Mails werden dabei als *.eml Files in den Anhang gepackt.)
- Im Outlook Express die Mail herunterladen. Die Anhänge in einen beliebigen Mailordner ziehen - fertig. Die Mails enthalten alle Daten auch die Header-Daten. Wenn es Zugriffs-Probleme gibt einfach die Mails kurz auf der Festplatte zwischenspeichern, und erst danach in den Mailordner ziehen.
Grundsätzlicher Ablauf einer Mailübertragung
von: http://www.lrz-muenchen.de/services/netzdienste/email/empfang/ (14.7.2006) Um zu verstehen, was im DNS konfiguriert werden muß und weshalb, soll zuerst der Ablauf der Übertragung einer Mail beschrieben werden.
Jede Mailadresse besteht aus zwei Teilen, dem lokalen Teil links vom '@'-Zeichen und der Domain rechts davon. Die Domain bestimmt das Routing, d.h. den Weg vom Mailserver des Absenders zum Mailserver des Empfängers. Der linke Teil bestimmt, was der empfangende Mailserver mit der Mail machen soll. In der Regel wird er die Mail an eine lokal vorhandene Mailbox ausliefern.
Der sendende Mailserver muß feststellen, an welchen Rechner er die Mail schicken muß. Dies kann bereits der Zielrechner sein, auf dem sich die Mailbox befindet, oder ein erster Rechner auf dem Weg zum Zielrechner (store-and-forward-Prinzip). Die notwendige Information bekommt er entweder aus einer internen Konfiguration - für uns hier nicht weiter interessant - oder aus dem DNS.
Im DNS gibt es verschiedene Arten von Einträgen - sogenannte Resource Records -, bei denen einem Domainnamen bestimmte Informationen zugeordnet sind. Bei der Abfrage des DNS gibt man den Domainnamen und den Typ des Eintrags an und bekommt die zugehörige Information geliefert. Unter einem Domainnamen kann man verschiedene Dinge verstehen.
Beim Mailversand spielen drei Typen von Einträgen eine Rolle:
* A-Record: zu einem Domainnamen (Rechner) wird die zugehörige IP-Adresse ausgegeben. Besitzt ein Rechner mehrere IP-Adressen, so gibt es entsprechend viele A-Records zum Domainnamen. * MX-Record: zu einem Domainnamen wird der zugehörige Mailserver ausgegeben. Meistens sind mehrere MX-Records zu einem Domainnamen konfiguriert. Zur Unterscheidung besitzt jeder MX-Record eine Priorität (kleine Zahl = große Priorität). Der MX-Record mit der höchsten Priorität ist der eigentliche Zielrechner, auf dem sich die Mailboxen befinden, die anderen MX-Records bezeichnen die Backup-Rechner für den Fall, daß der eigentliche Zielrechner nicht erreicht werden kann. Sie speichern die Mails nur temporär und versuchen periodisch die Mail an den eigentlichen Zielrechner weiterzuleiten. * CNAME-Record: der Domainname ist ein Alias für den angegebenen Rechner. Dieser Eintrag wird für Mail kaum verwendet und daher im folgenden nicht weiter betrachtet (sollten Sie aber so einen Eintrag zum Mailempfang verwenden, wenden Sie sich bitte an Herrn Spirk, spirk@lrz.de, damit er Ihnen bei der Migration helfen kann).
Ablauf einer Mailübertragung (soweit es hier interessiert):
* Der sendende Mailserver fragt im DNS nach den MX-Records für die Domain in der Mailadresse. * Gibt es keinen MX-Record, so wird die Existenz eines MX-Records mit Priorität 0 angenommen, der auf die nachgefragte Domain zeigt (in der Praxis heißt dies, der Domainname ist der Zielrechner, zu dem eine Verbindung aufgebaut werden muß). * Gibt es MX-Records, so werden diese nach Priorität sortiert. Zeigt einer der MX-Records auf den anfragenden Mailserver selbst, so wird dieser MX-Record und alle anderen gleicher oder niedrigerer Priorität ignoriert und nur die MX-Records mit höherer Priorität beachtet. * Für den Rechner aus dem MX-Record mit der höchsten Priorität wird eine Anfrage nach dem A-Record und damit nach der IP-Adresse des Rechners gestellt. Dieser A-Record muß existieren, sonst ist kein Mailaustausch möglich. * Zu dieser IP-Adresse wird eine Verbindung aufgebaut und die Mail übertragen. * Kann zu der IP-Adresse keine Verbindung aufgebaut werden, so wird der MX-Record mit der nächstniedrigeren Priorität genommen, der A-Record abgefragt und die Verbindung aufgebaut (Backup-Fall). * Kommt zu keinem der Rechner aus den MX-Records eine Verbindung zustande, so bleibt die Mail am absendenden Mailserver liegen und der ganze Ablauf beginnt nach einiger Zeit von neuem.
Was bedeutet dies nun, wenn z.B. eine Mail von einem Mailserver aus dem Internet an die Mailadresse xyz@vetmed.uni-muenchen.de geschickt werden soll? Im DNS seien folgende MX- und A-Records eingetragen:
Domainname Typ Prio Wert vetmed.uni-muenchen.de MX 10 cip-tf2.cip.vetmed.uni-muenchen.de vetmed.uni-muenchen.de MX 20 mailrelay1.lrz-muenchen.de vetmed.uni-muenchen.de MX 30 mailrelay2.lrz-muenchen.de
cip-tf2.cip.vetmed.uni-muenchen.de A 141.84.176.126 mailrelay1.lrz-muenchen.de A 129.187.254.101 mailrelay2.lrz-muenchen.de A 129.187.254.102
* Der sendende Mailserver bekommt auf Nachfrage im DNS diese drei MX-Records. * Der MX-Record mit der höchsten Priorität zeigt auf cip-tf2.cip.vetmed.uni.lrz-muenchen.de. Der sendende Mailserver versucht daher zu diesem Rechner eine Verbindung aufzubauen. Da cip-tf2.cip.vetmed.uni.lrz-muenchen.de nicht zu den im MHN zugelassenen Mailrelays gehört, wird die Verbindung am Router zwischen B-WiN und MHN blockiert. * Der MX-Record mit der nächst niedrigeren Priorität zeigt auf den Mailrelay mailrelay1.lrz-muenchen.de, der als Backup dient. Der Verbindungsaufbau kommt zustande, da mailrelay1.lrz-muenchen.de im Gegensatz zu cip-tf2.cip.vetmed.uni.lrz-muenchen.de zu den zugelassenen Mailrelays gehört, und so kann die Mail übertragen werden. * mailrelay1.lrz-muenchen.de stellt fest, daß die Mail nicht lokal ausgeliefert, sondern an einen anderen Rechner weitergeleitet werden soll. * Er holt sich ebenfalls die drei MX-Records. * Da der zweite MX-Record auf ihn selbst zeigt, verwirft er diesen und - wegen der noch niedrigeren Priorität- auch den dritten und behält nur den ersten MX-Record. * Er versucht eine Verbindung zu cip-tf2.cip.vetmed.uni.lrz-muenchen.de aufzubauen und die Mail zu übertragen. Dies gelingt, da sich die Mail bereits im MHN befindet und sich der Filter am Router nicht mehr auswirkt.
Daraus folgt, daß in Zukunft für jede Domain, für die Mail empfangen werden soll, mindestens 2 MX-Records existieren müssen. Dies gilt auch für den Mailserver, selbst wenn zur Zeit kein MX-Record für ihn definiert ist und alle E-Mails über den Domainnamen des Mailserver abgewickelt werden. Als Mailserver gelten in diesem Fall alle Rechner, auf denen sendmail oder ein ähnliches Programm zum Mailempfang/versand läuft.
Für cip-tf2.cip.vetmed.uni.lrz-muenchen.de sollten daher noch die folgenden MX-Records eingetragen werden:
Domainname Typ Prio Wert cip-tf2.cip.vetmed.uni-muenchen.de MX 10 cip-tf2.cip.vetmed.uni-muenchen.de cip-tf2.cip.vetmed.uni-muenchen.de MX 20 mailrelay1.lrz-muenchen.de cip-tf2.cip.vetmed.uni-muenchen.de MX 30 mailrelay2.lrz-muenchen.de
Der MX-Record mit der höchsten Priorität zeigt auf den eigentlichen Mailserver, auf dem die Mailboxen liegen. Der MX-Record mit niedriger Priorität zeigt auf eines der Mailrelays, über den der direkte Empfang aus dem Internet abgewickelt wird. Zur Sicherheit sollte noch ein dritter MX-Record auf einen weiteren Mailrelay zeigen, damit bei Ausfall des ersten Mailrelays als Backup das zweite zur Verfügung steht.
Befinden sich die Mailboxen zu einer Domain auf dem Mailboxserver des LRZ (mailin.lrz-muenchen.de), so gibt es nur die zwei MX-Records auf die beiden Mailrelays mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de. Es darf kein MX-Record auf den Mailboxserver zeigen. E-Mails gelangen von den Mailrelays zum Mailboxserver über eine interne Kopplung. Es sind in diesem Fall also nur 2 MX-Records definiert:
Domainname Typ Prio Wert jura.uni-muenchen.de MX 20 mailrelay1.lrz-muenchen.de jura.uni-muenchen.de MX 30 mailrelay2.lrz-muenchen.de
Was ist also zu tun? Es muß
1. festgelegt werden, über welche(n) Mailrelay(s) Mails empfangen werden sollen und 2. die entsprechende Konfiguration im DNS durchgeführt werden.
Daraus ergeben sich die folgenden Arbeitsschritte:
1. Überprüfung, ob es bereits MX-Records im DNS gibt:
* Stellen Sie fest, ob für Ihre Maildomain bereits MX-Records im DNS definiert sind, unter Unix z.B. mit nslookup -q=mx maildomain (s.a. nslookup auf LRZ-Nameserver)
* Zeigt einer der MX-Records bereits auf eines oder mehrere der Mailrelays (s. obige Tabelle), so sind Sie bereits fertig.
* Zeigt einer der MX-Records auf sunsrv5.lrz-muenchen.de (s. obiges Beispiel für jura.uni-muenchen.de) oder vielleicht sogar noch auf cd1.lrz-muenchen.de, so müssen diese Einträge auf die Mailrelays mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de geändert werden, s. weiter unten.
* Gibt es keinen MX-Record oder zeigt dieser nicht auf eines der Mailrelays, so muß ein Mailrelay ausgesucht werden.
2. Auswahl eines Mailrelays
* Gibt es in Ihrer Fakultät bereits ein Mailrelay, so bietet sich dieses an.
* Arbeiten Sie eng mit einer anderen Fakultät zusammen, die ein Mailrelay hat, so wäre dies eine weitere Möglichkeit.
* In jedem Fall ist es möglich, die zentralen Mailrelays des LRZ zu nutzen. Lassen Sie hierfür zwei MX-Records auf mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de eintragen, wobei die Priorität für mailrelay1.lrz-muenchen.de höher als die Priorität für mailrelay2.lrz-muenchen.de sein soll.
* Denken Sie bei der Auswahl an die Betriebsregeln des Mailrelays (neudeutsch: Policy). Hier gibt es Unterschiede, z.B. welche Mails von woher akzeptiert werden, wie sie weiterverarbeitet werden usw. So kann unter anderem die Größe der akzeptierten Mails unterschiedlich sein:
o srv.cip.physik.tu-muenchen.de akzeptiert 4 MByte große Mails
o die zentralen Relays des LRZ 20 MByte
o charly.bl.physik.tu-muenchen.de 100 MByte
o und die anderen Rechner aus obiger Liste haben bisher keine Größenbeschränkung.
Die Mail-Policy für die zentralen Mailrelays des LRZ finden sie unter http://www.lrz-muenchen.de/services/netzdienste/email/policy Vereinbarung mit dem Administrator des Mailrelays
3.
* Sprechen Sie zuerst mit dem Administrator des ausgesuchten Mailrelays, ob er bereit ist, Mails an Ihre Domain über sein Mailrelay zu leiten. Eventuell muß sein Mailrelay umkonfiguriert werden, damit er Mails für Ihre Domain auch entgegennimmt und nicht als unerwünschten Relay-Versuch ablehnt.
* Wollen Sie die Mails über die LRZ-Mailrelays leiten, so können Sie das jederzeit tun. Sie müssen nur dann mit uns Kontakt aufnehmen, wenn Ihre Maildomain keine Subdomain der von uns zur Zeit konfigurierten Domains ist, für die wir Mails akzeptieren. Mails an andere Domains werden als unerwünschter Relay-Versuch abgelehnt:
akzeptierte Domains
badw-muenchen.de
badw.de
isb.bayern.de
fh-muenchen.de
fh-weihenstephan.de
ku-eichstaett.de
lrz-muenchen.de
lrz.de
mgh.de
mhn.de
tu-muenchen.de
tum.de
uni-muenchen.de
weihenstephan.de
4. Konfiguration des DNS, Vereinbarung mit dem Administrator der DNS-Zone
* Nachdem Sie den zuständigen Mailserver festgelegt haben (und mit dem zuständigen Mailadministrator gesprochen haben), muß noch die Konfiguration im DNS erfolgen. Zuerst müssen Sie herausfinden, wer die Daten für Ihre Maildomain im DNS verwaltet, unter Unix z.B. durch nslookup -q=soa domainname. Gibt es dazu keine Antwort, müssen Sie die erste Subdomain auf der linken Seite streichen und erneut eine Abfrage stellen. Unter origin findet sich der Rechner, auf dem die DNS-Zone, d.h. die Daten für Ihre Domain verwaltet werden, und unter mail addr die Adresse des Administrators (der erste '.' muß durch ein '@' ersetzt werden).
* Nehmen Sie Kontakt mit diesem Administrator auf und lassen Sie MX-Records anhand obiger Erläuterung bzw. Beispiele eintragen, also einen auf Ihren Mailrechner und einen oder zwei auf die ausgesuchten Mailrelays. Denken Sie daran, daß sunsrv5.lrz-muenchen.de oder cd1.lrz-muenchen.de durch mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de ersetzt werden müssen.
* Werden die Daten vom DNS-Server des LRZ verwaltet, d.h.
o origin ist dfvgate.lrz-muenchen.de und
o mail addr ist hostmaster@lrz-muenchen.de und
o die MX-Records zeigen auf sunsrv5.lrz-muenchen.de,
so müssen Sie nichts tun. Wir stellen die MX-Records selbstständig auf mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de um. Im anderen Fall - also insbesondere für das erstmalige Eintragen von MX-Records - wenden Sie sich bitte an hostmaster@lrz-muenchen.de mit der Bitte eines Eintrags für Ihre Maildomain.
E-Mail - Betreff und Inhaltstext automatisch befüllen
Link auf der Webseitet öffnet E-Mail Programm und füllt Inhalte aus
<a href="mailto:name@domain.de?subject=Betreff&body=inhalt">Link</a>
HTML Inhalte für Versand über URL vorbereiten / enkodieren
Einige Sonderzeichen können nicht einfach über den body parameter in der URL versendet werden. Deshalb müssen die Inhalte zuerst kodiert werden.
PHP
urlencode() urldecode() rawurlencode() rewurldecode()
Hierbei wandelt rawurlencode zusätzlich das Leerzeichen um. Bei Kompatibilitätsproblemen kann man es mit dem älteren urlencode probieren.
Beispiel
<?php
echo urlencode ("Übertragener Wert: Ä");
?>
Ergebnis:
%DCbertragener+Wert%3A+%C4
JavaScript
Beispiel
var myEncodedUrl = "http://example.com/index.html?url=" + encodeURIComponent(myUrl);
Zu Beachten:
encodeURI() enkodiert nicht:
: ~!@#$&*()=:/,;?+'
encodeURIComponent() enkodiert nicht:
~!*()'
Quelle: http://stackoverflow.com/questions/332872/how-to-encode-a-url-in-javascript (Zugriff 2012-12)
Probleme lösen
iPhone
E-Mail wurde vom Server abgelehnt, da das weiterleiten unzulässig ist.
-> Ausgangsserver nicht auf Optional lassen sonst nimmt er manchmal die falschen daten.
