Was passiert, wenn SMTP-Server nicht online ist bzw. gerade mal rekonnected
Markus Gronotte
Was passiert eigentlich, wenn mein SMTP-Server nicht online ist bzw.
gerade mal reconnected. Machen Anbieter wie GMX dann neue Zustellversuche
oder was passiert dann. Oder kommt die Mail dann einfach nicht an?
lg,
Markus
Felix M. Palmen
* Markus Gronotte <mar...@gronoworx.dyndns.org>:
> Was passiert eigentlich, wenn mein SMTP-Server nicht online ist bzw.
> gerade mal reconnected. Machen Anbieter wie GMX dann neue Zustellversuche
> oder was passiert dann. Oder kommt die Mail dann einfach nicht an?
Kommt auf die Retry-Konfiguration des Senders an. Ein vernünftig
konfigurierter MTA wird es wieder versuchen. Falls das hinreichend oft
nicht klappt (ebenfalls Konfigurationssache) wird ein Bounce an den
Absender zurückgeschickt.
Grüße, Felix
--
| /"\ ASCII Ribbon | Felix M. Palmen (Zirias) http://zirias.ath.cx/ |
| \ / Campaign Against | f...@palmen.homeip.net encrypted mail welcome |
| X HTML In Mail | PGP key: http://zirias.ath.cx/pub.txt |
| / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 |
Markus Gronotte
"Felix M. Palmen"
Hi,
Danke für die Info.
> Kommt auf die Retry-Konfiguration des Senders an. Ein vernünftig
> konfigurierter MTA wird es wieder versuchen. Falls das hinreichend oft
> nicht klappt (ebenfalls Konfigurationssache) wird ein Bounce an den
> Absender zurückgeschickt.
Das heißt also prinzipiell kann ich davon ausgehen, dass eine
Fehlerbenachrichtigung im Falle einer Unzustellbarkeit eigentlich
_immer_ an den Versender zurückgeschickt wird?
Kann man Ausnahmen zu erwarten? Eigentlich nur extrem selten oder?
lg,
Markus
Felix M. Palmen
* Markus Gronotte <mar...@gronoworx.dyndns.org>:
> Kann man Ausnahmen zu erwarten? Eigentlich nur extrem selten oder?
Mailserver, die im Fehlerfall keine Bounces verschicken, habe ich noch
nicht erlebt. Es wäre aber denkbar, dass durch einen dummen Zufall auch
der Bounce nicht ankommt :)
Nils Ketelsen
> Das heißt also prinzipiell kann ich davon ausgehen, dass eine
> Fehlerbenachrichtigung im Falle einer Unzustellbarkeit eigentlich
> _immer_ an den Versender zurückgeschickt wird?
Meine Kristallkugel sagt: Du willst einen SMTP-Server an deiner DSL-Flatrate
mit dynamischer Adresse betreiben und DynDNS nutzen.
> Kann man Ausnahmen zu erwarten? Eigentlich nur extrem selten oder?
Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
oder beliebige Caches noch die alte Adresse haben und derjenige, der sie
jetzt hat Mails annimmt (es gibt so schoene Sachen wie nimm Mails an, wenn
DNS sagt, dass Du selber lowest MX bist, was dann ja der Fall ist). Dann hat
derjenige eben die Mail von Deiner Freundin, macht das Date klar und Du
kannst mit Deiner Flatrate zu Booble surfen und auf Handbetrieb umschalten.
Mersatz:
Hast Du DYN-IP und Mailserver dahinter,
steigst in ein kaltes Bett Du im Winter.
Nils
--
This message will self-destruct after the default expiration-time.
Joern Bredereck
> Mersatz:
> Hast Du DYN-IP und Mailserver dahinter,
> steigst in ein kaltes Bett Du im Winter.
grundsätzlich stimmt das. Aber du solltest dem OP auch nicht
verschweigen, daß es dafür hinreichend Workarounds (VPN, SMTP-TLS, MX
auf einem andern TCP-Port) gibt. Das setzt natürlich jeweils voraus,
dass der Primary-MX der entsprechenden Domain diese spielchen mitmacht.
Gruß,
Jörn
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Meine Kristallkugel sagt: Du willst einen SMTP-Server an deiner DSL-Flatrate
> mit dynamischer Adresse betreiben und DynDNS nutzen.
Ist eine Möglichkeit und eine praktische Sache.
>> Kann man Ausnahmen zu erwarten? Eigentlich nur extrem selten oder?
>
> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
> oder beliebige Caches noch die alte Adresse haben
dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt. TTL sind
60 Sekunden, Caches fragen also wieder nach.
> und derjenige, der sie jetzt hat Mails annimmt (es gibt so schoene
> Sachen wie nimm Mails an, wenn DNS sagt, dass Du selber lowest MX
> bist, was dann ja der Fall ist). Dann hat derjenige eben die Mail von
> Deiner Freundin, macht das Date klar und Du kannst mit Deiner Flatrate
> zu Booble surfen und auf Handbetrieb umschalten.
Die Wahrscheinlichkeit, dass im Zeitfenster von 60 Sekunden jemand die
IP-Adresse bekommt, der außerdem einen SMTP-Server betreibt, der alles
annimmt, möchtest du sicher gerne mal ausrechnen. Also bitte,
realistisch bleiben.
Nils Ketelsen
>> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
>> oder beliebige Caches noch die alte Adresse haben
> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt. TTL sind
> 60 Sekunden, Caches fragen also wieder nach.
Und Deine Leitung faellt nie aus?
> Die Wahrscheinlichkeit, dass im Zeitfenster von 60 Sekunden jemand die
> IP-Adresse bekommt, der außerdem einen SMTP-Server betreibt, der alles
> annimmt, möchtest du sicher gerne mal ausrechnen. Also bitte,
> realistisch bleiben.
Die Annahme alles waere immer so wie meistens, ist einer der haeufigsten
Fehler im IT Umfeld. Leitungsausfaelle? Der Bot der die dyndns updates
annimmt faellt aus? dyndns von Dir aus nicht zu erreichen, aber mailabsender
koennen noch (z.B. weil Dein provider das routing zu dyndns verbaselt hat)?
Caches die sich nicht an die TTL halten, um die Systemlast von eben solchen
Anbietern wie dyndns niedrig zu halten? Ausfall Deines Rechners, und somit
keine Moeglichkeit dyndns updates zu machen? Stromausfall, weil die
Haupsicherung Dank Deines neuen Toasters rausgeflogen ist?
Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
Operations taetig wirst. Alles selber erlebt, ausser dem Toaster (bei uns
war es jemand, der einen Staubsauger in die USV stoepselte und damit eine
Phase lahmlegte).
Nils
--
15:37 <@Zugschlus> $FLUCH
15:37 <@range> "Möge dir der Weihnachtsmann mit den Kufen seines Schlittens
über die Füße fahren!"
Felix M. Palmen
> Und Deine Leitung faellt nie aus?
Tut sie. (selten genug). In mittlerweile über 2 Jahren hat das zu keinem
bekannt gewordenen Verlust von Mails geführt. Auch wenn du das
vielleicht nicht verstehen kanns, aber damit bin ich absolut zufrieden.
> Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
> Operations taetig wirst.
Du hast dich soeben als ernstzunehmender Diskussionspartner
disqualifiziert.
Thomas Hochstein
> Was passiert eigentlich, wenn mein SMTP-Server nicht online ist bzw.
> gerade mal reconnected. Machen Anbieter wie GMX dann neue Zustellversuche
> oder was passiert dann.
Normalerweise wird bis zu vier Tagen lang in ständig größer werdenden
Abständen eine erneute Zustellung versucht.
> Oder kommt die Mail dann einfach nicht an?
Danach geht die Mail als unzustellbar an den Absender zurück.
Ein Problem bekommst Du aber, wenn jemand anderes online geht und die
IP bekommt, die Du vorher hattest. Dann wird nämlich versucht, die
Mail an ihn zuzustellen. Bestenfalls geht das nicht und sie geht
direkt als unzustellbar zurück, was nur zu Verwirrung führt;
schlimmstenfalls nimmt er sie an und hat dann Deine Mail.
Nils hat das im Ergebnis sehr schön und poetisch formuliert. Das kann
ich nur unterschreiben. :)
-thh
--
Informationsschnippsel rund um E-Mail: <http://th-h.de/infos/email/>
E-Mail-Header lesen und verstehen: <http://th-h.de/faq/headerfaq.php>
Joern Bredereck
>>Meine Kristallkugel sagt: Du willst einen SMTP-Server an deiner DSL-Flatrate
>>mit dynamischer Adresse betreiben und DynDNS nutzen.
>
>
> Ist eine Möglichkeit und eine praktische Sache.
ja, aber nur wenn man die Verbindung enstprechend über ein VPN oder
andere Authentifizierungsmechnismen aufbohrt.
> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt. TTL sind
> 60 Sekunden, Caches fragen also wieder nach.
sollten sie, tun sie aber leider nicht immer. Darauf kannst du dich also
absolut nicht verlassen.
> Die Wahrscheinlichkeit, dass im Zeitfenster von 60 Sekunden jemand die
> IP-Adresse bekommt, der außerdem einen SMTP-Server betreibt, der alles
> annimmt, möchtest du sicher gerne mal ausrechnen. Also bitte,
> realistisch bleiben.
ich muss nichts ausrechnen, um die Wahrscheinlich zu ermitteln. Ich kann
einfach aus Erfahrung sprechen. Wir routen momentan etwa 40 Kunden die
Mails per DSL-Dialups ins haus und daher bekomme ich ziemlich genau mit,
wann es mit DynDNS zu Problemen kommt. In den letzten paar Jahren war
z.B. der Anbieter dyndns.org ein paar mal komplett ausgfallen (die
veralteten IPs standen aber noch in den Caches der Resolver).
Regelmässige T-DSL-Leitungsprobleme sind auch an der Tagesordnung.
DynDNS-Clients machen auch nicht immer das was sie sollen. Wenn wir uns
also blind darauf verlassen würden, dass unsere Kunden immer die
richtige IP im DynDNS hinterlegt haben, dann hätten wir schon so manches
mal die Mails zum falschen SMTP-Server geroutet.
Aus diesem Grund baut unser Gateway vor dem SMTP-Übertragung ein VPN zum
Router des Kunden auf (auf Basis der DynDNS-Adresse). Erst wenn die
IPSec-Verbindung korrekt aufgebaut werden konnte, kann unser MX die
Mails für unsere Kunden an den dortigen DynDNS-MX weiterleiten. Anstelle
eines VPNs könnte man wohl auch eine TLS-SMTP-Verbindung benutzen, aber
das haben wir bislang noch nicht erprobt. Das VPN hat noch ein paar
andere Vorteile.
Ein Szenario, wie du es vorschlägst ist daher als fahrlässig zu
bezeichnen. Es ist nur eine Frage der Zeit, bis die ersten Mails zum
falschen SMTP-Server geschickt werden.
Gruß,
Jörn Bredereck
Rolf Eike Beer
[MX und DynDNS]
> Die Wahrscheinlichkeit, dass im Zeitfenster von 60 Sekunden jemand die
> IP-Adresse bekommt, der außerdem einen SMTP-Server betreibt, der alles
> annimmt, möchtest du sicher gerne mal ausrechnen. Also bitte,
> realistisch bleiben.
Die IP-Adressen werden AFAIK erst nach einem gewissen Intervall wieder
vergeben, in den 60 Sekunden ist dann halt schlicht niemand zu erreichen
-> Mail bleibt in der Absender-Queue.
Ingo Buescher
Stichwort: reconnected. Hast du bei deinem SMTP Server nur eine
dynamische Adresse zur Verfuegung und willst den Server mit
z.B. dyndns.org realisieren? Dann kann es auch noch passieren, dass
mails dann an die alte IP zugestellt und dort dann auch gelesen
werden, falls du noch nicht die neue schon bei dyndns.org registriert
hast.
> Markus
Ingo
--
===========================================================================
Ingo Buescher <de.comm.software.mailserver>
printk(KERN_ERR "msp3400: chip reset failed, penguin on i2c bus?\n");
2.2.16 /usr/src/linux/drivers/char/msp3400.c
Markus Gronotte
"Nils Ketelsen"
> Meine Kristallkugel sagt: Du willst einen SMTP-Server an deiner DSL-Flatrate
> mit dynamischer Adresse betreiben und DynDNS nutzen.
Exakto
>> Kann man Ausnahmen zu erwarten? Eigentlich nur extrem selten oder?
> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
> oder beliebige Caches noch die alte Adresse haben und derjenige, der sie
> jetzt hat Mails annimmt (es gibt so schoene Sachen wie nimm Mails an, wenn
> DNS sagt, dass Du selber lowest MX bist, was dann ja der Fall ist). Dann hat
> derjenige eben die Mail von Deiner Freundin, macht das Date klar und Du
> kannst mit Deiner Flatrate zu Booble surfen und auf Handbetrieb umschalten.
Ah. Darüber dass SMTP-Empfang Passwortlos vor sich geht, da hab ich noch gar nicht
so drüber nachgedacht. Aber die Wahrscheinlichkeit, dass die andere IP
einen SMTP-Server betreibt ist dennoch eher gering. Ich denke das Risiko
kann ich eingehen. Die Dyndns-Addi soll sowieso eher als Spamfänger fungieren.
Danke auch für alle anderen Antworten der anderen.
lg,
Markus - http://gronoworx.dyndns.org
Felix M. Palmen
* Joern Bredereck <j...@bw-networx.net>:
> Ein Szenario, wie du es vorschlägst ist daher als fahrlässig zu
> bezeichnen. Es ist nur eine Frage der Zeit, bis die ersten Mails zum
> falschen SMTP-Server geschickt werden.
Nein.¹ Es besteht ein theoretisches Risiko. Die Chance, dass auf diese
Art eine Mail auf einem anderen Rechner landet ist extrem gering. Schon
die Chance, dass überhaupt ein Rechner mit SMTP-Server die IP-Adresse
bekommen kann ist gering, dass er dann auch noch Mail an meinen
dyndns-hostnamen annimmt ist nochmal extrem unwahrscheinlich. Jetzt
multipliziere zwei Zahlen <<1.
Das Risiko ist da, wird aber von dir und anderen hochgradig übertrieben.
Ich habe es wie gesagt privat so konfiguriert und in der Hauptsache
haben hier 3 Leute ihre email-Adresse. Das läuft schon seit Jahren so
und es hat sich noch nie jemand über den Verbleib einer Email gewundert.
Was sensible Informationen angeht, die schickt sowieso kein vernünftiger
Mensch unverschlüsselt per Email.
Grüße, Felix
¹ Oder vielleicht doch, mit einem Erwartungswert von rund 10000 Jahren
für das erste derartige Vorkommnis ;)
Thomas Schweikle
> Felix M. Palmen <zir...@despammed.com> wrote:
>
>>> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
>>> oder beliebige Caches noch die alte Adresse haben
>> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt. TTL sind
>> 60 Sekunden, Caches fragen also wieder nach.
>
> Und Deine Leitung faellt nie aus?
>
>> Die Wahrscheinlichkeit, dass im Zeitfenster von 60 Sekunden jemand die
>> IP-Adresse bekommt, der außerdem einen SMTP-Server betreibt, der alles
>> annimmt, möchtest du sicher gerne mal ausrechnen. Also bitte,
>> realistisch bleiben.
>
> Die Annahme alles waere immer so wie meistens, ist einer der haeufigsten
> Fehler im IT Umfeld. Leitungsausfaelle? Der Bot der die dyndns updates
> annimmt faellt aus? dyndns von Dir aus nicht zu erreichen, aber mailabsender
> koennen noch (z.B. weil Dein provider das routing zu dyndns verbaselt hat)?
> Caches die sich nicht an die TTL halten, um die Systemlast von eben solchen
> Anbietern wie dyndns niedrig zu halten? Ausfall Deines Rechners, und somit
> keine Moeglichkeit dyndns updates zu machen? Stromausfall, weil die
> Haupsicherung Dank Deines neuen Toasters rausgeflogen ist?
:)
> Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
> Operations taetig wirst. Alles selber erlebt, ausser dem Toaster (bei uns
> war es jemand, der einen Staubsauger in die USV stoepselte und damit eine
> Phase lahmlegte).
Es soll auch schon Leute gegeben haben, die den Lichtschalter und
den Alarmknopf verwechselten. Dadurch wurde der Strom abgeschaltet,
und die Rechnerzelle mit CO2 geflutet. Bis die Klimaanlage das CO2
wieder aus der RZ heraus hat dauert 2 Stunden. Bis alle Rechner
wieder liefen dauerte es zwei Tage --- schön, das es noch ein
Backup-RZ gab. Sonst hätte diverse Leute zimlich geflucht: "Leider
steht dieser Bankautomat zur Zeit nicht zur Verfügung".
--
Thomas
Thomas Schweikle
> * Nils Ketelsen <ni...@steering-group.net>:
>> Und Deine Leitung faellt nie aus?
>
> Tut sie. (selten genug). In mittlerweile über 2 Jahren hat das zu keinem
> bekannt gewordenen Verlust von Mails geführt. Auch wenn du das
> vielleicht nicht verstehen kanns, aber damit bin ich absolut zufrieden.
>
>> Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
>> Operations taetig wirst.
>
> Du hast dich soeben als ernstzunehmender Diskussionspartner
> disqualifiziert.
Nein, hat er nicht. Ich habe genau das Problem zur Zeit häufiger.
Ursache: der Mailserver beim ISP ist nicht immer erreichbar. Ursache
dafür:
a) irgendwo spinnt ein Router
b) der Mailserver ist etwas "überlastet".
Versuche mit einem eigenen Mail- (und Terminkalender-Server) endeten
mit fast 25% Mail, die nicht zugestellt werden konnten.
In zwei von 100 Fällen landeten die Mail auf dem falschen Computer.
praktisch, das sie verschlüsselt waren, und so nicht für jeden lesbar.
"Sag' niemals nie!"
Es mag für dich zur Zeit nicht zutreffen, aber es ist ein Szenario,
das nicht für jeden so glücklich ablauft!
--
Thomas
Matthias Andree
> Hallo Joern,
>
> * Joern Bredereck <j...@bw-networx.net>:
>> Ein Szenario, wie du es vorschlägst ist daher als fahrlässig zu
>> bezeichnen. Es ist nur eine Frage der Zeit, bis die ersten Mails zum
>> falschen SMTP-Server geschickt werden.
>
> Nein.¹ Es besteht ein theoretisches Risiko. Die Chance, dass auf diese
> Art eine Mail auf einem anderen Rechner landet ist extrem gering. Schon
> die Chance, dass überhaupt ein Rechner mit SMTP-Server die IP-Adresse
> bekommen kann ist gering, dass er dann auch noch Mail an meinen
> dyndns-hostnamen annimmt ist nochmal extrem unwahrscheinlich. Jetzt
> multipliziere zwei Zahlen <<1.
Mailserver auf dynamischer IP-Adresse sind, aus der Erfahrung mit
Mailinglisten, als SMTP-Server ziemlich unbefriedigend.
Wenn jemand einen Honigtopf hinstellt, ist der SMTP-Client in der
Blacklist und die Mail weg.
Schließlich ist das Gezeter groß, wenn die Mail dann doch versäuft.
> Das Risiko ist da, wird aber von dir und anderen hochgradig übertrieben.
> Ich habe es wie gesagt privat so konfiguriert und in der Hauptsache
> haben hier 3 Leute ihre email-Adresse. Das läuft schon seit Jahren so
> und es hat sich noch nie jemand über den Verbleib einer Email gewundert.
"Was ich nicht sehe, existiert auch nicht."?
--
Matthias Andree
Felix M. Palmen
* Urs Janßen <u...@akk.org>:
> In <N3e8I41e5...@nexus.palmen.homeip.net>, Felix M. Palmen wrote:
>> > Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
>> > Operations taetig wirst.
>> Du hast dich soeben als ernstzunehmender Diskussionspartner
>> disqualifiziert.
>
> nicht wirklich - wer mailserver an solchen konstrukten betreibt muss
> mit mailverlust rechnen. fuer privat personen mag das (geringe)
> risiko tragbar sein, fuer firmen ist es das normalerweise nicht. wer
> das nicht sieht hat in der branche nix verloren - ausser seinen
> arbeitsplatz wenn es mal rummst obwohl das ja garnicht moeglich ist.
Solche Dinge /werden/ privat gemacht und das Risiko von Mailverlust
dadurch ist /sehr/ gering. Welche Firma, die einen Admin bezahlt, sollte
an einem Mailserver auf einem dnamischen Host interessiert sein?
Ich weiß jedenfalls was ich tue. Wie man es auch dreht, das Risiko, dass
eine Mail woanders hinläuft ist eben sehr gering und mir wegen dieser
Aussage fachliche Inkompetenz zu unterstellen ist in der Diskussion
einfach daneben.
Grüße, Felix
Felix M. Palmen
* Heiko Schlenker <hsc...@gmx.de>:
> * Felix M. Palmen <zir...@despammed.com> schrieb:
>
>> Es besteht ein theoretisches Risiko.
>
> Und ein praktisches. Eine goldene Regel lautet: Gehe keine unnötigen
> Risiken ein.
Praktisch besteht sowieso immer ein Risiko für Mailverlust. Email ist
nunmal nicht zuverlässig. Damit sich Mail in Verbindung mit einem dyndns
"verläuft" müssen zwei unwahrscheinliche Ereignisse gleichzeitig
eintreten. Das ist für mich vernachlässigbar, die Vorteile wiegen hier
einfach weit schwerer.
>> Das Risiko ist da, wird aber von dir und anderen hochgradig
>> übertrieben.
>
> Aha. Soll das eine Rechtfertigung für Murks sein? :->
Nun, du musst mir ja keine Emails schreiben, wen du wirklich
befürchtest, dass sie nicht bei *mir* ankommen.
> Ein weiteres Stichwort: Murphy
Wurde bei mir von der Praxis widerlegt.
Grüße, Felix
Thomas Hochstein
>> Meine Kristallkugel sagt: Du willst einen SMTP-Server an deiner DSL-Flatrate
>> mit dynamischer Adresse betreiben und DynDNS nutzen.
>
> Ist eine Möglichkeit und eine praktische Sache.
Für Leute, denen ihre Mail nicht wichtig ist, sicher.
>> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
>> oder beliebige Caches noch die alte Adresse haben
>
> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt.
Und beim Abbruch?
> TTL sind 60 Sekunden, Caches fragen also wieder nach.
Sie *sollten* wieder nachfragen. Tun aber nicht alle.
-thh
Felix M. Palmen
* Thomas Hochstein <t...@inter.net>:
> Felix M. Palmen schrieb:
>> Ist eine Möglichkeit und eine praktische Sache.
>
> Für Leute, denen ihre Mail nicht wichtig ist, sicher.
Du kannst ja gerne den Rest vom Thread lesen und auf die Argumente
eingehen. Die Mails kommen bei mir so sicher an, dass noch nie eine
vermisst wurde.
>> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt.
>
> Und beim Abbruch?
Was soll da sein? Sie wird wieder aufgebaut? Für den Fall, dass wirklich
mal was nicht klappt, helfen Scripts, die die DNS-Einträge überprüfen.
>> TTL sind 60 Sekunden, Caches fragen also wieder nach.
>
> Sie *sollten* wieder nachfragen. Tun aber nicht alle.
Kannst du mir einen zeigen? Ernsthaft, ich habe noch keinen gefunden.
Felix M. Palmen
* Urs Janßen <u...@akk.org>:
> das haben die kunden (kleine und mittelstaendische betriebe)
> meines (vor)letzten arbeitgebers anders gesehen.
Nun, erstaunlich. Aber die hatten dann sicher auch keine eigenen
Admin-Stellen, oder?
> wer die augen vor solchen problen verschliesst hat in der branche nix
> verloren.
Aber du siehst hoffentlich ein, dass man die Augen nicht "verschließen"
muss, um zu entscheiden, dass man mit diesem speziellen Risiko leben
kann?
Felix M. Palmen
* Heiko Schlenker <hsc...@gmx.de>:
> * Felix M. Palmen <zir...@despammed.com> schrieb:
>
>> Wurde bei mir von der Praxis widerlegt.
>
> Nullargument. [...]
Na dann passt es doch wunderbar zum "Argument" Murphy ;) Seltsam, dass
du dich ausgerechnet /darauf/ beziehst :þ
Grüße, Felix
PS: Nach einigem Nachdenken kann ich mir durchaus vorstellen, warum
andere damit doch ab und zu Probleme hatten. Dyndns war bei mir am
Anfang auch unzuverlässig; habe mir inzwischen aber Scripts geschrieben,
die ständig kontrollieren, ob die DNS-Einträge stimmen und im
Bedarfsfall Updates ausführen. Einen Mailserver habe ich erst später
installiert.
Nils Ketelsen
> * Nils Ketelsen <ni...@steering-group.net>:
>> Und Deine Leitung faellt nie aus?
> Tut sie. (selten genug). In mittlerweile über 2 Jahren hat das zu keinem
> bekannt gewordenen Verlust von Mails geführt. Auch wenn du das
> vielleicht nicht verstehen kanns, aber damit bin ich absolut zufrieden.
Dann ist ja auch alles schoen. Fuer Dich. Du bist auf die Risiken
hingewiesen worden, Du schaetzt sie als gering ein. Deine Sache. Aber so zu
tun als ob sie fuer jeden vernachlaessigbar sind ist eine Frechheit.
>> Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
>> Operations taetig wirst.
> Du hast dich soeben als ernstzunehmender Diskussionspartner
> disqualifiziert.
Fuer Dich. Etwas, womit ich gut klarkomme.
Nils
--
Gibt's eigentlich auch schon emacs-Einbauküchen?
[nico.h...@physik.tu-chemnitz.de (Nico Hoffmann)
zum Thema "vi-Tassen" in de.alt.arnooo]
Ralf Döblitz
>> Allerdinx. Wenn yum Beispiel jemand anders Deine IP-Adresse bekommt, dyndns
>> oder beliebige Caches noch die alte Adresse haben
>
> dyndns.org wird sofort beim Verbindungsaufbau benachrichtigt. TTL sind
> 60 Sekunden, Caches fragen also wieder nach.
Aber nicht unbedingt die Clients und Server, die mit deinem Server reden
wollen. Die gehen eher von etwas konservativeren TTLs aus, gerade bei
Mailservern. Und während eines Queue-Runs überprüft man nicht unbedingt
ob die TTL abgelaufen ist (da der Queue-Runner ja nur eine relativ klar
begrenzte Lebensdauer hat - eben _einen_ Queue-Run).
Ralf
--
Ralf Döblitz * Schapenstraße 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@doeblitz.net
Homepage: http://www.escape.de/users/selene/
Mit UTF-8 kann man gleichzeitig äöüßÄÖÜæœłø¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ verwenden.
Ralf Döblitz
[...]
> Ah. Darüber dass SMTP-Empfang Passwortlos vor sich geht, da hab ich noch gar nicht
> so drüber nachgedacht. Aber die Wahrscheinlichkeit, dass die andere IP
> einen SMTP-Server betreibt ist dennoch eher gering. Ich denke das Risiko
> kann ich eingehen. Die Dyndns-Addi soll sowieso eher als Spamfänger fungieren.
Na dann rate mal, wieviele Leute die gleiche Idee mit dem Spamfänger
haben und lokal einfach alles auf Port 25 annehmen und ihrem Spamfilter
vorwerfen.
Es gibt so viele robuste Lösungen ...
Ralf Döblitz
> Solche Dinge /werden/ privat gemacht und das Risiko von Mailverlust
> dadurch ist /sehr/ gering.
Bei privater Nutzung vielleicht. Bei stärkerer Nutzung können sich die
Wahrscheinlichkeiten schon sehr unangenehm verschieben.
> Welche Firma, die einen Admin bezahlt, sollte an einem Mailserver auf
> einem dnamischen Host interessiert sein?
Es gibt auch Teilzeitadmins, die so etwas "so nebenbei" mit erledigen
müssen. Selbst im professionellen Umfeld. Ich habe das schon bei DNS
erlebt und Sachen, die selbst für mich da vollkommen normal waren (ich
habe ja nur ein paar hundert Domains zu verwalten) waren es für diese
Leute nicht - es ging bei ihnen ja nur um zwei Domains. Nur sind die
Folgen, die dann daraus resultieren manchmal extrem schmerzhaft. Zum
Glück waren die entstehenden Pannen nur dort intern zu sehen und nicht
für Kunden, sonst hätte da wohl jemand ernsthafte Probleme bekommen.
> Ich weiß jedenfalls was ich tue. Wie man es auch dreht, das Risiko, dass
> eine Mail woanders hinläuft ist eben sehr gering und mir wegen dieser
> Aussage fachliche Inkompetenz zu unterstellen ist in der Diskussion
> einfach daneben.
Es geht micht um Inkompetenz. Du hast einfach für bestimmte Bereiche die
falsche Einstellung.
Wer für DNS und/oder Mail verantwortlich ist, der darf da keine tech-
nischen Risiken eingehen, sondern muß im Gegenteil nicht einfache Fail-
safe-Szenarien konstruieren (wie bei der Bahn wo _ein_ Fehler verkraf-
tet wird und das auch reicht, weil die Wahrscheinlichkeit für zwei
gleichzeitige Fehler verschwindend gering ist und nach einem Fehler
alles stehen muß) sondern mit möglichst vielen gleichzeitigen Fehlern
immer noch korrekt (im Sinne von "kein Datenverlust" bzw. "kein Sicher-
heitsverlust") umgehen.
Wer im privaten Bereich solche Risiken bereitwillig eingeht, der ver-
liert auch im professionellen Bereich die Scheu vor ihnen. Und das ist
eine Einstellung, die ich bei niemandem, der mir Infrastruktur bereit-
stellt, sehen will.
Felix M. Palmen
>>> Operations taetig wirst.
>> Du hast dich soeben als ernstzunehmender Diskussionspartner
>> disqualifiziert.
>
> Fuer Dich. Etwas, womit ich gut klarkomme.
Wird dir bei den meisten so gehen, die du im Lauf einer Diskussion
beleidigst. Wenn du damit gut klarkommst, schön für dich. EOD.
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
> Wer im privaten Bereich solche Risiken bereitwillig eingeht, der ver-
> liert auch im professionellen Bereich die Scheu vor ihnen. Und das ist
> eine Einstellung, die ich bei niemandem, der mir Infrastruktur bereit-
> stellt, sehen will.
Eine sehr gewagte Implikation, wenn man mal überlegt, /wie/
unterschiedlich die Umgebung bei einem privaten Rechner/Netz und in
einer womöglich größeren Firma oder gar bei einem IT-Dienstleister ist.
Wenn du wirklich fordern willst, dass dein Admin bei sich privat
sämtliche Maßnahmen und Sicherheitsvorkehrungen trifft, die in der Firma
angezeigt sind, dann kannst du wahrscheinlich lange nach einem suchen.
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
> Es gibt so viele robuste Lösungen ...
Wenn man nicht mit Accounts in fremden Domains vorlieb nehmen will
beginnen die bei der eigenen Domain mit "catch-all". Mag man außerdem
gerne die Kontrolle über seinen Mailserver haben, ist mindestens ein
virtual server Angebot nötig. Alles Mehrausgaben. Und wozu, wenn doch so
alles funktioniert?
Ich kann mich nur wiederholen, bei mir tut das seit 2 Jahren ohne
verlorene Mail. Zumindest ohne einen Verlust, der jemandem aufgefallen
wäre. Und wenn es sich nicht gerade um Spam handelt würde das sicher
auffallen.
Natürlich sollte man wissen, dass man einen Mailverlust auf diese Art
nicht völlig ausschließen kann. Dass sich dieses Vorgehen daher für
Firmen verbietet, versteht sich auch von selbst. Aber bitte, zwischen
dem und der Idee, verlorene Mails seien damit an der Tagesordnung,
liegen Welten.
Joern Bredereck
>>>Es besteht ein theoretisches Risiko.
>>
>>Und ein praktisches. Eine goldene Regel lautet: Gehe keine unnötigen
>>Risiken ein.
>
>
> Praktisch besteht sowieso immer ein Risiko für Mailverlust. Email ist
> nunmal nicht zuverlässig.
Ich würde sagen, dass kommt zum großen Teil auf die Admins und vor allem
auf deren Einstellung zum Thema Sicherheit an.
Gruß,
Jörn
Joern Bredereck
> PS: Nach einigem Nachdenken kann ich mir durchaus vorstellen, warum
> andere damit doch ab und zu Probleme hatten. Dyndns war bei mir am
> Anfang auch unzuverlässig; habe mir inzwischen aber Scripts geschrieben,
> die ständig kontrollieren, ob die DNS-Einträge stimmen und im
> Bedarfsfall Updates ausführen.
und was machen deine Scripte, wenn die DynDNS-Datenbank von dyndns.org
ausfällt und keine Updates mehr annimmt, wie es in den letzten 3 Jahren
ein paar Mal (wenn auch nur kurz) vorgekommen ist?
Gruß,
Jörn
Felix M. Palmen
* Joern Bredereck <j...@bw-networx.net>:
> und was machen deine Scripte, wenn die DynDNS-Datenbank von dyndns.org
> ausfällt und keine Updates mehr annimmt, wie es in den letzten 3 Jahren
> ein paar Mal (wenn auch nur kurz) vorgekommen ist?
Sie versuchen es in 5 Minuten wieder ;)
Ich hab nie behauptet, dass der DNS-Eintrag zu /jeder/ Zeit korrekt ist.
Aber die Zeiten, in denen er nicht stimmt, lassen sich durchaus
minimieren. Die übliche Praxis, beim Verbindungsaufbau blind ein Update
rauszuschicken und sich danach nicht mehr darum zu kümmern, ist dazu
nicht geeignet.
Grüße, Felix
Felix M. Palmen
* Joern Bredereck <j...@bw-networx.net>:
> Felix M. Palmen wrote:
>> Praktisch besteht sowieso immer ein Risiko für Mailverlust. Email ist
>> nunmal nicht zuverlässig.
>
> Ich würde sagen, dass kommt zum großen Teil auf die Admins und vor allem
> auf deren Einstellung zum Thema Sicherheit an.
Ich meinte jetzt das Medium "Email" an sich. Die meisten deiner Mails
laufen über eine gewisse Anzahl von Systemen, die außerhalb deiner
Kontrolle liegen, und wo du keine Ahnung hast, wer da was wie
konfiguriert hat und ob sie jederzeit wie erwartet funktionieren.
Joern Bredereck
>>und was machen deine Scripte, wenn die DynDNS-Datenbank von dyndns.org
>>ausfällt und keine Updates mehr annimmt, wie es in den letzten 3 Jahren
>>ein paar Mal (wenn auch nur kurz) vorgekommen ist?
>
>
> Sie versuchen es in 5 Minuten wieder ;)
ja, und bis dahin werden die Mails an die letzte IP geschickt, bei der
das Update noch geklappt hat. Da die Ausfälle einige Stunden angehalten
haben, konnten in der Zeit ne ganze Reihe von SMTP-Servern die IP und
somit auch die E-Mails bekommen.
Gruß,
Jörn
Joern Bredereck
>>>Praktisch besteht sowieso immer ein Risiko für Mailverlust. Email ist
>>>nunmal nicht zuverlässig.
>>
>>Ich würde sagen, dass kommt zum großen Teil auf die Admins und vor allem
>>auf deren Einstellung zum Thema Sicherheit an.
>
>
> Ich meinte jetzt das Medium "Email" an sich. Die meisten deiner Mails
> laufen über eine gewisse Anzahl von Systemen, die außerhalb deiner
> Kontrolle liegen, und wo du keine Ahnung hast, wer da was wie
> konfiguriert hat und ob sie jederzeit wie erwartet funktionieren.
Wenn ich in ein Flugzeug steige habe ich keine Kontrolle darüber, was
der Pilot und die Fluglotsen da machen. Ich muss einfach darauf
vertrauen, dass sie ihr Handwerk verstehen. Ich würde daraus aber im
Gegensatz zu dir nicht ableiten, dass Fliegen grundsätzlich
"unzuverlässig" ist, nur weil ich selbst keinen Einfluss darauf habe, ob
ich unbeschadet am Zielflughafen ankomme.
Worauf ich hinausmöchte: Nicht das Medium "E-Mail" ist unzuverlässig,
sondern es kommt immer wieder zu Problemen und Mailverlust, weil einige
Admins ihren Job nicht ernst nehmen und vor sich hinpfuschen. Den
Einsatz von DynDNS-MX-Records würe ich als ein Beispiel dafür betrachten.
Gruß,
Jörn
Ralf Döblitz
>
> * Ralf Döblitz <doeb...@doeblitz.net>:
>> Es gibt so viele robuste Lösungen ...
>
> Wenn man nicht mit Accounts in fremden Domains vorlieb nehmen will
> beginnen die bei der eigenen Domain mit "catch-all". Mag man außerdem
> gerne die Kontrolle über seinen Mailserver haben, ist mindestens ein
> virtual server Angebot nötig. Alles Mehrausgaben. Und wozu, wenn doch so
> alles funktioniert?
Oder man läßt die Doamin bei einem Provider hosten, der einem einen
anständigen Service biete. Zum Beispiel Mailtransfer per UUCP oder ESMTP
durch VPN-Tunnel. Halt irgendwas, was für eine *beiderseitige* Authenti-
fikation zwischen den beiden Systemen sorgt. Bei unserem Verein (Escape
e.V.) ist so etwas Standardleistung für die Mailanbindung von Sites. Und
dieses Prinzip des Store&Forward ist wirklich uralt.
Ralf Döblitz
>
> * Ralf Döblitz <doeb...@doeblitz.net>:
>> Wer im privaten Bereich solche Risiken bereitwillig eingeht, der ver-
>> liert auch im professionellen Bereich die Scheu vor ihnen. Und das ist
>> eine Einstellung, die ich bei niemandem, der mir Infrastruktur bereit-
>> stellt, sehen will.
>
> Eine sehr gewagte Implikation, wenn man mal überlegt, /wie/
> unterschiedlich die Umgebung bei einem privaten Rechner/Netz und in
> einer womöglich größeren Firma oder gar bei einem IT-Dienstleister
> ist.
Verdammt klein, wenn ich mir meine lokale Infrastruktur ansehe. Aber ich
baue die ja auch nach den gleichen Maßstäben auf, die ich in der Firma
anleeg. Und genauso machen es auch eine Reihe von Leuten, die ich kenne
(die auch rein zufällig beruflich mit so etwas zu tun haben). Es *ist*
eine Frage der Grundeinstellung, ob man etwas ordentlich macht oder auch
Pfusch akzeptiert.
> Wenn du wirklich fordern willst, dass dein Admin bei sich privat
> sämtliche Maßnahmen und Sicherheitsvorkehrungen trifft, die in der Firma
> angezeigt sind, dann kannst du wahrscheinlich lange nach einem suchen.
Da irrst du. Ich habe solche Admins. Und genau deshalb habe ich auch
kein Problem damit, daß das nicht die billigsten Anbieter sind. Mir ist
Qualität wichtiger als Geiz.
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
> Felix M. Palmen <zir...@despammed.com> wrote:
>> Hallo Ralf,
>>
>> * Ralf Döblitz <doeb...@doeblitz.net>:
>>> Es gibt so viele robuste Lösungen ...
>>
>> Wenn man nicht mit Accounts in fremden Domains vorlieb nehmen will
>> beginnen die bei der eigenen Domain mit "catch-all". Mag man außerdem
>> gerne die Kontrolle über seinen Mailserver haben, ist mindestens ein
>> virtual server Angebot nötig. Alles Mehrausgaben. Und wozu, wenn doch so
>> alles funktioniert?
>
> Oder man läßt die Doamin bei einem Provider hosten, der einem einen
> anständigen Service biete. Zum Beispiel Mailtransfer per UUCP oder ESMTP
> durch VPN-Tunnel. Halt irgendwas, was für eine *beiderseitige* Authenti-
> fikation zwischen den beiden Systemen sorgt. Bei unserem Verein (Escape
> e.V.) ist so etwas Standardleistung für die Mailanbindung von Sites. Und
> dieses Prinzip des Store&Forward ist wirklich uralt.
Ach und das gibt's kostenlos?
Felix M. Palmen
* Joern Bredereck <j...@bw-networx.net>:
> ja, und bis dahin werden die Mails an die letzte IP geschickt, bei der
> das Update noch geklappt hat. Da die Ausfälle einige Stunden angehalten
> haben, konnten in der Zeit ne ganze Reihe von SMTP-Servern die IP und
> somit auch die E-Mails bekommen.
Wieviele Leute haben auf ihren privaten Kisten SMTP-Server laufen?
Wieviele davon nehmen beliebige Mail einfach an? Wieviele /davon/ routen
sie nicht korrekt weiter sondern legen sie einfach lokal ab? Da muss
ziemlich viel zusammenkommen, damit eine Mail wirklich in der Versenkung
verschwindet.
Ich denke ich habe oft genug geschrieben, dass man Mailverlust durch
zeitweilig falschen DNS-Eintrag nicht *vollständig* ausschließen kann.
Aber es ist und bleibt so: Das Risiko ist sehr sehr gering. Und das
wollen einige hier wohl nicht akzeptieren.
An der stelle EOT für mich, denn ich bin mit meinem System wie es ist
einfach absolut zufrieden.
Ralf Döblitz
>> Oder man läßt die Doamin bei einem Provider hosten, der einem einen
>> anständigen Service biete. Zum Beispiel Mailtransfer per UUCP oder ESMTP
>> durch VPN-Tunnel. Halt irgendwas, was für eine *beiderseitige* Authenti-
>> fikation zwischen den beiden Systemen sorgt. Bei unserem Verein (Escape
>> e.V.) ist so etwas Standardleistung für die Mailanbindung von Sites. Und
>> dieses Prinzip des Store&Forward ist wirklich uralt.
>
> Ach und das gibt's kostenlos?
Es ist Basisfunktionalität. Wenn du beim Escape e.V. einen UUCP- oder
IP-Zugnag nimmst, dann ist das grundsätzlich mit drin. In diesem Sinne
ist es also kostenlos, denn es verursacht keine Mehrkosten. Der Escape
ist sicher nicht der günstigste Provider für die Region hier, aber eben
einer, der einem nicht nur ein absolutes Minimum an Features bietet.
Wenn du dich ernsthaft umsiehst, dann wirst du sicher auch in anderen
regionen Provider finden, die solche Leistungen anbieten (die ehemaligen
IN-Regionaldomains z.B.) udn für die diese Qualität selbstverständlich
ist.
Wer nur auf den Preis achtet, der ist selbst Schuld, wenn er Billigmüll
einkauft.
Thomas Schweikle
>>> > Alles zu unrealistisch? Naja, dann hoffe ich einfach, dass Du nie in IT
>>> > Operations taetig wirst.
>>> Du hast dich soeben als ernstzunehmender Diskussionspartner
>>> disqualifiziert.
>>
>> mit mailverlust rechnen. fuer privat personen mag das (geringe)
>> risiko tragbar sein, fuer firmen ist es das normalerweise nicht. wer
>> das nicht sieht hat in der branche nix verloren - ausser seinen
>> arbeitsplatz wenn es mal rummst obwohl das ja garnicht moeglich ist.
>
> Solche Dinge /werden/ privat gemacht
Nicht nur. Beispiele: Schulen, kleine Firmen, für die ein fester
Anschluß nicht rentiert, Privatiers, Künstler, Argenturen, ...
> und das Risiko von Mailverlust
> dadurch ist /sehr/ gering.
Bei dir. Andere haben andere Erfahrungen gemacht. Zum Beispiel ich.
> Welche Firma, die einen Admin bezahlt, sollte
> an einem Mailserver auf einem dnamischen Host interessiert sein?
Jeder, für den sich eine feste Adresse im Internet nicht rentiert,
weil er einfach zu wenig mit dem Internet verdient, aber trotzdem
mit Möglichkeiten online sein will, die anders, als mit einem
eigenen Server nicht zu verwirklichen sind. Nicht immer ist ein
Mietserver die Lösung aller Probleme. DSL ist es auch nicht.
> Ich weiß jedenfalls was ich tue.
Das kann sein.
> Wie man es auch dreht, das Risiko, dass
> eine Mail woanders hinläuft ist eben sehr gering
Für dich. S.o.
> und mir wegen dieser
> Aussage fachliche Inkompetenz zu unterstellen ...
Ich darf dich zitieren: "Du hast dich soeben als ernstzunehmender
Diskussionspartner disqualifiziert".
Wer hier wem zuerst Inkompetenz unterstellt hat, läßt sich am Thread
leicht nachvollziehen.
> ... ist in der Diskussion
> einfach daneben.
Sehr richtig. Dabei beachte man bitte: "Wer im Glasshaus sitzt,
sollte nicht mit Steinen werfen!".
--
Thomas
Thomas Schweikle
> Hallo Joern,
>
> * Joern Bredereck <j...@bw-networx.net>:
>> ja, und bis dahin werden die Mails an die letzte IP geschickt, bei der
>> das Update noch geklappt hat. Da die Ausfälle einige Stunden angehalten
>> haben, konnten in der Zeit ne ganze Reihe von SMTP-Servern die IP und
>> somit auch die E-Mails bekommen.
>
> Wieviele Leute haben auf ihren privaten Kisten SMTP-Server laufen?
Diverse Hamster-Nutzer.
> Wieviele davon nehmen beliebige Mail einfach an?
Jeder Hamster in der Grundkonfiguration.
> Wieviele /davon/ routen
> sie nicht korrekt weiter sondern legen sie einfach lokal ab?
Jeder Hamster in der Grundkonfiguration (Zustellung an den
Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
möglich. Spamschleudern mag aber niemand.
Was für Hamster gilt, gilt auch für die Mailserver, die
verschiedenen Distributionen standartmässig aufsetzen:
- SuSE
- Gentoo
- Debian (hängt vom installierten Mailserver ab)
- FreeBSD (hängt vom installierten Mailserver ab)
Auch einige kommerzielle Produkte liefern Mail in solchen Fällen an
einen Standartaccount, der sie dann bearbeiten sollte:
- Domino.
> Da muss
> ziemlich viel zusammenkommen, damit eine Mail wirklich in der Versenkung
> verschwindet.
Ja. Zwei Fehler, die selten getrennt auftreten.
> Ich denke ich habe oft genug geschrieben, dass man Mailverlust durch
> zeitweilig falschen DNS-Eintrag nicht *vollständig* ausschließen kann.
> Aber es ist und bleibt so: Das Risiko ist sehr sehr gering. Und das
> wollen einige hier wohl nicht akzeptieren.
Das ist genau das Problem: was du als "sehr sehr gering" bezeichnest
ist für andere "sehr sehr viel", was du anscheinend nicht
akzeptierst. Denn Zahlen vorlegen, das hat bisher nur einer gemacht.
> An der stelle EOT für mich, denn ich bin mit meinem System wie es ist
> einfach absolut zufrieden.
Dann hoffe einfach, das es so bleibt.
--
Thomas
Felix M. Palmen
da muss ich doch nochmal kurz einhaken:
* Thomas Schweikle <t...@vr-web.de>:
> Jeder Hamster in der Grundkonfiguration (Zustellung an den
> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
> möglich. Spamschleudern mag aber niemand.
Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
Korrekt wäre ja wohl so ein Verhalten:
| RCPT TO:<te...@foobar.example>
| 550 relay not permitted
Es sei denn natürlich er wird nur mit Mails gefüttert, die irgendwo aus
anderen Mailboxen abgeholt wurden. In dem Fall ist es aber wieder sehr
sinnfrei, ihn am externen Interface horchen zu lassen.
> - Debian (hängt vom installierten Mailserver ab)
Beim per default installierten Exim ist das definitiv nicht so.
Felix M. Palmen
da muss ich doch nochmal kurz einhaken:
* Thomas Schweikle <t...@vr-web.de>:
> Jeder Hamster in der Grundkonfiguration (Zustellung an den
> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
> möglich. Spamschleudern mag aber niemand.
Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
Korrekt wäre ja wohl so ein Verhalten:
| RCPT TO:<te...@foobar.example>
| 550 relay not permitted
Es sei denn natürlich er wird nur mit Mails gefüttert, die irgendwo aus
anderen Mailboxen abgeholt wurden. In dem Fall ist es nämlich bereits
völlig sinnfrei, ihn überhaupt erst am externen Interface horchen zu
lassen.
> - Debian (hängt vom installierten Mailserver ab)
Beim per default installierten Exim ist das definitiv nicht so.
Grüße, Felix
Thomas Schweikle
> Hallo Thomas,
>
> da muss ich doch nochmal kurz einhaken:
>
> * Thomas Schweikle <t...@vr-web.de>:
>> Jeder Hamster in der Grundkonfiguration (Zustellung an den
>> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
>> möglich. Spamschleudern mag aber niemand.
>
> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
> Korrekt wäre ja wohl so ein Verhalten:
> | RCPT TO:<te...@foobar.example>
> | 550 relay not permitted
Es ist per Definition aber kein relaying, wenn die Adresse, an die
ich die Mail sende mir gehört. Dann ist einfach der Empfänger unbekannt.
Genau das ist aber das Szenario, wenn DynDNS gerade mal einige
Adressen noch zu kennen behauptet, die eigentlich gerade nicht mehr
existieren sollten. Ganz einfacher Fall:
Meine DynDNS-Domäne sei: invail.ipnet.de
Ich bin angemeldet und DynDNS kennt meine IP:
| C:\> nslookup invalid.homeip.net
| Server: www-proxy.UL1.srv.t-online.de
| Address: 217.237.150.141
|
| Nicht autorisierte Antwort:
| Name: invalid.homeip.net
| Address: 217.236.217.145
Prima. Soweit alles OK.
Mein PC macht einen Abgang. Abmelden bei DynDNS unterbleibt
(DSL-Stecker gezogen).
nslookup von einem anderen PC aus funktioniert aber weiterhin:
| hazel: ~> nslookup invalid.homeip.net
| Server: www-proxy.UL1.srv.t-online.de
| Address: 217.237.150.141
|
| Nicht autorisierte Antwort:
| Name: invalid.homeip.net
| Address: 217.236.217.145
Mit einem Ping läßt sich prüfen, ob es noch einen PC hinter der
Adresse gibt:
| hazel: ~> ping -c1 invalid.homeip.net
| PING invalid.homeip.net (217.236.217.88): 56 data bytes
|
| --- invalid.homeip.net ping statistics ---
| 1 packets transmitted, 0 packets received, 100% packet loss
Was zu erwarten war.
Das geht auch noch einige Minuten später:
| hazel: ~> nslookup invalid.homeip.net
| Server: www-proxy.UL1.srv.t-online.de
| Address: 217.237.150.141
|
| Nicht autorisierte Antwort:
| Name: invalid.homeip.net
| Address: 217.236.217.88
|
| hazel: ~> ping -c1 invalid.homeip.net
| PING invalid.homeip.net (217.236.217.88): 56 data bytes
|
| --- invalid.homeip.net ping statistics ---
| 1 packets transmitted, 1 packets received, 0% packet loss
Upps! Mein PC ist noch nicht wieder online (dazu hätte jemand
zuhause den Stecker wieder einstecken müssen --- da ist aber
niemand)! Das Abstürzen habe ich schließlich duch ziehen des
DSL-Kabels simmuliert. PC Nr. 2 hat einen eigenen DSL-Zugang und
steht etwa 80m entfernt beim Nachbarn.
Wer garantiert dir, das dieser PC keinen Mailer mit SMTP laufen hat?
Mal testen:
| nmap -p25 invalid.homeip.net
|
| Starting nmap 3.77 ( http://www.nmap.insecure.org/nmap/ ) \
| at 2005-01-15 17:21:15 CET
| Interesting ports on \
| pD9ECD991.dip0.t-ipconnect.de (217.236.217.88):
| PORT STATE SERVICE
| 25/tcp open smtp
:)
Richtig neugierig geworden:
| hazel: ~> telnet invaild.homeip.net 25
| Trying 217.236.217.88...
| Connected to invalid.homeip.net.
| Escape character is '^]'.
| 220 margot ESMPT Postfix
| quit
| 221 Bye
| Connection closed by foreign host.
Und --- warum sollte dieser PC die Mail mit "Relaying denied"
ablehnen? Die IP-Adresse stimmt! Da DynDNS keine Rückwärtsauflösung
unterstützt, bleibt einem korrekt konfigurierten Mailer höchstens
übrig die Mail mit Empfänger unbekannt zu bouncen (sonst darf er
überhaup keine Mail annehmen!). Das ist aber auch eine Methode SPAM
zu versenden. Einfach beides fälschen: Absender- und
Empfängeradresse. Folge: wenn ein Mailer an einer dynamischen
Adresse hängt, sollte er eine Mail mit "Empfänger unbekannt" *nicht*
weiterschicken, es sei den der Admin will es so.
> Es sei denn natürlich er wird nur mit Mails gefüttert, die irgendwo aus
> anderen Mailboxen abgeholt wurden. In dem Fall ist es aber wieder sehr
> sinnfrei, ihn am externen Interface horchen zu lassen.
Das kommt darauf an.
>> - Debian (hängt vom installierten Mailserver ab)
>
> Beim per default installierten Exim ist das definitiv nicht so.
Tja. Wie gesagt: es hängt vom ausgewählten Mailer ab.
--
Thomas
Peter J. Holzer
> Felix M. Palmen schrieb:
>> Wieviele davon nehmen beliebige Mail einfach an?
>
> Jeder Hamster in der Grundkonfiguration.
>
>> Wieviele /davon/ routen
>> sie nicht korrekt weiter sondern legen sie einfach lokal ab?
>
> Jeder Hamster in der Grundkonfiguration (Zustellung an den
> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
> möglich. Spamschleudern mag aber niemand.
>
> Was für Hamster gilt, gilt auch für die Mailserver, die
> verschiedenen Distributionen standartmässig aufsetzen:
> - SuSE
> - Gentoo
> - Debian (hängt vom installierten Mailserver ab)
> - FreeBSD (hängt vom installierten Mailserver ab)
Das bezweifle ich. Der Default-Zustand bei Unix-Mailern ist
typischerweise "akzeptiere $user@$myhostname, wenn $user ein lokaler User
oder ein lokales Alias ist" und zumindest bei SuSE und Debian habe ich
schon frisch aufgesetzte Kisten gesehen, wo das so war (kann natürlich
sein, dass bei beiden irgendwo auf der letzten CD ein exotischer Mailer
drauf ist, der einfach alles akzeptiert, aber nicht der standardmäßig
installierte - typischerweise wohl sendmail, postfix oder exim).
hp
--
_ | Peter J. Holzer | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR | überhaupt gesprochen, also auch kein Dialekt.
| | | h...@hjp.at | Hallig Gröde ist fast gänzlich dialektfrei.
__/ | http://www.hjp.at/ | -- Hannes Petersen in desd
Thomas Schweikle
> On 2005-01-15 14:33, Thomas Schweikle <t...@vr-web.de> wrote:
>> Felix M. Palmen schrieb:
>>> Wieviele davon nehmen beliebige Mail einfach an?
>>
>> Jeder Hamster in der Grundkonfiguration.
>>
>>> Wieviele /davon/ routen
>>> sie nicht korrekt weiter sondern legen sie einfach lokal ab?
>>
>> Jeder Hamster in der Grundkonfiguration (Zustellung an den
>> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
>> möglich. Spamschleudern mag aber niemand.
>>
>> Was für Hamster gilt, gilt auch für die Mailserver, die
>> verschiedenen Distributionen standartmässig aufsetzen:
>> - SuSE
>> - Gentoo
>> - Debian (hängt vom installierten Mailserver ab)
>> - FreeBSD (hängt vom installierten Mailserver ab)
>
> Das bezweifle ich. Der Default-Zustand bei Unix-Mailern ist
> typischerweise "akzeptiere $user@$myhostname, wenn $user ein lokaler User
> oder ein lokales Alias ist" und zumindest bei SuSE und Debian habe ich
> schon frisch aufgesetzte Kisten gesehen, wo das so war (kann natürlich
> sein, dass bei beiden irgendwo auf der letzten CD ein exotischer Mailer
> drauf ist, der einfach alles akzeptiert, aber nicht der standardmäßig
> installierte - typischerweise wohl sendmail, postfix oder exim).
Bei Debian hatte qmail diese Angewohnheit. Da das auch bei der SuSE
und Gentoo-Version so war, nehme ich an, das qmail es überall so macht.
Ob es immer noch so ist, kann ich nicht beantworten. Der Test
diverser Mailer ist jetzt mehr als zehn Monate her (ich bin bei
Postfix geblieben --- leider macht Postfix diverse Schwierigkeiten
im Zusammenhang mit DynDNS und ohne "keep online", d.h. bei häufig
wechselnder Adresse. Ich bin deshalb von der Idee einen eigenen
Mailer betreiben zu wollen wieder abgerückt).
--
Thomas
Peter J. Holzer
> Peter J. Holzer schrieb:
>> On 2005-01-15 14:33, Thomas Schweikle <t...@vr-web.de> wrote:
>>> Felix M. Palmen schrieb:
>>>> Wieviele davon nehmen beliebige Mail einfach an?
>>> Was für Hamster gilt, gilt auch für die Mailserver, die
>>> verschiedenen Distributionen standartmässig aufsetzen:
>>> - SuSE
>>> - Gentoo
>>> - Debian (hängt vom installierten Mailserver ab)
>>> - FreeBSD (hängt vom installierten Mailserver ab)
>>
>> Das bezweifle ich. Der Default-Zustand bei Unix-Mailern ist
>> typischerweise "akzeptiere $user@$myhostname, wenn $user ein lokaler User
>> oder ein lokales Alias ist" und zumindest bei SuSE und Debian habe ich
>> schon frisch aufgesetzte Kisten gesehen, wo das so war (kann natürlich
>> sein, dass bei beiden irgendwo auf der letzten CD ein exotischer Mailer
>> drauf ist, der einfach alles akzeptiert, aber nicht der standardmäßig
>> installierte - typischerweise wohl sendmail, postfix oder exim).
>
> Bei Debian hatte qmail diese Angewohnheit. Da das auch bei der SuSE
> und Gentoo-Version so war, nehme ich an, das qmail es überall so macht.
Das wird den Dan Bernstein aber interessieren :-) Der mag es nämlich gar
nicht, wenn man einen geänderten qmail irgendwo installiert, ohne den
User darauf aufmerksam zu machen, dass das nicht der Echte Und Wahre
qmail vom großen Meister ist. Abgesehen davon ist der qmail weder bei
Debian noch bei SuSE der default-MTA (bei Debian schon deshalb nicht,
weil er non-free ist).
Default ist auch beim qmail, dass er nur Mails an lokale User
ausliefert. Was beim qmail anders ist als bei den anderen (und dieser
Unterschied disqualifiziert ihn IMNSHO für den Einsatz auf einem MX),
ist dass er die Mail zunächst einmal annimmt, und dann erst schaut, ob
es die Adresse lokal überhaupt gibt. Wenn es sie nicht gibt, generiert
er eine DSN.
hp (auch qmail-User, aber mit qpsmtpd als SMTP-Server)
Felix M. Palmen
* Thomas Schweikle <t...@vr-web.de>:
> Richtig neugierig geworden:
> | hazel: ~> telnet invaild.homeip.net 25
> | Trying 217.236.217.88...
> | Connected to invalid.homeip.net.
> | Escape character is '^]'.
> | 220 margot ESMPT Postfix
> | quit
> | 221 Bye
> | Connection closed by foreign host.
>
> Und --- warum sollte dieser PC die Mail mit "Relaying denied"
> ablehnen? Die IP-Adresse stimmt!
Weil er "invalid.homeip.net" nicht in der Liste der lokalen Domains hat.
Selbst wenn der eigene Hostname automatisch als lokale Domain angesehen
wird, ergibt das keinen Sinn. Denn der ist trotz des DNS-Eintrags mit
Sicherheit auch nicht "invalid.homeip.net". Die einzige sinnvolle
Möglichkeit, den Hostnamen aus dem DNS zu bestimmen, ist ein reverse
lookup.
> Da DynDNS keine Rückwärtsauflösung unterstützt
eben.
> bleibt einem korrekt konfigurierten Mailer höchstens übrig die Mail
> mit Empfänger unbekannt zu bouncen
Nein, er kann (bzw muss) sie ablehnen, z.B. mit 550 relaying denied. Die
Domain ist eben keine seiner lokalen Domains, also wäre es Relaying, sie
anzunehmen und selbst Zustellversuche zu unternehmen. Diese würden dann
allerdings in der Tat scheitern.
> Folge: wenn ein Mailer an einer dynamischen
> Adresse hängt, sollte er eine Mail mit "Empfänger unbekannt" *nicht*
> weiterschicken, es sei den der Admin will es so.
Natürlich nicht, das sollte kein Mailer tun. Mail mit unbekanntem
Empfänger kann abgelehnt werden, Mail mit fremder Domain ebenfalls, es
sei denn man /will/ als Relay funktionieren.
Nils Ketelsen
> Weil er "invalid.homeip.net" nicht in der Liste der lokalen Domains hat.
> Selbst wenn der eigene Hostname automatisch als lokale Domain angesehen
> wird, ergibt das keinen Sinn. Denn der ist trotz des DNS-Eintrags mit
> Sicherheit auch nicht "invalid.homeip.net". Die einzige sinnvolle
> Möglichkeit, den Hostnamen aus dem DNS zu bestimmen, ist ein reverse
> lookup.
Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die Domain
der eingehenden Mail einen Vorwaertslookup zu machen, und wenn der auf einen
selber zeigt die Mail anzunehmen. Und es gibt Mailer da draussen, die so
konfiguriert sind.
Bei exim3 musste man zum Beispiel dafuer einfach "self=local" konfigurieren,
IIRC.
Nils
--
All persons have the right to be attracted to other objects in accordance
with the Laws of Gravity.
[stolen at http://totl.net/Rights/]
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die Domain
> der eingehenden Mail einen Vorwaertslookup zu machen, und wenn der auf einen
> selber zeigt die Mail anzunehmen. Und es gibt Mailer da draussen, die so
> konfiguriert sind.
Mag sein, dass es die gibt. Dann sind sie kaputt (im Sinn von reichlich
idiotisch).
> Bei exim3 musste man zum Beispiel dafuer einfach "self=local" konfigurieren,
> IIRC.
Da hast du die Doku nicht so genau gelesen. Die Option self bestimmt,
was passiert, wenn beim Mailrouting der Host des Servers selbst
ermittelt wird. Das ist also erst dann relevant, wenn man die Mail
bereits angenommen hat. Und das tut man für nicht-lokale Domains nur
dann, wenn man als Relay funktionieren will.
Wenn man die Mail annehmen wollte, müsste man also Relaying erlauben,
und würde damit dann ja /jede/ Mail annehmen.
Peter J. Holzer
>>> Jeder Hamster in der Grundkonfiguration (Zustellung an den
>>> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
>>> möglich. Spamschleudern mag aber niemand.
>>
>> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
>> Korrekt wäre ja wohl so ein Verhalten:
>> | RCPT TO:<te...@foobar.example>
>> | 550 relay not permitted
>
> Es ist per Definition aber kein relaying, wenn die Adresse, an die
> ich die Mail sende mir gehört. Dann ist einfach der Empfänger unbekannt.
Unsinn. Es ist dann Relaying, wenn die Empfängeradresse zu einem anderen
Mailserver gehört, als dem, über den Du gerade zu senden versuchst. Ob
sie Dir als Absender gehört oder nicht, ist vollkommen irrelevant.
Wenn also der Mailserver der Domain a.invalid zu einem bestimmten
Zeitpunkt die IP-Adresse 10.1.2.3 hat und diese im DynDNS einträgt, und
zu einem späteren Zeitpunkt diese IP-Adresse dem Mail-Server der Domain
b.invalid zugewiesen wird, dann ist der Versuch, zu diesem Zeitpunkt,
eine Mail an <te...@a.invalid> über den Server mit der IP-Adresse
10.1.2.3 zuzustellen, ein Relay-Versuch (denn der Server ist eben nur
b.invalid zuständig, nicht für a.invalid, und müsste die Mail daher
weiterleiten).
> Genau das ist aber das Szenario, wenn DynDNS gerade mal einige
> Adressen noch zu kennen behauptet, die eigentlich gerade nicht mehr
> existieren sollten. Ganz einfacher Fall:
>
> Meine DynDNS-Domäne sei: invail.ipnet.de
> Ich bin angemeldet und DynDNS kennt meine IP:
>| C:\> nslookup invalid.homeip.net
>| Server: www-proxy.UL1.srv.t-online.de
>| Address: 217.237.150.141
>|
>| Nicht autorisierte Antwort:
>| Name: invalid.homeip.net
>| Address: 217.236.217.145
^^^^^^^^^^^^^^^
> Prima. Soweit alles OK.
> Mein PC macht einen Abgang. Abmelden bei DynDNS unterbleibt
> (DSL-Stecker gezogen).
[...]
> Das geht auch noch einige Minuten später:
>| hazel: ~> nslookup invalid.homeip.net
>| Server: www-proxy.UL1.srv.t-online.de
>| Address: 217.237.150.141
>|
>| Nicht autorisierte Antwort:
>| Name: invalid.homeip.net
>| Address: 217.236.217.88
^^^^^^^^^^^^^^
Moment! Da hat sich die IP-Adresse geändert. D.h., jemand hat für Deine
Domain eine neue IP-Adresse angegeben - wer kann das außer Dir? (Ich
kenne homeip.net nicht, nehme aber doch an, dass es da irgendeine Art
der Authentifikation geben wird)
>| hazel: ~> ping -c1 invalid.homeip.net
>| PING invalid.homeip.net (217.236.217.88): 56 data bytes
>|
>| --- invalid.homeip.net ping statistics ---
>| 1 packets transmitted, 1 packets received, 0% packet loss
>
> Upps! Mein PC ist noch nicht wieder online (dazu hätte jemand
> zuhause den Stecker wieder einstecken müssen --- da ist aber
> niemand)! Das Abstürzen habe ich schließlich duch ziehen des
> DSL-Kabels simmuliert. PC Nr. 2 hat einen eigenen DSL-Zugang und
> steht etwa 80m entfernt beim Nachbarn.
>
> Wer garantiert dir, das dieser PC keinen Mailer mit SMTP laufen hat?
> Mal testen:
[...]
>| hazel: ~> telnet invaild.homeip.net 25
>| Trying 217.236.217.88...
>| Connected to invalid.homeip.net.
>| Escape character is '^]'.
>| 220 margot ESMPT Postfix
>| quit
>| 221 Bye
>| Connection closed by foreign host.
>
> Und --- warum sollte dieser PC die Mail mit "Relaying denied"
> ablehnen?
Weil er sich nicht für die Domain invalid.homeip.net zuständig fühlen
sollte - das ist Deine Domain, nicht Margots.
> Die IP-Adresse stimmt!
Irrelevant.
> Da DynDNS keine Rückwärtsauflösung unterstützt,
Auch irrelevant. Wozu sollte der Server Rückwärtsauflösung brauchen? Im
Gegenteil, gerade dadurch würde er ja falsche Information bekommen, wenn
der DynDNS-Record noch nicht upgedatet wurde.
> bleibt einem korrekt konfigurierten Mailer höchstens übrig die Mail
> mit Empfänger unbekannt zu bouncen (sonst darf er überhaup keine Mail
> annehmen!). Das ist aber auch eine Methode SPAM zu versenden.
Er soll nicht bouncen, sondern rejecten.
> Einfach beides fälschen: Absender- und Empfängeradresse. Folge: wenn
> ein Mailer an einer dynamischen Adresse hängt, sollte er eine Mail mit
> "Empfänger unbekannt" *nicht* weiterschicken, es sei den der Admin
> will es so.
Das hat mit dynamisch oder fix überhaupt nichts zu tun, die
Argumentation bleibt bei fixen IP-Adressen genau die gleiche. Ein MX
soll Mail nur dann annehmen, wenn er sich einigermaßen sicher sein kann,
dass er sie auch zustellen kann. Wenn er sie aber angenommen hat, dann
darf er sie nicht einfach kommentarlos entsorgen. Da die Return-Adresse
gefälscht sein kann (und insbesondere bei Spam und Würmern fast immer
gefälscht ist), sollte er alle Checks durchführen, bevor er die Mail
annimmt.
hp
Nils Ketelsen
>> Bei exim3 musste man zum Beispiel dafuer einfach "self=local" konfigurieren,
>> IIRC.
>
> Da hast du die Doku nicht so genau gelesen. Die Option self bestimmt,
> was passiert, wenn beim Mailrouting der Host des Servers selbst
> ermittelt wird. Das ist also erst dann relevant, wenn man die Mail
> bereits angenommen hat. Und das tut man für nicht-lokale Domains nur
> dann, wenn man als Relay funktionieren will.
Ach? Dafuer langt es nicht das RCPT TO der Mail zu kennen? Faszinierend.
> Wenn man die Mail annehmen wollte, müsste man also Relaying erlauben,
> und würde damit dann ja /jede/ Mail annehmen.
Das hat mit Relaying aber auch so garnichts zu tun. Konnte man exim aber
auch beibringen. Die Option heisst "relay-domains-include-local-MX".
Nils
--
Wahre Worte gelassen ausgesprochen (2):
"The farther you get away from water, the dumber the people get."
[aus einer Diskussion, warum so viele Leute in Kuestenregionen
leben]
Nils Ketelsen
> Das hat mit Relaying aber auch so garnichts zu tun. Konnte man exim aber
> auch beibringen. Die Option heisst "relay-domains-include-local-MX".
Ich mach hier mal die Ingrid: Letzteres macht natuerlich nur Sinn, wenn
nicht der lowest MX auf einen zeigt. Hat also mit dem hier diskutierten
DynDNS-Setup nichts zu tun.
Nils
--
Nils Ketelsen // Mississauga, Canada
43° 35' 13"N, 79° 38' 23"W
mailto:`#!/bin/sh`@druecke.strg-alt.entf.org
http://druecke.strg-alt-entf.org/
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
>> Da hast du die Doku nicht so genau gelesen. Die Option self bestimmt,
>> was passiert, wenn beim Mailrouting der Host des Servers selbst
>> ermittelt wird. Das ist also erst dann relevant, wenn man die Mail
>> bereits angenommen hat. Und das tut man für nicht-lokale Domains nur
>> dann, wenn man als Relay funktionieren will.
>
> Ach? Dafuer langt es nicht das RCPT TO der Mail zu kennen? Faszinierend.
Die Mail kommt erst in den router, nachdem sie angenommen wurde. Erst
dort bestimmt dann die "self"-Option, was mit ihr geschehen soll, falls
beim Routing wieder die eigene IP-Adresse ermittelt wird.
Wenn fragliche Domain aber nicht in den local_domains ist (und wie
sollte sie da hineinkommen) und man auch nicht zufälligerweise für den
Absender relayt, dann wird sie gar nicht erst angenommen. Daran ändert
"self=local" absolut nichts.
Thomas Schweikle
> Felix M. Palmen <zir...@despammed.com> wrote:
>
>> Weil er "invalid.homeip.net" nicht in der Liste der lokalen Domains hat.
>> Selbst wenn der eigene Hostname automatisch als lokale Domain angesehen
>> wird, ergibt das keinen Sinn. Denn der ist trotz des DNS-Eintrags mit
>> Sicherheit auch nicht "invalid.homeip.net". Die einzige sinnvolle
>> Möglichkeit, den Hostnamen aus dem DNS zu bestimmen, ist ein reverse
>> lookup.
>
> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die Domain
> der eingehenden Mail einen Vorwaertslookup zu machen, und wenn der auf einen
> selber zeigt die Mail anzunehmen. Und es gibt Mailer da draussen, die so
> konfiguriert sind.
Ak. Und nicht nur einen. Postfix kann das auch.
> Bei exim3 musste man zum Beispiel dafuer einfach "self=local" konfigurieren,
> IIRC.
Ja.
--
Thomas
Thomas Schweikle
> Hallo Thomas,
>
> * Thomas Schweikle <t...@vr-web.de>:
>> Richtig neugierig geworden:
>> | hazel: ~> telnet invaild.homeip.net 25
>> | Trying 217.236.217.88...
>> | Connected to invalid.homeip.net.
>> | Escape character is '^]'.
>> | 220 margot ESMPT Postfix
>> | quit
>> | 221 Bye
>> | Connection closed by foreign host.
>>
>> Und --- warum sollte dieser PC die Mail mit "Relaying denied"
>> ablehnen? Die IP-Adresse stimmt!
>
> Weil er "invalid.homeip.net" nicht in der Liste der lokalen Domains hat.
> Selbst wenn der eigene Hostname automatisch als lokale Domain angesehen
> wird, ergibt das keinen Sinn. Denn der ist trotz des DNS-Eintrags mit
> Sicherheit auch nicht "invalid.homeip.net". Die einzige sinnvolle
> Möglichkeit, den Hostnamen aus dem DNS zu bestimmen, ist ein reverse
> lookup.
OK. Dann setzt du aber voraus, das der Mailer so konfiguriert ist,
das er nur eine Mail an die eigene Domain akzeptiert. Das würde ich
nicht einfach machen. Ich würde davon ausgehen, das jeder User
seinen Server der einfachheit halber so konfiguriert hat, das dieser
jede Mail annimmt --- egal welche Domäne die Empfängerdomäne ist.
>> Da DynDNS keine Rückwärtsauflösung unterstützt
>
> eben.
Ich könnte zum Beispiel einfach "*.t-online.de" zulassen. Das wäre
dann zwar eine Fehlkonfiguration, aber mein Server würde damit seine
Adresse rückwärts auflösen können. Der Domänenteil wäre korrekt und
damit die Mail akzeptabel.
>> bleibt einem korrekt konfigurierten Mailer höchstens übrig die Mail
>> mit Empfänger unbekannt zu bouncen
>
> Nein, er kann (bzw muss) sie ablehnen, z.B. mit 550 relaying denied. Die
> Domain ist eben keine seiner lokalen Domains, also wäre es Relaying, sie
> anzunehmen und selbst Zustellversuche zu unternehmen. Diese würden dann
> allerdings in der Tat scheitern.
Was ist mit Software, die den Hostnamen immer auf den Dail-In-Namen
setzt (AFAIK hat die T-Online-Software diese Angewohnheit --- ob das
heute noch so ist, kann ich nicht sagen. Ich verwende sie nicht mehr).
>> Folge: wenn ein Mailer an einer dynamischen
>> Adresse hängt, sollte er eine Mail mit "Empfänger unbekannt" *nicht*
>> weiterschicken, es sei den der Admin will es so.
>
> Natürlich nicht, das sollte kein Mailer tun. Mail mit unbekanntem
> Empfänger kann abgelehnt werden, Mail mit fremder Domain ebenfalls, es
> sei denn man /will/ als Relay funktionieren.
AK.
--
Thomas
Felix M. Palmen
* Thomas Schweikle <t...@vr-web.de>:
> Nils Ketelsen schrieb:
>> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die
>> Domain der eingehenden Mail einen Vorwaertslookup zu machen, und wenn
>> der auf einen selber zeigt die Mail anzunehmen. Und es gibt Mailer da
>> draussen, die so konfiguriert sind.
>
> Ak. Und nicht nur einen. Postfix kann das auch.
>
>> Bei exim3 musste man zum Beispiel dafuer einfach "self=local"
>> konfigurieren, IIRC.
>
> Ja.
Nein. Lest bitte die Dokumentation etwas aufmerksamer. Wenn Exim die
Mail bereits angenommen hat und beim Routing ja feststellt, dass der DNS
auf den eigenen Host zeigt, /obwohl/ es sich nicht um eine als lokal
angesehene Domain handelt, dann steht er vor einem Problem. Wie das zu
"lösen" ist, bestimmt der Parameter "self".
Exim nimmt aber keine Mail für fremde Domains an, wenn man ihn nicht als
Relay konfiguriert. Wäre schlimm, wenn's anders wäre.
Thomas Schweikle
> Hallo Nils,
>
> * Nils Ketelsen <ni...@steering-group.net>:
>> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die Domain
>> der eingehenden Mail einen Vorwaertslookup zu machen, und wenn der auf einen
>> selber zeigt die Mail anzunehmen. Und es gibt Mailer da draussen, die so
>> konfiguriert sind.
>
> Mag sein, dass es die gibt. Dann sind sie kaputt (im Sinn von reichlich
> idiotisch).
Nein. Es ist notwendig unter bestimmten Umständen. Und zwar dann,
wenn es mehrere Namenszuordnungen zu einer Adresse geben kann. Das
dies mit DynDNS unerwünscht ist, steht auf einem anderen Blatt.
Das was bei meinem Test passiert ist, war, das es zu zwei Namen ein
und dieselbe Adresse gab. Das ist manchmal normal:
www.xyz.invalid
ftp.xyz.invalid
http.xyz.invalid
mail.xyz.invalid
news.xyz.invalid
imap.xyz.invalid
pop3.xyz.invalid
können alle auf dieselbe Adresse verweisen. Es ist praktisch einen
Server auf diese Art im DNS bekannt zu machen und dazu *keine* Alias
zu verwenden. Das die Rückwärtsauflösung immer nur einen Namen
liefert, verkompliziert die Konfiguration der diversen Systeme. Aber
es erleichtert, später, bei steigender Last, die Systeme auf eigene
Hardware umzuziehen, ohne irgend jemanden davon etwas sagen zu müssen.
Wie heist es immer in der Fahrschule: gehe davon aus, das die
anderen auch Fehler machen können! Wenn dein Server korrekt für die
Anwendung konfiguriert ist, dann muß es der anderer nicht sein!
Oder anders: betreibe deine Server so, das die Fehler anderer dir
keinen Schaden zufügen. Verlorene, oder falsch zugestellte Mail
schaden dir. Den anderen sind sie egal.
--
Thomas
Thomas Schweikle
> On 2005-01-15 20:32, Thomas Schweikle <t...@vr-web.de> wrote:
>> Felix M. Palmen schrieb:
>>
>>> * Thomas Schweikle <t...@vr-web.de>:
>>>> Jeder Hamster in der Grundkonfiguration (Zustellung an den
>>>> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
>>>> möglich. Spamschleudern mag aber niemand.
>>>
>>> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
>>> Korrekt wäre ja wohl so ein Verhalten:
>>> | RCPT TO:<te...@foobar.example>
>>> | 550 relay not permitted
>>
>> Es ist per Definition aber kein relaying, wenn die Adresse, an die
>> ich die Mail sende mir gehört. Dann ist einfach der Empfänger unbekannt.
>
> Unsinn. Es ist dann Relaying, wenn die Empfängeradresse zu einem anderen
> Mailserver gehört, als dem, über den Du gerade zu senden versuchst. Ob
> sie Dir als Absender gehört oder nicht, ist vollkommen irrelevant.
AK.
> Wenn also der Mailserver der Domain a.invalid zu einem bestimmten
> Zeitpunkt die IP-Adresse 10.1.2.3 hat und diese im DynDNS einträgt, und
> zu einem späteren Zeitpunkt diese IP-Adresse dem Mail-Server der Domain
> b.invalid zugewiesen wird, dann ist der Versuch, zu diesem Zeitpunkt,
> eine Mail an <te...@a.invalid> über den Server mit der IP-Adresse
> 10.1.2.3 zuzustellen, ein Relay-Versuch (denn der Server ist eben nur
> b.invalid zuständig, nicht für a.invalid, und müsste die Mail daher
> weiterleiten).
>
>
>> Genau das ist aber das Szenario, wenn DynDNS gerade mal einige
>> Adressen noch zu kennen behauptet, die eigentlich gerade nicht mehr
>> existieren sollten. Ganz einfacher Fall:
>>
>> Meine DynDNS-Domäne sei: invail.ipnet.de
>> Ich bin angemeldet und DynDNS kennt meine IP:
>>| C:\> nslookup invalid.homeip.net
>>| Server: www-proxy.UL1.srv.t-online.de
>>| Address: 217.237.150.141
>>|
>>| Nicht autorisierte Antwort:
>>| Name: invalid.homeip.net
>>| Address: 217.236.217.145
> ^^^^^^^^^^^^^^^
Arrrg: da war wohl ein s/145/88/ zuwenig!
>> Prima. Soweit alles OK.
>> Mein PC macht einen Abgang. Abmelden bei DynDNS unterbleibt
>> (DSL-Stecker gezogen).
> [...]
>> Das geht auch noch einige Minuten später:
>>| hazel: ~> nslookup invalid.homeip.net
>>| Server: www-proxy.UL1.srv.t-online.de
>>| Address: 217.237.150.141
>>|
>>| Nicht autorisierte Antwort:
>>| Name: invalid.homeip.net
>>| Address: 217.236.217.88
> ^^^^^^^^^^^^^^
>
> Moment! Da hat sich die IP-Adresse geändert. D.h., jemand hat für Deine
> Domain eine neue IP-Adresse angegeben - wer kann das außer Dir? (Ich
> kenne homeip.net nicht, nehme aber doch an, dass es da irgendeine Art
> der Authentifikation geben wird)
Nein --- einfach nicht alle Adressen entsprechend geändert.
>>| hazel: ~> ping -c1 invalid.homeip.net
>>| PING invalid.homeip.net (217.236.217.88): 56 data bytes
>>|
>>| --- invalid.homeip.net ping statistics ---
>>| 1 packets transmitted, 1 packets received, 0% packet loss
>>
>> Upps! Mein PC ist noch nicht wieder online (dazu hätte jemand
>> zuhause den Stecker wieder einstecken müssen --- da ist aber
>> niemand)! Das Abstürzen habe ich schließlich duch ziehen des
>> DSL-Kabels simmuliert. PC Nr. 2 hat einen eigenen DSL-Zugang und
>> steht etwa 80m entfernt beim Nachbarn.
>>
>> Wer garantiert dir, das dieser PC keinen Mailer mit SMTP laufen hat?
>> Mal testen:
> [...]
>>| hazel: ~> telnet invaild.homeip.net 25
>>| Trying 217.236.217.88...
>>| Connected to invalid.homeip.net.
>>| Escape character is '^]'.
>>| 220 margot ESMPT Postfix
>>| quit
>>| 221 Bye
>>| Connection closed by foreign host.
>>
>> Und --- warum sollte dieser PC die Mail mit "Relaying denied"
>> ablehnen?
>
> Weil er sich nicht für die Domain invalid.homeip.net zuständig fühlen
> sollte - das ist Deine Domain, nicht Margots.
Kann er aber doch. Wenn er so konfiguriert ist, das er den Namen
auflösen läßt. Der MTA schickt eine Abfrage an den DNS und bekommt
eine Adresse zurück. Die vergleicht er mit seiner eigenen. Stimmt.
Ist identisch. Muß ich also "invalid.homeip.net" sein. Her mit der Mail!
>> Die IP-Adresse stimmt!
>
> Irrelevant.
Nein. S.o.
>> Da DynDNS keine Rückwärtsauflösung unterstützt,
>
> Auch irrelevant. Wozu sollte der Server Rückwärtsauflösung brauchen?
Um festzustellen, ob eine angegebene IP-Adresse zu einem gegebenen
Namen gehört.
> Im
> Gegenteil, gerade dadurch würde er ja falsche Information bekommen, wenn
> der DynDNS-Record noch nicht upgedatet wurde.
Genau.
>> bleibt einem korrekt konfigurierten Mailer höchstens übrig die Mail
>> mit Empfänger unbekannt zu bouncen (sonst darf er überhaup keine Mail
>> annehmen!). Das ist aber auch eine Methode SPAM zu versenden.
>
> Er soll nicht bouncen, sondern rejecten.
Ja. Ich sollte auf meinen Ausdruck achten!
>> Einfach beides fälschen: Absender- und Empfängeradresse. Folge: wenn
>> ein Mailer an einer dynamischen Adresse hängt, sollte er eine Mail mit
>> "Empfänger unbekannt" *nicht* weiterschicken, es sei den der Admin
>> will es so.
>
> Das hat mit dynamisch oder fix überhaupt nichts zu tun, die
> Argumentation bleibt bei fixen IP-Adressen genau die gleiche. Ein MX
> soll Mail nur dann annehmen, wenn er sich einigermaßen sicher sein kann,
> dass er sie auch zustellen kann. Wenn er sie aber angenommen hat, dann
> darf er sie nicht einfach kommentarlos entsorgen. Da die Return-Adresse
> gefälscht sein kann (und insbesondere bei Spam und Würmern fast immer
> gefälscht ist), sollte er alle Checks durchführen, bevor er die Mail
> annimmt.
OK.
--
Thomas
Nils Ketelsen
>
> * Nils Ketelsen <ni...@steering-group.net>:
>>> Da hast du die Doku nicht so genau gelesen. Die Option self bestimmt,
>>> was passiert, wenn beim Mailrouting der Host des Servers selbst
>>> ermittelt wird. Das ist also erst dann relevant, wenn man die Mail
>>> bereits angenommen hat. Und das tut man für nicht-lokale Domains nur
>>> dann, wenn man als Relay funktionieren will.
>>
>> Ach? Dafuer langt es nicht das RCPT TO der Mail zu kennen? Faszinierend.
>
> Die Mail kommt erst in den router, nachdem sie angenommen wurde. Erst
> dort bestimmt dann die "self"-Option, was mit ihr geschehen soll, falls
> beim Routing wieder die eigene IP-Adresse ermittelt wird.
Das ist falsch. Exim geht die router durch, wenn ein rcpt-verify macht. Und
da er die router durchgeht wuerde er auch ein self=local bemerken.
> Wenn fragliche Domain aber nicht in den local_domains ist (und wie
> sollte sie da hineinkommen) und man auch nicht zufälligerweise für den
> Absender relayt, dann wird sie gar nicht erst angenommen. Daran ändert
> "self=local" absolut nichts.
Local-Domains ist nicht alles ;-)
Nils
--
Der Minister nimmt flüsternd den Bischof beim Arm:
"Halt Du sie dumm - ich halt sie Arm"
[Reinhard Mey, 'Sei Wachsam']
Felix M. Palmen
* Thomas Schweikle <t...@vr-web.de>:
> OK. Dann setzt du aber voraus, das der Mailer so konfiguriert ist,
> das er nur eine Mail an die eigene Domain akzeptiert. Das würde ich
> nicht einfach machen. Ich würde davon ausgehen, das jeder User
> seinen Server der einfachheit halber so konfiguriert hat, das dieser
> jede Mail annimmt --- egal welche Domäne die Empfängerdomäne ist.
Ein MTA, der in seine default-Konfiguration beliebig relayt, ist IMHO
aus verschiedenen Gründen gefährlich/schädlich. Eine Konfiguration, in
der nicht relayt wird, Mails an fremde Domains aber trotzdem angenommen
werden und in einer Art Versenkung verschwinden, ist nicht ganz so
schlimm, wie ein offenes Relay, aber immer noch reichlich idiotisch.
Exim macht per default keines von beiden und um ihn zu letzterem zu
zwingen, müsste man entprechend dämliche Router selbst schreiben. Ich
war einfach mal davon ausgegangen, dass die meisten anderen MTAs sich
ebenso vernünftig benehmen.
> Ich könnte zum Beispiel einfach "*.t-online.de" zulassen. Das wäre
> dann zwar eine Fehlkonfiguration, aber mein Server würde damit seine
> Adresse rückwärts auflösen können. Der Domänenteil wäre korrekt und
> damit die Mail akzeptabel.
Erstens wäre es eine Fehlkonfiguration, die noch dazu völlig sinnlos
ist. Mal abgesehen davon, dass sich dialup-Hosts nicht in der Domain
"t-online.de" sondern "dip.t-dialin.net" befinden, wäre die Mail aber
auch damit noch lange nicht akzeptabel, denn sie ist schließlich nicht
an "*.dip.t-dialin.net" adressiert.
> Was ist mit Software, die den Hostnamen immer auf den Dail-In-Namen
> setzt (AFAIK hat die T-Online-Software diese Angewohnheit --- ob das
> heute noch so ist, kann ich nicht sagen. Ich verwende sie nicht mehr).
Nichts. Es ist akzeptables Verhalten, den Hostnamen auf den DNS-Eintrag
der dynamischen IP zu setzen. Für diesen gibt es aber keinen MX-Record,
es wird also niemals Mail an deinen dynamischen Hostnamen bei dir
ankommen.
Nils Ketelsen
>> Was ist mit Software, die den Hostnamen immer auf den Dail-In-Namen
>> setzt (AFAIK hat die T-Online-Software diese Angewohnheit --- ob das
>> heute noch so ist, kann ich nicht sagen. Ich verwende sie nicht mehr).
> Nichts. Es ist akzeptables Verhalten, den Hostnamen auf den DNS-Eintrag
> der dynamischen IP zu setzen. Für diesen gibt es aber keinen MX-Record,
> es wird also niemals Mail an deinen dynamischen Hostnamen bei dir
> ankommen.
Existiert kein MX-Record wird mail an den A-Record zugestellt. Das verlangt
der RfC so.
Nils
--
- Proponenten führen sich (z.T.) auf, wie die Borg nach einer Nacht in
Schlumpfhausen.
[Kai Bojens in de.alt.admin .. Letzter Punkt zur Erklärung seines Protestes]
Felix M. Palmen
* Thomas Schweikle <t...@vr-web.de>:
> Felix M. Palmen schrieb:
>> * Nils Ketelsen <ni...@steering-group.net>:
>>> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer
>>> die Domain der eingehenden Mail einen Vorwaertslookup zu machen, und
>>> wenn der auf einen selber zeigt die Mail anzunehmen. Und es gibt
>>> Mailer da draussen, die so konfiguriert sind.
>>
>> Mag sein, dass es die gibt. Dann sind sie kaputt (im Sinn von reichlich
>> idiotisch).
>
> Nein. Es ist notwendig unter bestimmten Umständen. Und zwar dann,
> wenn es mehrere Namenszuordnungen zu einer Adresse geben kann. Das
> dies mit DynDNS unerwünscht ist, steht auf einem anderen Blatt.
>
> Das was bei meinem Test passiert ist, war, das es zu zwei Namen ein
> und dieselbe Adresse gab. Das ist manchmal normal:
>
> www.xyz.invalid
> ftp.xyz.invalid
> http.xyz.invalid
> mail.xyz.invalid
> news.xyz.invalid
> imap.xyz.invalid
> pop3.xyz.invalid
local_domains = xyz.invalid:*.xyz.invalid
Und wozu jetzt die Geschichte mit dem Vorwärtslookup? Wenn man den MX
für xyz.invalid so konfigurieren würde, würde er ja z.B. Mail für
ftp.xyz.invalid nicht mehr annehmen, sobald der FTP-Server auf einen
anderen Host umzieht. Sorry, aber das ergibt absolut keinen Sinn. Erst
recht nicht als default.
> Wie heist es immer in der Fahrschule: gehe davon aus, das die
> anderen auch Fehler machen können!
Genau deshalb wäre es blödsinnig, aufgrund eines Vorwärts-Lookups eine
Mail anzunehmen. Im DNS kann es Fehler geben. Sieht auch die Doku zu
Exim so:
| This option specifies what is to happen if routing a remote address ends
| up pointing at the local host [..] Normally this indicates either an
| error in Exim's configuration [..] or an error in the DNS [..].
Ein "self = local" ist also ein Sonderfall. Und wie schon gesagt, damit
das greift, muss die Mail überhaupt erstmal angenommen worden sein.
Darauf hat "self" keinen Einfluss.
> Oder anders: betreibe deine Server so, das die Fehler anderer dir
> keinen Schaden zufügen.
Darum geht es mir nicht mehr. Habe bereits geschrieben, dass in über
zwei Jahren noch kein derartiges Problem vorgekommen ist, das reicht mir
für meine privaten Mails voll und ganz und ist da ja auch meine
Entscheidung.
Felix M. Palmen
* Thomas Schweikle <t...@vr-web.de>:
> Kann er aber doch. Wenn er so konfiguriert ist, das er den Namen
> auflösen läßt. Der MTA schickt eine Abfrage an den DNS und bekommt
> eine Adresse zurück. Die vergleicht er mit seiner eigenen. Stimmt.
> Ist identisch. Muß ich also "invalid.homeip.net" sein. Her mit der Mail!
Genau das ist ausgemachter Schwachsinn. Wenn ein MTA überhaupt den
eigenen Hostnamen via DNS bestimmen will, dann über einen reverse
lookup. Und der ergibt niemals "invalid.homeip.net".
Ein MTA, der sich so verhält, wie du oben schreibst, ist wirklich als
kaputt(-konfiguriert) anzusehen. Ich wüsste jetzt doch gern mal, ob
Hamster das per default wirklich /so/ macht...
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Das ist falsch. Exim geht die router durch, wenn ein rcpt-verify macht. Und
> da er die router durchgeht wuerde er auch ein self=local bemerken.
Bemerken würde er es, aber wieso sollte das zur Annahme der Mail führen?
Der default-Wert "freeze" führt schließlich auch nicht zur Annahme.
> Local-Domains ist nicht alles ;-)
Sofern man für den Absender nicht relayt: doch. Habe es eben sogar
ausprobiert, mit route_list = "* 192.168.99.2" (was die eigene Adresse
ist) und self = local im einzigen Router. Ergebnis:
550 relaying to <f...@bar.example> prohibited by administrator
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Felix M. Palmen <zir...@despammed.com> wrote:
>> Nichts. Es ist akzeptables Verhalten, den Hostnamen auf den DNS-Eintrag
>> der dynamischen IP zu setzen. Für diesen gibt es aber keinen MX-Record,
>> es wird also niemals Mail an deinen dynamischen Hostnamen bei dir
>> ankommen.
>
> Existiert kein MX-Record wird mail an den A-Record zugestellt. Das verlangt
> der RfC so.
Oh wirklich? Na gut, hatte den Fall nie :) Ist aber im Prinzip auch
egal, deshalb wird der MTA trotzdem nicht plötzlich Mail für eine völlig
andere Domain, in deren A-Record er aus Versehen gerade steht, annehmen.
Nils Ketelsen
>> Local-Domains ist nicht alles ;-)
>
> Sofern man für den Absender nicht relayt: doch. Habe es eben sogar
> ausprobiert, mit route_list = "* 192.168.99.2" (was die eigene Adresse
> ist) und self = local im einzigen Router. Ergebnis:
> 550 relaying to <f...@bar.example> prohibited by administrator
Und bar.example hat auch den lowest MX auf den gleichen Rechner? Sonst
testest Du da ja was ganz anderes.
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Felix M. Palmen <zir...@despammed.com> wrote:
>> Sofern man für den Absender nicht relayt: doch. Habe es eben sogar
>> ausprobiert, mit route_list = "* 192.168.99.2" (was die eigene Adresse
>> ist) und self = local im einzigen Router. Ergebnis:
>> 550 relaying to <f...@bar.example> prohibited by administrator
>
> Und bar.example hat auch den lowest MX auf den gleichen Rechner? Sonst
> testest Du da ja was ganz anderes.
*lies* *die* *Doku*. Bitte.
| self Type: string Default: "freeze"
|
| This option specifies what is to happen if routing a remote address ends
| up pointing at the local host (checked by comparing IP addresses)
[...]
Mit meiner zum Test verwendeten route_list ist das /immer/ der Fall. Das
mit dem lowest MX ist in der Doku lediglich ein Beispiel, wann "self =
local" sinnvoll sein könnte.
Peter J. Holzer
> Peter J. Holzer schrieb:
>
>> On 2005-01-15 20:32, Thomas Schweikle <t...@vr-web.de> wrote:
>>> Wer garantiert dir, das dieser PC keinen Mailer mit SMTP laufen hat?
>>> Mal testen:
>> [...]
>>>| hazel: ~> telnet invaild.homeip.net 25
>>>| Trying 217.236.217.88...
>>>| Connected to invalid.homeip.net.
>>>| Escape character is '^]'.
>>>| 220 margot ESMPT Postfix
>>>| quit
>>>| 221 Bye
>>>| Connection closed by foreign host.
>>>
>>> Und --- warum sollte dieser PC die Mail mit "Relaying denied"
>>> ablehnen?
>>
>> Weil er sich nicht für die Domain invalid.homeip.net zuständig fühlen
>> sollte - das ist Deine Domain, nicht Margots.
>
> Kann er aber doch.
Ich schrieb, er sollte nicht. Dass er kann, ist mir klar.
> Wenn er so konfiguriert ist, das er den Namen auflösen läßt. Der MTA
> schickt eine Abfrage an den DNS und bekommt eine Adresse zurück. Die
> vergleicht er mit seiner eigenen. Stimmt. Ist identisch. Muß ich also
> "invalid.homeip.net" sein.
Das ist ein Fehlschluss.
> Her mit der Mail!
Und das ebenfalls. Nur weil der Hostname identisch ist, muss er nicht
für die Mail zuständig sein. (Deswegen gibt es ja MX-Records)
>>> Die IP-Adresse stimmt!
>>
>> Irrelevant.
>
> Nein. S.o.
>
>>> Da DynDNS keine Rückwärtsauflösung unterstützt,
>>
>> Auch irrelevant. Wozu sollte der Server Rückwärtsauflösung brauchen?
>
> Um festzustellen, ob eine angegebene IP-Adresse zu einem gegebenen
> Namen gehört.
Diese Information hat aber genau gar nichts damit zu tun, ob er für eine
bestimmte Domain zuständig ist oder nicht. Außer Vergabe von
IP-Adressen, Vorwärts- und Rückwärtsauflösung unterliegen der Kontrolle
der gleichen Person/Organisation: Dann - und nur dann - kann man
sicherstellen, dass die Information stimmt.
Bei DynDNS kann man das eben nicht sicherstellen, daher muss man die
lokalen Domains lokal konfigurieren, wenn man nicht gelegentlich anderer
Leute Mails abfangen will.
>> Im Gegenteil, gerade dadurch würde er ja falsche Information
>> bekommen, wenn der DynDNS-Record noch nicht upgedatet wurde.
>
> Genau.
Und genau deshalb sollte man das eben nicht machen.
Peter J. Holzer
>>> Nichts desto Trotz gibt es mailer, denen man beibringen kann fuer die Domain
>>> der eingehenden Mail einen Vorwaertslookup zu machen, und wenn der auf einen
>>> selber zeigt die Mail anzunehmen. Und es gibt Mailer da draussen, die so
>>> konfiguriert sind.
>>
>> Mag sein, dass es die gibt. Dann sind sie kaputt (im Sinn von reichlich
>> idiotisch).
>
> Nein. Es ist notwendig unter bestimmten Umständen.
Nein, es ist nie notwendig. Es mag unter bestimmten Umständen marginal
weniger Aufwand sein (man spart sich eine Zeile in einem Configfile).
> Und zwar dann, wenn es mehrere Namenszuordnungen zu einer Adresse
> geben kann. Das dies mit DynDNS unerwünscht ist, steht auf einem
> anderen Blatt.
>
> Das was bei meinem Test passiert ist, war, das es zu zwei Namen ein
> und dieselbe Adresse gab. Das ist manchmal normal:
>
> www.xyz.invalid
> ftp.xyz.invalid
> http.xyz.invalid
> mail.xyz.invalid
> news.xyz.invalid
> imap.xyz.invalid
> pop3.xyz.invalid
>
> können alle auf dieselbe Adresse verweisen.
Natürlich. Man kann die auch alle in die Localdomains eintragen. Oder
auch nicht, wenn man nicht für alle diese Domains Mail auf dieser
Maschine empfangen will.
Und spätestens dann:
> Aber es erleichtert, später, bei steigender Last, die Systeme auf
> eigene Hardware umzuziehen, ohne irgend jemanden davon etwas sagen zu
> müssen.
musst Du es sowieso machen, denn nur weil Du jetzt einen eigenen
Webserver hast, muss der Webserver noch nicht auch Mailserver sein.
Ralf Döblitz
>> bleibt einem korrekt konfigurierten Mailer höchstens übrig die Mail
>> mit Empfänger unbekannt zu bouncen
>
> Nein, er kann (bzw muss) sie ablehnen, z.B. mit 550 relaying denied. Die
> Domain ist eben keine seiner lokalen Domains, also wäre es Relaying, sie
> anzunehmen und selbst Zustellversuche zu unternehmen. Diese würden dann
> allerdings in der Tat scheitern.
Oder er nimmt einfach alles an und leitet das, was nicht korrekt an das
lokale System gerichtet ist einfach an einen Spamfilter weiter. Da
Spammer ja durchaus noch gerne nach offenen Relays in Dialup-Netzen
suchen kann man mit so einem Honeypot auch recht nett Spamfilter
trainieren.
Ralf
--
Ralf Döblitz * Schapenstraße 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@doeblitz.net
Homepage: http://www.escape.de/users/selene/
Mit UTF-8 kann man gleichzeitig äöüßÄÖÜæœłø¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ verwenden.
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
> Oder er nimmt einfach alles an und leitet das, was nicht korrekt an das
> lokale System gerichtet ist einfach an einen Spamfilter weiter. Da
> Spammer ja durchaus noch gerne nach offenen Relays in Dialup-Netzen
> suchen kann man mit so einem Honeypot auch recht nett Spamfilter
> trainieren.
So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
davon ausgehen können, dass er zumindest Versuche unternimmt, sie
zuzustellen.
Nils Ketelsen
> So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
> zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
Ja. Aber deswegen davon auszugehen, dass es niemand tut ist leichtsinnig.
Nils
--
15:37 <@Zugschlus> $FLUCH
15:37 <@range> "Möge dir der Weihnachtsmann mit den Kufen seines Schlittens
über die Füße fahren!"
Ralf Döblitz
>
> * Ralf Döblitz <doeb...@doeblitz.net>:
>> Oder er nimmt einfach alles an und leitet das, was nicht korrekt an das
>> lokale System gerichtet ist einfach an einen Spamfilter weiter. Da
>> Spammer ja durchaus noch gerne nach offenen Relays in Dialup-Netzen
>> suchen kann man mit so einem Honeypot auch recht nett Spamfilter
>> trainieren.
>
> So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
> zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
> davon ausgehen können, dass er zumindest Versuche unternimmt, sie
> zuzustellen.
Nö. Mein Server, meine Entscheidung. Wer ich als MX einträgt oder als
Smarthost benutzen will ohne dies vorher mit mir bereinbart zu haben,
der riskiert eben, daß diese Mail exakt als das behandelt wird, was sie
darstellt: unsolicited email. Und die kann man gut zum Spamfiltertrai-
ning benutzen, damit erhöht man die Chancen, daß Spam, der auf den
_echten_ Adressen aufschlägt, bereits automatisch als solcher erkannt
wird.
Wer Mail blind irgendwem anvertraut ohne zu prüfen, ob der dafür über-
haupt zuständig ist, der riskiert halt Verluste.
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Felix M. Palmen <zir...@despammed.com> wrote:
>
>> So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
>> zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
>
> Ja. Aber deswegen davon auszugehen, dass es niemand tut ist leichtsinnig.
Wo habe ich das denn geschrieben? Natürlich gibt bei jedem Mist, den man
machen kann, immer auch jemanden, der ihn wirklich macht.
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
> Felix M. Palmen <zir...@despammed.com> wrote:
>> So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
>> zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
>> davon ausgehen können, dass er zumindest Versuche unternimmt, sie
>> zuzustellen.
>
> Nö.
Doch.
> Mein Server, meine Entscheidung.
In der Tat. Man kann sich für so manch asoziales Verhalten entscheiden
und niemand kann es einem verbieten.
> Wer ich als MX einträgt oder als Smarthost benutzen will ohne dies
> vorher mit mir bereinbart zu haben, der riskiert eben, daß diese Mail
> exakt als das behandelt wird, was sie darstellt: unsolicited email.
Unsinn. Schließlich ist sie nicht an dich adressiert. Sie ist vielleicht
von dir nicht erwünscht, aber deshalb muss das noch lange keine
unerwünschte Mail sein. Wenn du nicht relayen willst, lehne sie ab.
Ansonsten sabotierst du das System Email.
> Und die kann man gut zum Spamfiltertrai- ning benutzen, damit erhöht
> man die Chancen, daß Spam, der auf den _echten_ Adressen aufschlägt,
> bereits automatisch als solcher erkannt wird.
Allein aus der Tatsache, dass Mail bei dir ankommt, die nicht zu deiner
Domain gehört, auf Spam zu schließen, halte ich zwar auch für unsinnig,
aber wenn du das unbedingt willst kannst du deinen Spamfilter damit
trainieren und sie trotzdem nach DATA noch korrekt ablehnen.
> Wer Mail blind irgendwem anvertraut ohne zu prüfen, ob der dafür über-
> haupt zuständig ist, der riskiert halt Verluste.
Der Absender von Mail hat keinen Einfluss auf eventuelle Fehler und/oder
Ausfälle im DNS und auf den einzelnen Mailservern unterwegs.
Nils Ketelsen
> Hallo Nils,
> * Nils Ketelsen <ni...@steering-group.net>:
>> Felix M. Palmen <zir...@despammed.com> wrote:
>>> So zu tun, als würde man relayen, und die Mail dann einfach verschwinden
>>> zu lassen, ist asozial. Wenn ein MTA eine Mail annimmt, muss der Sender
>> Ja. Aber deswegen davon auszugehen, dass es niemand tut ist leichtsinnig.
> Wo habe ich das denn geschrieben? Natürlich gibt bei jedem Mist, den man
> machen kann, immer auch jemanden, der ihn wirklich macht.
Darum ging es frueher doch mal in diesem Thread, wenn ich mich recht
entsinne. Was passiert, wenn mein MX-Record noch auf die alte IP zeigt und
die jetzt ein anderer hat, oder so. Oder verwechsel ich das jetzt?
Nils
--
Die EG-Gesundheitsminister:
Standleitungen verursachen Blässe
Felix M. Palmen
* Nils Ketelsen <ni...@steering-group.net>:
> Darum ging es frueher doch mal in diesem Thread, wenn ich mich recht
> entsinne. Was passiert, wenn mein MX-Record noch auf die alte IP zeigt und
> die jetzt ein anderer hat, oder so. Oder verwechsel ich das jetzt?
Darum ging es, ich habe aber nie etwas anderes behauptet, als dass es
prinzipiell passieren /kann/, dass Mail verschwindet. Nach meiner
Erfahrung ist das Risiko dafür allerdings nahe genug bei Null, dass ich
damit voll zufrieden bin und es auch anderen für ihre private
Kommunikation durchaus empfehlen kann.
Hier wollte ich eigentlich nur noch wissen, ob Hamster wirklich per
default derart idiotisch konfiguriert ist oder ob es sogar noch andere
MTAs mit einer solch blöden Konfiguration gibt. Wenn dem tatsächlich so
ist und Hamster noch dazu in Mode kommt, sieht es nämlich irgendwann in
Zukunft schlechter aus für MX auf dyndns.
Ralf Döblitz
> Ansonsten sabotierst du das System Email.
Das will ich in manchen Fällen sogar. Bei RBL-betriebern nennt sich so
etwas dann zum Beispiel "Spamtrap". Und genau das kann man auch für sich
selbst zuhause machen, wenn man seinen Rechner mit dynamischer
IP-Adresse nirgends als MX einträgt. Wer dort einliefert, der veruscht
offensichtlich zu spammen und genau so wird die Mail auch behandelt: sie
wird diversen Spamerkennungsdiensten zugeliefert (sa-learn läßt grüßen).
[...]
> Allein aus der Tatsache, dass Mail bei dir ankommt, die nicht zu deiner
> Domain gehört, auf Spam zu schließen, halte ich zwar auch für unsinnig,
> aber wenn du das unbedingt willst kannst du deinen Spamfilter damit
> trainieren und sie trotzdem nach DATA noch korrekt ablehnen.
OK, könnte man tun. Wäre vielleicht nett gegenüber den <censored>, die
dynamische Adressen für MXe verwenden. Aber wenn sie keine fehler
machen, dann kann ihnen das ja eh nicht pasieren, daß _ihre_ Mail bei
mir eingeliefert wird. Also kann es sich wirklich nur um Spammer
handeln. und denen gegenüber *will* ich mich nicht nett verhalten.
>> Wer Mail blind irgendwem anvertraut ohne zu prüfen, ob der dafür über-
>> haupt zuständig ist, der riskiert halt Verluste.
>
> Der Absender von Mail hat keinen Einfluss auf eventuelle Fehler und/oder
> Ausfälle im DNS und auf den einzelnen Mailservern unterwegs.
Tja, dann sollte er mal den DNS-Betreiber des Empfängers treten, daß
dieser keinen groben Unsinn wie z.B. MXe über DynDNS macht. Aber ich
glaube wir drehen uns da jetzt im Kreis. :-)
Felix M. Palmen
* Ralf Döblitz <doeb...@doeblitz.net>:
[MTA ohne MX-Eintrag]
> Wer dort einliefert, der veruscht offensichtlich zu spammen und genau
> so wird die Mail auch behandelt: sie wird diversen
> Spamerkennungsdiensten zugeliefert (sa-learn läßt grüßen).
Erstens funktioniert bei mir der Bayes-Filter geradezu perfekt ganz ohne
solche seltsamen Ideen.
Zweitens schadest du deinem Bayes-Filter eher, denn er soll ja möglichst
auf den Spam trainiert werden, den /du/ typischerweise erhältst.
Drittens gehst du damit davon aus, dass DNS und Mailrouting auf anderen
Systemen fehlerfrei funktionieren. Das kannst du aber nicht
voraussetzen. Bei DynDNS sind falsche DNS-Einträge für kurze Zeiträume
unumgänglich, aber das bedeutet umgekehrt noch lange nicht, dass andere
DNS-Einträge vor Fehlern sicher sind. Und dass jemandem in seinen
Mailrouting-Regeln ein Fehler unterläuft, kann ebenfalls nicht
ausgeschlossen werden.
>> aber wenn du das unbedingt willst kannst du deinen Spamfilter damit
>> trainieren und sie trotzdem nach DATA noch korrekt ablehnen.
>
> OK, könnte man tun. Wäre vielleicht nett gegenüber den <censored>, die
> dynamische Adressen für MXe verwenden.
IMHO ist das keine Frage von nett oder nicht nett, sondern eine von
richtig oder falsch. Eine Mail, die man nicht ausliefern kann/will, hat
man abzulehnen oder zu bouncen. Alles andere ist falsch.
"Nett" ist es dann, so viele Tests wie möglich bereits im SMTP-Dialog zu
unternehmen, um nach Möglichkeit ablehnen zu können, denn Bounces können
ja bekanntermaßen problematisch sein ;)
> Aber wenn sie keine fehler machen, dann kann ihnen das ja eh nicht
> pasieren, daß _ihre_ Mail bei mir eingeliefert wird. Also kann es sich
> wirklich nur um Spammer handeln. und denen gegenüber *will* ich mich
> nicht nett verhalten.
Verwechselst du da jetzt nicht den Absender mit dem Empfänger und/oder
den Admins dazwischenliegender Systeme?
Wilfried Kramer
> da muss ich doch nochmal kurz einhaken:
Und wo kommt der Thread jetzt her?
> * Thomas Schweikle <t...@vr-web.de>:
>> Jeder Hamster in der Grundkonfiguration (Zustellung an den
>> Hamster-Admin: unbekannter Empfänger). Grund: sonst wäre relaying
>> möglich. Spamschleudern mag aber niemand.
>
> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
Nein.
Die *Grundkonfiguration* ist, daß da niemand von außen dran kommt. Da
liegen mindestens zwei Sperren davor. Jedes andere Szenario ist nicht
Grund, und muß mit entsprechender Arbeit erst einmal ermöglicht werden.
> Korrekt wäre ja wohl so ein Verhalten:
> | RCPT TO:<te...@foobar.example>
> | 550 relay not permitted
>
> Es sei denn natürlich er wird nur mit Mails gefüttert, die irgendwo aus
> anderen Mailboxen abgeholt wurden. In dem Fall ist es nämlich bereits
> völlig sinnfrei, ihn überhaupt erst am externen Interface horchen zu
> lassen.
Oder Hamster dient als Endpunkt einer selbst eingerichteten
Weiterleitung. Dann braucht man allerdings nicht jedem Zugriff zu
ermöglichen, sondern genau diesem Rechner. Wenn man weiß, welcher es
ist. Kennst Du z.B. alle IP-Adressen der fraglichen Rechner bei GMX? Und
erfährst Du etwaige Änderungen rechtzeitig?
Und dann gibt es noch die Leute, die Hamster tatsächlich als MX
einsetzen wollen. Nicht besonders sinnvoll IMO, aber was will man tun?
Wilfried
--
Was schlaegt meine Rechtschreibpruefung fuer "Winmodem" vor?
"Windigem", Recht hat sie!!
Felix M. Palmen
* Wilfried Kramer <selten....@arcor.de>:
> zir...@despammed.com (Felix M. Palmen) wrote:
>
>> da muss ich doch nochmal kurz einhaken:
>
> Und wo kommt der Thread jetzt her?
Hm?
>> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
>
> Nein.
> Die *Grundkonfiguration* ist, daß da niemand von außen dran kommt. Da
> liegen mindestens zwei Sperren davor. Jedes andere Szenario ist nicht
> Grund, und muß mit entsprechender Arbeit erst einmal ermöglicht werden.
Na, da bin ich dann ja beruhigt. Dass man mit den meisten MTAs auch
recht sinnfreie Konfigurationen hinbekommt ist ja nicht unbedingt der
Fehler betreffender MTAs.
>> Korrekt wäre ja wohl so ein Verhalten:
>> | RCPT TO:<te...@foobar.example>
>> | 550 relay not permitted
>>
>> Es sei denn natürlich er wird nur mit Mails gefüttert, die irgendwo aus
>> anderen Mailboxen abgeholt wurden. In dem Fall ist es nämlich bereits
>> völlig sinnfrei, ihn überhaupt erst am externen Interface horchen zu
>> lassen.
>
> Oder Hamster dient als Endpunkt einer selbst eingerichteten
> Weiterleitung. Dann braucht man allerdings nicht jedem Zugriff zu
> ermöglichen, sondern genau diesem Rechner. Wenn man weiß, welcher es
> ist. Kennst Du z.B. alle IP-Adressen der fraglichen Rechner bei GMX? Und
> erfährst Du etwaige Änderungen rechtzeitig?
Wozu? Auch dann weiß man doch, für welche Mail-Adressen man Mail
annehmen will und für welche nicht.
> Und dann gibt es noch die Leute, die Hamster tatsächlich als MX
> einsetzen wollen. Nicht besonders sinnvoll IMO, aber was will man tun?
Naja ist das denn ein Problem? Kann man ihn nicht so konfigurieren, dass
er als MX korrekt seinen Dienst tut?
Wilfried Kramer
> Felix M. Palmen schrieb:
>> * Joern Bredereck <j...@bw-networx.net>:
>>> ja, und bis dahin werden die Mails an die letzte IP geschickt, bei der
>>> das Update noch geklappt hat. Da die Ausfälle einige Stunden angehalten
>>> haben, konnten in der Zeit ne ganze Reihe von SMTP-Servern die IP und
>>> somit auch die E-Mails bekommen.
>> Wieviele Leute haben auf ihren privaten Kisten SMTP-Server laufen?
>
> Diverse Hamster-Nutzer.
Für den internen Gebrauch, und als Relay von innen nach außen.
>> Wieviele davon nehmen beliebige Mail einfach an?
>
> Jeder Hamster in der Grundkonfiguration.
Das ist ganz grob falsch.
In der Grundkonfiguration ist der Hamster nicht einmal von außen
sichtbar. Ganz zu schweigen von einem erfolgreichen Kontakt oder gar der
Annahme von Mails.
Wenn man diese beiden Hürden manuell beseitigt (das ist nicht gar so
schwer), dann wird der Hamster zum offenen Relay. Eben deswegen
existieren besagte Hürden. Man kann auch das ändern. Das ist dann aber
keine Grundkonfiguration mehr.
Wilfried
--
Diese Signatur wurde per Zufall ausgewaehlt, ist aber nicht repraesentativ
Wilfried Kramer
> Hier wollte ich eigentlich nur noch wissen, ob Hamster wirklich per
> default derart idiotisch konfiguriert ist
Ich kann Dir versichern, daß das keineswegs der Fall ist. Aber ich
schreibe das besser einmal detailliert auf.
Ein frisch installierter Hamster bindet seinen SMTP-Server an 127.0.0.1,
und nirgendwo sonst. Das ist die Grundkonfiguration. So man in einem LAN
sitzt, kann man diese Bindung leicht ändern, dann sinnvollerweise an die
NIC des LAN.
Oder an 0.0.0.0, wenn man wirklich global erreichbar sein will.
Aber selbst dann hat nur localhost[1] Zugriff, sowie 192.168.0.0/16. Alle
anderen werden abgelehnt, mit einer kurzen Meldung.
Auch das kann man ändern, das ist aber schon schwieriger. Man muß hier
als erlaubte Quellen 0.0.0.0/0[2] eintragen. Dann nimmt Hamster erst einmal
jede Mail an. Je nach RCPT TO: wird die Mail in der lokalen Mailbox
abgelegt, das ist natürlich der erwünschte Fall. Oder im Mail.out. Wie der
Name andeutet, ist das die Ausgangsqueue des Hamsters. In diesem Zustand
ist er ein offenes Relay. Sofern der Hamster einen Smarthost kennt, den er
benutzen darf.
Das will man natürlich auch nicht. Dazu gibt es weitere Konfigurationen.
Zuständigkeit:
| local.mail.islocaldomain=.*hamster|\[?127\.0\.0\.1\]?|.*invalid
| ; Legt fest, ob der FQDN für die Message.ID’s eine lokale Domain ist.
| local.mail.LocalMIDFQDN=1
Hier fehlt in der Hilfe die Beschreibung. Diese RegExp defineirt, für
welche Domains Hamster zuständig sein soll.
Außerdem nimmt Hamster Mails an für Adressen, die als lokale Adressen
der Mailboxen eingetragen sind.
| ; Bounce senden, wenn Mails für unbekannte User am lokalen
| ; SMTP-Server eintreffen.
| local.mail.BounceIfUnknownUser=0
Ich bin mir jetzt nicht sicher, ob das nun Reject oder Bounce meint.
Hier aber egal, wir reden ja vom Prinzip, und das akzeptiert einen
Bounce. Diese Einstellung ist per Default aus.
Verhindern von offenem Relay:
| ; Nicht autorisierten Usern am lokalen SMTP-Server trotz eingeschaltetem
| ; SMTP-Auth das Einliefern von Mails für lokale Empfänger gestatten
| local.mail.reqnotauth=0
Der SMTP-Server wird zunächst[3] so konfiguriert, daß SMTP-AUTH verlangt
wird. Vorzugsweise mit TLS, dann kann man "seinen" Hamster auch von
unterwegs benutzen. Diese Einstellung hier erlaubt dann auch die
Zustellung von Mails ohne AUTH, dann aber nur an lokale Adressen. Zu lokal
siehe oben.
Diese Zitate stammen direkt aus der aktuellen Hilfe zum Hamster Classic.
Ich sehe da nur eine Möglichkeit, *alle* Mails dem Admin[4] zuzustellen.
Nämlich ausdrücklich .* als lokale Domain einzutragen. Ansonsten geht nur
Catch-All, also alle Mails für die als lokal definierten Domains. Und alle
annehmen, und nach Mail.out legen, das geht auch. Wenn man dem Hamster
dann kein Relay zum Weiterversand mitteilt, dann versacken in der Tat die
Mails. Genaugenommen hat man damit aber nur den Postmaster beauftragt, den
Weiterversand manuell anzustoßen.
Es mag beim Hamster Playground anders aussehen, aber ehrlich gesagt
bezweifele ich das. Classic hat die größte Verbreitung, aber wer einen
MX betreiben will, der nimmt vermutlich eher den Playground.
Der beherrscht auch die direkte Zustellung an den Ziel-MX. Und dann gibt
es natürlich noch diverse andere Linien, Hamster-FR etwa.
Keiner davon[5] ist als Default überhaupt von außen erreichbar. Also ist die
fragliche Behauptung schon aus diesem simplen Grund falsch, und zwar sehr
falsch. Ein öffentlich erreichbarer Hamster ist nicht mehr
Grundkonfiguration. Es kann maximal eine Anleitung im Netz geben, die die
Konfiguration als MX erläutert. Und diese Anleitung kann falsche Angaben
zur erforderlichen Konfiguration enthalten.
Wilfried
Fußnoten:
¯¯¯¯¯¯¯¯¯
[1] und dessen öffentliche Adressen
[2] in anderer Syntax: 0.0.0.0 bis 255.255.255.255
[3] an anderer Stelle
[4] genauer dem Postmaster, ein Alias für den Admin
[5] jedenfalls weiß ich von keiner
--
Stell Dir mal vor, Du waerst immer nur gut drauf. Du wuerdest doch gar
nicht mehr wissen, dass Du gut drauf bist. (Olaf Zerres in dafa)
Wolfgang Jäth
>
> > Und dann gibt es noch die Leute, die Hamster tatsächlich als MX
> > einsetzen wollen. Nicht besonders sinnvoll IMO, aber was will man tun?
>
> Naja ist das denn ein Problem? Kann man ihn nicht so konfigurieren, dass
> er als MX korrekt seinen Dienst tut?
'Kann man ein Fahrrad nicht so konfigurieren, daß es als
30-Tonnen-Stahltransporter seinen Dienst tut?'
Hint: Der Hamster ist ein *lokaler* Server, und kein INN- oder exim-Ersatz.
Wie Wilfried schon sagte, muss jeder andere Verwendungszweck erst einmal mit
entsprechendem Aufwand künstlich herbeimanipuliert werden. Es gibt zwar
einige Ansätze, den Hamster entsprechend zu erweitern, aber das sind
*Ansätze*, und IMHO noch lange nicht ernsthaft einsetzbar.
Bitte informiere Dich erst mal über das, wovon Du redest, bevor Du
Schwachsinn produzierst.
Wolfgang
--
Felix M. Palmen
* Wolfgang Jäth <jawo.us...@goldmail.de>:
> Bitte informiere Dich erst mal über das, wovon Du redest, bevor Du
> Schwachsinn produzierst.
Vielleicht solltest du erst mal den Thread lesen, bevor du andere dumm
anmachst. Ich kenne Hamster nicht und habe nie was anderes behauptet,
die Behauptung, er nehme per default alle Mails an und schicke sie nicht
weiter, kam von anderer Seite, und die fand ich unglaubwürdig.
Wilfried Kramer
> * Wilfried Kramer <selten....@arcor.de>:
>> Und wo kommt der Thread jetzt her?
>
> Hm?
Mein Fehler, hatte nicht mit einem simplen Subjectwechsel gerechnet.
>>> Dann ist die Grundkonfiguration von Hamster aber wirklich "kaputt".
>> Nein.
>> Die *Grundkonfiguration* ist, daß da niemand von außen dran kommt. Da
>> liegen mindestens zwei Sperren davor. Jedes andere Szenario ist nicht
>> Grund, und muß mit entsprechender Arbeit erst einmal ermöglicht werden.
>
> Na, da bin ich dann ja beruhigt. Dass man mit den meisten MTAs auch
> recht sinnfreie Konfigurationen hinbekommt ist ja nicht unbedingt der
> Fehler betreffender MTAs.
Dein Problem ist aber doch ein anderes. Auch wenn Du das nicht als
Problem sehen willst. Wieviele MX laufen an DynDNS rum, und nehmen
einfach alles ohne Weiterleitung an? Hamster kann man so auch
konfigurieren. Selbst gemacht, die Queue dann aber manuell geprüft.
>> Und dann gibt es noch die Leute, die Hamster tatsächlich als MX
>> einsetzen wollen. Nicht besonders sinnvoll IMO, aber was will man tun?
>
> Naja ist das denn ein Problem? Kann man ihn nicht so konfigurieren, dass
> er als MX korrekt seinen Dienst tut?
Klar kann man. Geht jeder beliebige Texteditor, das Tool zum lesbaren
Umwandeln der Konfiguration ist ebenfalls kostenlos. Es heißt Delphi.
Hamster ist nicht dafür konzipiert. Die Grundannahme ist, daß Mails per
SMTP nur von absolut vertrauenswürdigen Stationen kommen. Und es wird
einiges dafür getan, daß andere Stationen keinerlei Zugriff haben.
Beim Einsatz als MX stimmt schon diese Annahme nicht mehr. Hamster nimmt
die Mail auf jeden Fall erst einmal an, und das war es dann auch. Das
will man nicht als MX machen, auch wenn einige das versuchen.
Es ist und bleibt Blödsinn, genauso wie IMO der MX-Betrieb an einer
wechselnden Adresse.
Felix M. Palmen
* Wilfried Kramer <selten....@arcor.de>:
> Dein Problem ist aber doch ein anderes. Auch wenn Du das nicht als
> Problem sehen willst.
/Ich/ habe kein Problem.
> Wieviele MX laufen an DynDNS rum, und nehmen einfach alles ohne
> Weiterleitung an?
Offenbar nicht genug, um mir bisher Probleme zu bereiten.
> Hamster kann man so auch
> konfigurieren. Selbst gemacht, die Queue dann aber manuell geprüft.
Darf ich mal fragen, warum? Also was genau du damit bezweckst hast?
> Hamster ist nicht dafür konzipiert. Die Grundannahme ist, daß Mails per
> SMTP nur von absolut vertrauenswürdigen Stationen kommen. Und es wird
> einiges dafür getan, daß andere Stationen keinerlei Zugriff haben.
Na ist doch wunderbar. Also hat man bei Hamstern in der
Default-Konfiguration kein dämliches Verhalten zu erwarten. Mehr wollte
ich ja auch gar nicht wissen :)
Wilfried Kramer
> * Wilfried Kramer <selten....@arcor.de>:
>> Dein Problem ist aber doch ein anderes. Auch wenn Du das nicht als
>> Problem sehen willst.
>
> /Ich/ habe kein Problem.
Du hattest Dir Sorgen gemacht, über zuviele freilaufende Hamster. Weil
Du erwartet hast, daß Dir das ein Problem bereiten könnte.
>> Hamster kann man so auch
>> konfigurieren. Selbst gemacht, die Queue dann aber manuell geprüft.
>
> Darf ich mal fragen, warum? Also was genau du damit bezweckst hast?
Vor allem reine Neugier.
Zunächst war die Adresse nirgends publiziert. Trotzdem wurde der Port 25
gefunden, und es kamen ein paar Relaytests aus Taiwan an. Nein, nicht
vom Betreiber einer Blacklist. Das lies sich leicht durch manuelles
Weiterleiten des Tests verifizieren.
Der Hamster war eine Spezialversion, konfiguriert als Teergrube. Brachte
auch nichts. Und ist wieder abgeschaltet.
Wilfried
--
[2] Wer Fehler abonniert, bekommt sie auch geliefert - Feature! <eg>
[-jh- in hdn]
Wolfgang Jäth
> > Bitte informiere Dich erst mal über das, wovon Du redest, bevor Du
> > Schwachsinn produzierst.
>
> Vielleicht solltest du erst mal den Thread lesen,
Habe ich; sonst hätte ich Dir noch ganz anders geantwortet.
> Ich kenne Hamster nicht
/Sagte/ ich doch: Informiere Dich bitte erst mal über das, wovon Du
redest ...
Wolfgang
--
Felix M. Palmen
* Wolfgang Jäth <jawo.us...@goldmail.de>:
> /Sagte/ ich doch: Informiere Dich bitte erst mal über das, wovon Du
> redest ...
Warum sollte ich? Wenn jemand /anders/ Blödsinn über Hamster behauptet
und ich das nicht glaube kann ich ja wohl hier nach Bestätigung/Dementi
fragen. Hat ja auch funktioniert.