Hamster als STMP Eingangsserver
Günter
Nun ist es aber so, daß Hamster nun auch RelayServer ist.
ein Test mit telnet to relay-test.mail-abuse.org belegt dies.
Wie kann man nun die Realymöglichkeit auf einem bestimmten IP -
Adressbereich festlegen, und wo kann ich festlegen, daß nur emails an eine
definierte Domäne (z.B. test.at) angenommen werden?
SMTP - Auth ist nicht möglich, da ich sonst keine eMails zugestellt bekomme!
Günter
Heiko Studt
> Ich betreibe Hamster .160 auf einer ofiziellen fixen IP Adresse.
ok.
> Nun ist es aber so, daß Hamster nun auch RelayServer ist.
> ein Test mit telnet to relay-test.mail-abuse.org belegt dies.
Bitte informiere dich demnächst *vorher* auf mögliche Sicherheitsrisiken etc
pp.
> Wie kann man nun die Realymöglichkeit auf einem bestimmten IP -
> Adressbereich festlegen, und wo kann ich festlegen, daß nur emails an eine
Schaue dir IP-Access in der Hilfe an.
> definierte Domäne (z.B. test.at) angenommen werden?
> SMTP - Auth ist nicht möglich, da ich sonst keine eMails zugestellt bekomme!
Schaue in die Aenderungen.txt außerdem hilft Google über die Gruppen weiter.
Ich lese einmal vor.
Hamster.ini: [Setup]
; Bounce senden, wenn Mails für unbekannte User am lokalen
; SMTP-Server eintreffen.
local.mail.BounceIfUnknownUser=0
; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
local.mail.reqnotauth=0
MFG, HTH
--
Heiko Studt
Joern Weber
"Günter" <g...@aon.at> schrieb/wrote:
> Ich betreibe Hamster .160 auf einer ofiziellen fixen IP Adresse.
> Nun ist es aber so, daß Hamster nun auch RelayServer ist.
Wenn er falsch konfiguriert wird, kann das passieren.
> Wie kann man nun die Realymöglichkeit auf einem bestimmten IP -
> Adressbereich festlegen,
Das ist im Hamster nicht möglich, er kann nur das relaying auf
authentifizierte User beschränken. Eine Beschränkung des relaying auf
IP-Quell-Adressen ist sinnfrei, da man diese auch fälschen kann.
> und wo kann ich festlegen, daß nur emails an eine
> definierte Domäne (z.B. test.at) angenommen werden?
In Setup des lokalen SMTP-Servers
> SMTP - Auth ist nicht möglich, da ich sonst keine eMails zugestellt bekomme!
Falsch. Du kannst SMTP-Auth verwenden und gleichzeitig eine
Ausnahmereglung für im Setup festgelegten lokalen Domains treffen.
Was ist zu tun:
0. Update auf Version .161 (Die .161 ist am lokalen Server gegen
DoS-Angriffen anfällig, wenn man dessen Bug kennt.)
1. In IPAccess.hst den SMTP-Server für alle IP Adressen öffnen
2. Im Menü "Lokale Domains" deine lokalen Domains festlegen
3. Im Menü "Lokale Server"->"SMTP-Server" SMTP-Auth aktivieren
und die Ausnahme für die unauthorisierte Zustellung an
lokale User aktivieren
4. SMTP-Auth kennt verschiedene Auth-Mechanismen. Wenn es die
Reader deiner lokalen Nutzer zulassen nur CRAM-MD5 oder CRAM-SHA1
verwenden. Die zulässigen Auth-Mechanismen kannst im Setup des
lokalen SMTP-Server einstellen. Aber Vorsicht OE und Mozilla
beherrschen nicht die sicheren Auth-Mechanismen.
5. Den Bouncer für den lokalen SMTP-Server in der Hamster.ini
aktivieren mit.
[Setup]
local.mail.BounceIfUnknownUser=1
6. Als doppelten Boden empfehle ich noch dein HamSendmail-Script
so zu gestalten, das nur Mails an den Smarthost gesendet werden
welche im Envelope eine lokale Domain im Domainpart besitzen.
Alle anderen Mails solltest Du per Script in ein Kontroll-
Verzeichnis verschieben. Aber Vorsicht, dann können deine lokalen
User nur die festgelegten lokalen Domains als Absender-Adresse
verwenden.
7. Konzept für regelmässige Kontrolle des Hamster erstellen und
umsetzen.(separater Postmaster-Account,Logging usw.)
btw. Es ist auch ein Konzept mir zwei separaten Hamstern auf einem
Rechner machbar. Ein Hamster für die externe Maileinlieferung
ohne SMTP-Auth mit lokalen POP3 Server, aber ohne HamSendmail
und einem zweiten Hamster mit SMTP-Auth und ausschliesslicher
Bindung des lokalen SMTP-Server an das Netzwerkinterface
des Intranet und verwendung von HamSendmail. Bei diesem
Konzept ist dann aber eine Sonderbehandlung der hausinternen
Mails erforderlich. Diese müssen dann via Envelope-RCPt-TO:
Selection im HamsendMail-Befehl dann beim ersten öffentlichen
Hamster eingeliefert werden.
btw. Der Betrieb eines öffentlichen Mail-Servers sollte immer ein
Konzept vorgehen, das alle Sicherheitsaspecte berücksichtigt.
Gruss Joern Weber
--
em...@joernweber.de
Günter Wukoutz
Das Ganze ist ja schön und gut, aber trifft die Sache nicht ganz!
Nochmals um Misverständnisse zu vermeiden. Die eMails werden vom Provider
zugestellet! SMTP - SMTP Verbindung und NICHT über ein/mehrere POP3 Konten.
Es muß für den öffentlichen Betrieb folgendes möglich sein:
* Defnitition mehrere Domänen (hausbau.de, hausbau.com, hausbau.info, ...)
* Relaying von eMails aus einem definierten Adressbereich (192.168.1.0 -
192.168.1.255, 10.0.0.1 - 10.0.0.40, ...) ohne/mit Auth.
mittels Telnet mail.hausbau.de 25 sieht das ganze dann so aus (von externer
Adresse)
helo beliebigertext
OK
mail from:te...@test.com
OK
rcpt to:bi...@microsoft.com
relaying denied <<< der eMailserver nimmt NUR eMails
mit der eigenen Domäne an!
helo beliebigertext
OK
mail from:te...@test.com
OK
rcpt to:bi...@hausbau.de
OK <<< der eMailserver nimmt NUR
eMails mit der eigenen Domäne an!
DATA
.
QUIT
mittels Telnet localhost 25 sieht das ganze dann so aus (von internet
Adresse)
helo beliebigertext
OK
mail from:te...@test.com
OK
rcpt to:bi...@microsoft.com
OK <<< hier ist es egal, da Relaying aus
diesem Adressbereich erlaubt ist
Ansonsten ist es leider nicht möglich HAMSTER als offiziellen eMailserver zu
betreiben!
Viele Provider gehen dazu über ANTI Relaying vorzuschreiben!
Günter
Heiko Studt
> Es muß für den öffentlichen Betrieb folgendes möglich sein:
> * Defnitition mehrere Domänen (hausbau.de, hausbau.com, hausbau.info, ...)
AFAIR geht das, will ich aber jett auch nicht beschwören.
> * Relaying von eMails aus einem definierten Adressbereich (192.168.1.0 -
> 192.168.1.255, 10.0.0.1 - 10.0.0.40, ...) ohne/mit Auth.
Why?
> rcpt to:bi...@microsoft.com
> OK <<< hier ist es egal, da Relaying aus
> diesem Adressbereich erlaubt ist
Du hast nicht wirklich gelesen?! Noch einmal zum mitmeißeln:
[Hamster.ini: Setup]
; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
local.mail.reqnotauth=0
dies muß "1" sein, SMTP-AUTH muß "1" sein.
Jetzt kann Hamster "seine" Domains empfangen, bei anderen Domains gibt es
eine Fehlermeldung, sofern kein SMTP-AUTH durchgeführt wurde.
Das Hamster grundsätzlich nur von IP-Adressen 10.x.y.z angesprochen werden
kann und sonst *gar nicht* reagiert (bei der Verbindung gibt's "Permission
Denied") kannst du in der IP-Access einstellen.
Achtung: IP-Spoofing umgeht diese Sicherungsstufe.
BTW: Hamster wird schon von mehreren als 'offizieller' SMTP-Server benutzt.
MFG
--
Heiko Studt
Günter Wukoutz
Ich glaube ich bins nicht - weil:
> [Hamster.ini: Setup]
> ; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
> ; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
> local.mail.reqnotauth=0
>
>
> dies muß "1" sein, SMTP-AUTH muß "1" sein.
> Jetzt kann Hamster "seine" Domains empfangen, bei anderen Domains gibt es
> eine Fehlermeldung, sofern kein SMTP-AUTH durchgeführt wurde.
Du meinst also ernsthaft, daß sich ein anderer SMTP Server bei meinem Authentifizieren muß? Wie soll das denn gehen? Denn innerhalb der SMTP - SMTP Komunikation wird ja zuerst vom Sendenden STMP Server der MX - Record der jeweiligen DNS - Zone (=Domäne) abgefragt. Die hier einghtragene IP-Adresse ist somit jene IP Adresse des dafür zuständigen eMailservers! Somit meiner. Und wie soll nun z.B. der T-Online Server das Kennwort meines eMailserver kennen? Geht nicht - logisch oder?
Hier kommt nun das ANTI - Relaying ins Spiel. Der Server darf zum einen nur eMails an seine eigene Domäne (FQDN) annehmen. Im Programmcode habe ich nichts gefunden! Die Meldung: 550 Relaying denied ist nicht enthalten!
Das hat nichts mit IP - Adressen und Berechtigungen zu tun.
In meinem Posting habe ich beschieben wie man es testen kann.
Ich habe jedoch mittlerweile die Unit cServerSMTP.pas soweit modifiziert, daß dies nun verhindert werden kann! Wem muß ich diese Unit nun schicken, damit dies in die nächste Release aufgenommen wird?
> Das Hamster grundsätzlich nur von IP-Adressen 10.x.y.z angesprochen werden
> kann und sonst *gar nicht* reagiert (bei der Verbindung gibt's "Permission
> Denied") kannst du in der IP-Access einstellen.
> Achtung: IP-Spoofing umgeht diese Sicherungsstufe.
Ist klar.
Heiko Studt
> > ; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
> > ; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^
> > local.mail.reqnotauth=0
> > Jetzt kann Hamster "seine" Domains empfangen, bei anderen Domains gibt es
^^^^^^^^^^^^^^^^^^^^^^^^^^
> > eine Fehlermeldung, sofern kein SMTP-AUTH durchgeführt wurde.
> Du meinst also ernsthaft, daß sich ein anderer SMTP Server bei meinem Authentifizieren muß? Wie soll das denn gehen? Denn innerhalb der SMTP - SMTP Komunikation wird ja zuerst vom Sendenden STMP Server der MX - Record der jeweiligen DNS - Zone (=Domäne) abgefragt. Die hier einghtragene IP-Adresse ist somit jene IP Adresse des dafür zuständigen eMailservers! Somit meiner. Und wie soll nun z.B. der T-Online Server das Kennwort meines eMailserver kennen? Geht nicht -
logisch oder?
Glaube mir einbfach: Ich kenne das MX-Prinzip.
Wenn du das obrige unterstrichene immer noch nicht verstehst, dann schaue
bitte im Source nach: Wenn local.mail.reqnotauth gesetzt und SMTP-AUTH
gesetzt ist, dann *kann* T-Online und auch irgentwer an Empfänger *deiner
Domaine* schreiben. *Wenn* er aber deinen Server *zum relaying* benutzen will
muß er SMTP-AUTH benutzen.
> Hier kommt nun das ANTI - Relaying ins Spiel. Der Server darf zum einen nur eMails an seine eigene Domäne (FQDN) annehmen.
In diesem Falle weiß ich nicht auswendig ob der FQDN oder ein seperates Feld
benutzt wird und ehrlich gesagt habe ich auch keine Lust jetzt nachzuschauen.
> Im Programmcode habe ich nichts gefunden! Die Meldung: 550 Relaying denied ist nicht enthalten!
Bitte schaue dir den RFC nochmals an!
Allein die Zahl '550' ist wichtig, der Text ist vollkommen beliebig und
könnte in Suaheli sein -- sofern es in 7Bit Zeichen darstellbar ist.
Wie er genau im Hamster-Source heißt kann ich dir aus dem Stand nicht sagen.
> Das hat nichts mit IP - Adressen und Berechtigungen zu tun.
Mit IP-Adressen hat es nicht wirklich etwas zu tun, aber das war ja deine
*2.* Frage, die ich seperat geantwortet habe.
> Ich habe jedoch mittlerweile die Unit cServerSMTP.pas soweit modifiziert, daß dies nun verhindert werden kann! Wem muß ich diese Unit nun schicken, damit dies in die nächste Release aufgenommen wird?
hamster...@yahoogroups.com (Anmeldung erforderlich!)
Oder einem der anderen Programmierer um es weiterzuleiten.
Aber wie bereits gesagt: Den Code gibt es schon! Seit AFAIR 23.150 kann durch
obrigen ini-Schalter genau das gewünschte erreicht werden.
Falls du detailierte Fragen hast solltest du dich in diesem Falle an Joern
wenden, welcher AFAIR die Erweiterung geschrieben hatte.
MFG
--
Heiko Studt
Günter Wukoutz
OK
> Wenn du das obrige unterstrichene immer noch nicht verstehst, dann schaue
> bitte im Source nach: Wenn local.mail.reqnotauth gesetzt und SMTP-AUTH
> gesetzt ist, dann *kann* T-Online und auch irgentwer an Empfänger *deiner
> Domaine* schreiben. *Wenn* er aber deinen Server *zum relaying* benutzen will
> muß er SMTP-AUTH benutzen.
Wenn SMTP Auth gesetzt ist, dann muß sich jeder SMTP Client Authentifizieren!
Wenn man die lokalen IP Adressen ausnimmt, dann gilt das für das LAN. Was ja auch so sein soll.
> Bitte schaue dir den RFC nochmals an!
> Allein die Zahl '550' ist wichtig, der Text ist vollkommen beliebig und
> könnte in Suaheli sein -- sofern es in 7Bit Zeichen darstellbar ist.
> Wie er genau im Hamster-Source heißt kann ich dir aus dem Stand nicht sagen.
>
> > Das hat nichts mit IP - Adressen und Berechtigungen zu tun.
Auch richtig. Aber "550" ist trotzdem nicht enthalten. Vieleicht verweselst Du das mit 500 (Permision denied).
> Aber wie bereits gesagt: Den Code gibt es schon! Seit AFAIR 23.150 kann durch
> obrigen ini-Schalter genau das gewünschte erreicht werden.
Anbei der wichtige Code Teil:
Function AddressContainsLocalDomain(Const FullAddress: string): boolean;
var i: integer; Addr, Domain: string;
begin
Result := false;
// strip brackes <>
Addr := FilterEmailOfFrom(FullAddress);
// decleare emty adress as non local
if Addr > '' then
begin
i := RScan ( '@', Addr );
// check if old style local address using
if i = 0 then
begin
Result := True
end
else
begin
// extract domain part
Domain := copy(Addr, i+1, Length(Addr)-i );
// check for bad domains
Result := (Domain > '') // Domain exists
and (Pos( '.', Domain )>0) // is valid
and ((Length(Domain)<8)
or (copy(Domain,length(Domain)-7,8)<>'.invalid')) // .*\.invalid
and IsLocalDomain ( Domain )
end
end
end;
Dieser Code überprüft lediglich ob in der Ziel Domäne (vom Sender aus gesehen) ein @ und ein . enthalten ist.
Der Teil vor dem @ wird entfernt. Dann bleibt eine gültige Domäne übrig.
Hier die Überprüfung:
If not (AuthOK or (Def_LocalMailReqNotAuth and AddressContainsLocalDomain(s))) then begin
SendResult( '500 Permission denied' );
exit;
end;
Leider testet der Code nicht, ob die Zieldomäne lokal angelegt ist.
> Falls du detailierte Fragen hast solltest du dich in diesem Falle an Joern
> wenden, welcher AFAIR die Erweiterung geschrieben hatte.
Hast Du eine eMail oder eine Homepage von Joern?
mfg
Günter
Heiko Studt
> > Wenn du das obrige unterstrichene immer noch nicht verstehst, dann schaue
> > bitte im Source nach: Wenn local.mail.reqnotauth gesetzt und SMTP-AUTH
> > gesetzt ist, dann *kann* T-Online und auch irgentwer an Empfänger *deiner
> > Domaine* schreiben. *Wenn* er aber deinen Server *zum relaying* benutzen will
> > muß er SMTP-AUTH benutzen.
> Wenn SMTP Auth gesetzt ist, dann muß sich jeder SMTP Client Authentifizieren!
Arg. Der ini-Schalter verhindert gerade dies für "lokale" Domains.
Vielleicht ist das Erkennen von "lokalen" Domains nicht buglos (;-)), aber
das sollte ggf. Joern etc klären, letzlich ist es aber die Intention des INI-
Schalters die genau das gewünschte machen soll.
> Auch richtig. Aber "550" ist trotzdem nicht enthalten.
> Vieleicht verweselst Du das mit 500 (Permision denied).
Letzlich ist es gleich welche 5xy-er Meldung er ausgibt, oder?
> Anbei der wichtige Code Teil:
[...]
Joern es sieht so aus als ob er Recht hat, kannst du das bitte überprüfen?
> > Falls du detailierte Fragen hast solltest du dich in diesem Falle an Joern
> > wenden, welcher AFAIR die Erweiterung geschrieben hatte.
> Hast Du eine eMail oder eine Homepage von Joern?
www.joernweber.de
Er liest hier normalerweise mit und per Copyif sollte er auch auf Buzzwords
reagieren...
BTW: Du scheinst Delphi zu kennen (;-)), wenn du Zeit&Lust hast ist deine
Hilfe sehr willkommen. Angeraten sei dir hamster...@yahoogroups.com um
Source-Änderungen mitzubekommen bzW eigene Änderungen zu senden.
MFG
--
Heiko Studt
Günter Wukoutz
> Vielleicht ist das Erkennen von "lokalen" Domains nicht buglos (;-)), aber
Niemand ist perfekt. 80% der Zeit des Programmierens besteht aus Fehlersuche. Ich spreche aus Erfahrung.
> das sollte ggf. Joern etc klären, letzlich ist es aber die Intention des INI-
> Schalters die genau das gewünschte machen soll.
>
> > Auch richtig. Aber "550" ist trotzdem nicht enthalten.
> > Vieleicht verweselst Du das mit 500 (Permision denied).
>
> Letzlich ist es gleich welche 5xy-er Meldung er ausgibt, oder?
Im Endeffekt ist der Text egal. Aber in der Funktionalität liegt eben der Unterschied. Bevor ich diesen Thread losgetreten habe, habe ich das natürlich getestet. Und bin draufgekommen das es leider nicht funktioniert wie es sollte - das Relaying.
> > Anbei der wichtige Code Teil:
> [...]
>
> Joern es sieht so aus als ob er Recht hat, kannst du das bitte überprüfen?
Sage ich doch.
> > > Falls du detailierte Fragen hast solltest du dich in diesem Falle an Joern
> > > wenden, welcher AFAIR die Erweiterung geschrieben hatte.
> > Hast Du eine eMail oder eine Homepage von Joern?
>
> www.joernweber.de
Danke
> Er liest hier normalerweise mit und per Copyif sollte er auch auf Buzzwords
> reagieren...
>
> BTW: Du scheinst Delphi zu kennen (;-)), wenn du Zeit&Lust hast ist deine
Bin seit TP5.0 dabei. Fast Tag und Nacht.
Mein jünstes Projekt: http://www.emailchess.at
> Hilfe sehr willkommen. Angeraten sei dir hamster...@yahoogroups.com um
> Source-Änderungen mitzubekommen bzW eigene Änderungen zu senden.
Habe mich angemeldet. Ich warte erstmal auf eine Reaktion von Joern.
Oder wohin kann ich meine Codeänderungen senden? Gibt es irgendwo einen Sourceserver? So wie CSV oder Sourceforge? Ich konnte auf den diversen HP´s leider nichts finden.
Günter
Heiko Studt
*g*
> > Letzlich ist es gleich welche 5xy-er Meldung er ausgibt, oder?
> Im Endeffekt ist der Text egal. Aber in der Funktionalität liegt eben der Unterschied. Bevor ich diesen Thread losgetreten habe, habe ich das natürlich getestet. Und bin draufgekommen das es leider nicht funktioniert wie es sollte - das Relaying.
Naja, ob er nun 500 oder 550 zurücksendet dürfte ein "SHOULD NOT" für das
auswerten sein. Aber ich habe jetzt nicht nachgelesen
> > BTW: Du scheinst Delphi zu kennen (;-)), wenn du Zeit&Lust hast ist deine
> Bin seit TP5.0 dabei. Fast Tag und Nacht.
Wow.
> Mein jünstes Projekt: http://www.emailchess.at
Gibt es bereits. Wenn auch vielleicht anders...
Wo genau kann ich aber nicht mehr sagen.
> > Hilfe sehr willkommen. Angeraten sei dir hamster...@yahoogroups.com um
> > Source-Änderungen mitzubekommen bzW eigene Änderungen zu senden.
> Habe mich angemeldet. Ich warte erstmal auf eine Reaktion von Joern.
> Oder wohin kann ich meine Codeänderungen senden?
Ebendorthin. (hamster-sourcen)
> Gibt es irgendwo einen Sourceserver? So wie CSV oder Sourceforge?
Nein.
In den Classic wird "manuell" der Source eingefügt.
> Ich konnte auf den diversen HP´s leider nichts finden.
Viel wurde dazu AFAIK auch nicht geschrieben.
MFG
--
Heiko Studt
Thomas G. Liesner
>> Hilfe sehr willkommen. Angeraten sei dir hamster...@yahoogroups.com um
>> Source-Änderungen mitzubekommen bzW eigene Änderungen zu senden.
> Habe mich angemeldet. Ich warte erstmal auf eine Reaktion von Joern.
Unnötig.
> Oder wohin kann ich meine Codeänderungen senden?
In die Mailingliste.
Optimal: Sprechendes Subject, (kurze) Erläuterung, was die folgenden
Änderungen bewirken sollen, der relevante Quellcode mit den markierten
Änderungen.
So long,
Thomas G. Liesner
PS: Die Mail damit beantwortet?
--
Hamster & Co, seit 20.5.2002 steht die Beta (!) 1.3.23.161 bereit
http://www.tglsoft.de bzw. http://home.arcor.de/tgl70/
(In .160 gab es mit dem Timeout diverser lokaler Server Probleme)
Günter Wukoutz
PS: Die Mail damit beantwortet?
Ja. Code wurde versendet.
Günter
Günter Wukoutz
Habe heute Probleme mich dazuanzumelden. Ich dachte es reicht einfach eine eMail an die Adresse. Yahoo will aber div. Infos von mir. Habe den Bestätigungscode noch nicht erhalten. Ich hoffe er kommt noch heute.
Günter
Joern Weber
"Günter Wukoutz" <g...@aon.at> schrieb/wrote:
> Das Ganze ist ja schön und gut, aber trifft die Sache nicht ganz!
Wieso?
> Nochmals um Misverständnisse zu vermeiden. Die eMails werden vom Provider
> zugestellet! SMTP - SMTP Verbindung und NICHT über ein/mehrere POP3 Konten.
Das habe ich schon verstanden.
> Es muß für den öffentlichen Betrieb folgendes möglich sein:
>
> * Defnitition mehrere Domänen (hausbau.de, hausbau.com, hausbau.info, ...)
Ok.
> * Relaying von eMails aus einem definierten Adressbereich (192.168.1.0 -
> 192.168.1.255, 10.0.0.1 - 10.0.0.40, ...) ohne/mit Auth.
Das ist nicht machbar und sinnreich. Nochmal zum mitmeisseln:
IP-Absenderadressen sind problemlos fälschbar.
> Ansonsten ist es leider nicht möglich HAMSTER als offiziellen eMailserver zu
> betreiben!
Das ist Unfug. Eine Einschränkung des Relays anhand der
Absender-IP-Adresse ist unsicher. Wenn Du dich über IP-Spoofing informiert
hast können wir über das Thema weiterreden.
> Viele Provider gehen dazu über ANTI Relaying vorzuschreiben!
Ja und? Dazu verwendet man andere Methoden. Einer dieser Methoden ist es
die öffentliche Zustellung von Mails nur an die eigene Domaine zu
erlauben, und Relaying nur mit SMTP-Auth zu gestatten.
Joern Weber
> Also einer von uns hat ein Brett vorm Kopf.
Ja, Du.
> Ich glaube ich bins nicht - weil:
>
>> [Hamster.ini: Setup]
>> ; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
>> ; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
>> local.mail.reqnotauth=0
>>
>>
>> dies muß "1" sein, SMTP-AUTH muß "1" sein.
>> Jetzt kann Hamster "seine" Domains empfangen, bei anderen Domains gibt es
>> eine Fehlermeldung, sofern kein SMTP-AUTH durchgeführt wurde.
>
> Du meinst also ernsthaft, daß sich ein anderer SMTP Server bei meinem Authentifizieren muß?
Nein, nur deine eigenen User müssen sich authentifizieren, da ihnen das
Relaying erlaubt ist. Alle anderen User müssen sich nicht
authentifizieren, ihnen ist aber dafür das Relaying verboten.
Joern Weber
Günter Wukoutz <g...@aon.at> schrieb/wrote:
> Ich habe jedoch mittlerweile die Unit cServerSMTP.pas soweit modifiziert,
> daß dies nun verhindert werden kann! Wem muß ich diese Unit nun schicken,
> damit dies in die nächste Release aufgenommen wird?
Poste es in die Sourcenmailing-Liste, dann können wir drüber diskutieren.
Relaying an IP-Adressen fest zu machen geht aber nur über meine Leiche,
sprich meiner weiteren Mitarbeit an dem Projekt.
Joern Weber
> and IsLocalDomain ( Domain )
> end
> end
> end;
>
> Dieser Code überprüft lediglich ob in der Ziel Domäne (vom Sender aus gesehen) ein @ und ein . enthalten ist.
> Der Teil vor dem @ wird entfernt. Dann bleibt eine gültige Domäne übrig.
IsLocalDomain testet ob die Domain lokal ist.
>
> Hier die Überprüfung:
>
> If not (AuthOK or (Def_LocalMailReqNotAuth and AddressContainsLocalDomain(s))) then begin
> SendResult( '500 Permission denied' );
> exit;
> end;
>
>
> Leider testet der Code nicht, ob die Zieldomäne lokal angelegt ist.
Falsch
>> Falls du detailierte Fragen hast solltest du dich in diesem Falle an Joern
>> wenden, welcher AFAIR die Erweiterung geschrieben hatte.
>
> Hast Du eine eMail oder eine Homepage von Joern?
Wenn Du ein Problem hast dann poste hier bitte ein konkretes Beispiel, das
man debuggen kann.
Joern Weber
> 'Cause Günter Wukoutz's words, I thought of...
>
>> Es muß für den öffentlichen Betrieb folgendes möglich sein:
>
>> * Defnitition mehrere Domänen (hausbau.de, hausbau.com, hausbau.info, ...)
>
> AFAIR geht das, will ich aber jett auch nicht beschwören.
Ja es funktioniert.
Günter Wukoutz
> Das ist Unfug. Eine Einschränkung des Relays anhand der
> Absender-IP-Adresse ist unsicher. Wenn Du dich über IP-Spoofing informiert
> hast können wir über das Thema weiterreden.
Ich weis was IP - Spoofing ist.
Dagegen gibts Firewalls und ausgebildete Admins.
>
> > Viele Provider gehen dazu über ANTI Relaying vorzuschreiben!
>
> Ja und? Dazu verwendet man andere Methoden. Einer dieser Methoden ist es
> die öffentliche Zustellung von Mails nur an die eigene Domaine zu
> erlauben, und Relaying nur mit SMTP-Auth zu gestatten.
SMTP Auth zwischen Mailserver?
Mal folgendes Beispiel:
Du registrierst die Domäne xyz.de und läßt diese von T-Online hosten.
Ebenfalls hast Du eine Stanleitung und somit auch eine fixe offizielle IP zB. 140.10.55.33.
Am DNS Server von T-Online wird ein MX-Record mit Deiner IP (140.10.55.33.) eingetragen.
Soweit alles klar?
Ich hoffe Dir ist der Sinn des MX-Records bewust - ich möchte nichts unterstellen!
Wenn ich nun eine eMail über meinen Provider (A-Online) versende, dann sieht der AOnline Server nach welchen MX-Eintrag die Domäne xzy.de hat. Dann wird eine Verbindung zwischen beiden Server aufgebaut.
UND DIESE IST GRUNDSÄTZLICH OHNE AUTHENTIFIZIERUNG!
Da fährt nunmal die Eisenbahn darüber.
Weiter:
Da dies im oberen Szenario nunmal Standard ist, stellt sich nun auch folgendes Problem:
Wie kann nun verhindert werden, daß mein Mailserver nur eMails an meine Domäne annimmt? Ansonsten verbinde ich mich mal kurz mit Deinem Hamster und versende mal 10000 eMails!
Es ist richtig wenn man die IP Berechtigung sperrt, dann gehts nicht. jedoch bekomme ich niemehr eMails!
Ebenso mit SMTP Aut. Dies ist eine zusätzliche Sicherheitsmaßnahme.
Sinnvoll aber nur auf Benutzerebene im LAN.
Hier ein Link, der das Relaying schön beschreibt:
http://www.msexchangefaq.de/internet/relaytest.htm
Teste doch mal mit telnet den Mailserver von fireball.de!
telnet relay.guj.de 25
220 relay1.guj.de ESMTP Sendmail 8.11.6/guj-zz-1.55; Sun, 26 May 2002 20:51:43 +
0200 (CEST)
250 relay1.guj.de Hello chello080109224053.3.klafu.surfer.at [80.109.224.53], pl
eased to meet you
500 5.5.1 Command unrecognized: "mailfrom"
mail from:te...@test.com
250 2.1.0 te...@test.com... Sender ok
rcpt to:g...@aon.at
550 5.7.1 g...@aon.at... Relaying denied
Ich hoffe ich habe nun das ganze ausführlichst dargelegt worum es beim Relaying geht.
Sollte ich eine Funktion im Hamster .161 übersehen haben, welche die gleiche Funktionalität bietet, dann bin ich für jede eMail dankbar.
Ansonsten kann der Hamster leiner nur über POP3 mit der Ausenwelt komunizieren. Und der Anwender darf für ein POP3 Sammelkonto den Provider bezahlen.
Günter,
MCSE
Joern Weber
Günter Wukoutz <g...@aon.at> schrieb/wrote:
> Grunsätzlich spreche ich vom Einsatz in einer KMU.
>
>> Das ist Unfug. Eine Einschränkung des Relays anhand der
>> Absender-IP-Adresse ist unsicher. Wenn Du dich über IP-Spoofing informiert
>> hast können wir über das Thema weiterreden.
>
> Ich weis was IP - Spoofing ist.
> Dagegen gibts Firewalls und ausgebildete Admins.
Nein, gegen gefälschte IP-Adressen helfen nicht in jeden Fall Paketfilter.
Das ist genau dann der Fall wenn im Intranet öffentliche IP-Adressen
eingesetzt werden. Firewalls sind im übrigen mehr ein Konzept als eine
Software.
> Da dies im oberen Szenario nunmal Standard ist, stellt sich nun auch folgendes Problem:
>
> Wie kann nun verhindert werden, daß mein Mailserver nur eMails an meine Domäne annimmt?
> Ansonsten verbinde ich mich mal kurz mit Deinem Hamster und versende mal 10000 eMails!
Das ist nicht möglich. An meinem Hamster können nur User "10000" Mails
versenden die sich vorher mit SMTP-Auth ausgewiesen haben. User die sich
nicht ausgewiesen haben dürfen nur an mich selber Mails einliefern und
bekommen andernfalls eine Bounce.
> Es ist richtig wenn man die IP Berechtigung sperrt, dann gehts nicht. jedoch bekomme
> ich niemehr eMails!
Falsch. Willst Du hier auf hohem Niveau trollen? IP-Absender-Adressen sind
fälschbar.
> Ich hoffe ich habe nun das ganze ausführlichst dargelegt worum es beim Relaying geht.
>
> Sollte ich eine Funktion im Hamster .161 übersehen haben, welche die gleiche Funktionalität
> bietet, dann bin ich für jede eMail dankbar.
Nö, das diskutieren wir hier. Du hast immer noch nicht begriffen, das man
einen SMTP-Server sowohl mit und ohne SMTP-Auth gleichzeitig betreiben
kann. Ist der User per SMTP-Auth am lokalen SMTP-Server authentifiziert,
darf er Mails an alle Welt einliefern, ist er nicht authentifiziert darf
er nur Mails an lokale Empfänger einliefern und kann somit nicht relayen.
Dieses Verhalten wird erreicht, wenn man im Menü für den lokalen Server
SMTP-Auth aktiviert, aber eine Ausnahme für die ausschliesslich lokale
Mailzustellung von nicht authentifizierten Usern zulässt.
> MCSE
Argl, da muss man sich wirklich nicht über die Vorurteile wundern. Lasse
Dir das Geld wiedergeben, das Du dafür aufgewendet hast. Deine Lehrer
wahren unfähig dir die Funktionsweise einer sicheren Relay-Sperre bei zu
bringen. Da sieht man wieder die Qualität solcher scheine.
Thomas G. Liesner
> Relaying an IP-Adressen fest zu machen geht aber nur über meine Leiche,
> sprich meiner weiteren Mitarbeit an dem Projekt.
Müssen gleich solche Drohungen sein? Es reicht, die Probleme/Nachteile
vorgeschlagener Änderungen verständlich zu machen, Entscheidungen für
oder gegen treffe ich bei kritischen Sachen normalerweise nicht einfach
so.
Im konkreten Fall sehe ich es so, daß Günter die aktuelle Technik noch
nicht wirklich verstanden hat. Ob eine _Ergänzung_ über die IP-Erkennung
nützlich/suboptimal/schädlich ist, kann ich noch nicht 100%ig
beurteilen, einen Abbau der momentanen Sicherungen, den du in der
Mailinglist festgestellt hast (ich selber habe mir den vorgeschlagenen
Code noch nicht angeguckt), halte ich auf jeden Fall für falsch.
So long,
Thomas G. Liesner
Günter Wukoutz
> Das ist genau dann der Fall wenn im Intranet öffentliche IP-Adressen
> eingesetzt werden. Firewalls sind im übrigen mehr ein Konzept als eine
> Software.
Ich weis. Ich spreche von Watchguard Firebox, Checkpoint 1 usw.
> > Da dies im oberen Szenario nunmal Standard ist, stellt sich nun auch folgendes Problem:
> >
> > Wie kann nun verhindert werden, daß mein Mailserver nur eMails an meine Domäne annimmt?
> > Ansonsten verbinde ich mich mal kurz mit Deinem Hamster und versende mal 10000 eMails!
>
> Das ist nicht möglich. An meinem Hamster können nur User "10000" Mails
> versenden die sich vorher mit SMTP-Auth ausgewiesen haben. User die sich
> nicht ausgewiesen haben dürfen nur an mich selber Mails einliefern und
> bekommen andernfalls eine Bounce.
10000 war nur eine Zahl. Dann eben entsprechend weniger.
> > Es ist richtig wenn man die IP Berechtigung sperrt, dann gehts nicht. jedoch bekomme
> > ich niemehr eMails!
>
> Falsch. Willst Du hier auf hohem Niveau trollen? IP-Absender-Adressen sind
> fälschbar.
Dieser Tatsache muß sich jeder eMailserver stellen. Siehe Thema Firewall.
>
> > Ich hoffe ich habe nun das ganze ausführlichst dargelegt worum es beim Relaying geht.
> >
> > Sollte ich eine Funktion im Hamster .161 übersehen haben, welche die gleiche Funktionalität
> > bietet, dann bin ich für jede eMail dankbar.
>
> Nö, das diskutieren wir hier. Du hast immer noch nicht begriffen, das man
> einen SMTP-Server sowohl mit und ohne SMTP-Auth gleichzeitig betreiben
> kann. Ist der User per SMTP-Auth am lokalen SMTP-Server authentifiziert,
> darf er Mails an alle Welt einliefern, ist er nicht authentifiziert darf
> er nur Mails an lokale Empfänger einliefern und kann somit nicht relayen.
> Dieses Verhalten wird erreicht, wenn man im Menü für den lokalen Server
> SMTP-Auth aktiviert, aber eine Ausnahme für die ausschliesslich lokale
> Mailzustellung von nicht authentifizierten Usern zulässt.
Es geht NICHT um den lokalen User! Sondern um den externen!
> Argl, da muss man sich wirklich nicht über die Vorurteile wundern. Lasse
> Dir das Geld wiedergeben, das Du dafür aufgewendet hast. Deine Lehrer
> wahren unfähig dir die Funktionsweise einer sicheren Relay-Sperre bei zu
> bringen. Da sieht man wieder die Qualität solcher scheine.
Bleib mal auf dem Teppich. Ich wollte damin untersteichen, daß ich was von der Materie verstehe. Im übrigen muß jeder mal einen Fehler eingestehen können.
Ich habe entdeckt, daß gewisse Erweiterungen unnötig waren jedoch der Check auf die lokale Domäne hat einen Bug. Ein Test mit telnet relay-test.mail-abuse.org wird es Dir selbst beweisen!
Teste doch das mal und poste mir das Ergebnis.
Günter
Axel Werner
Weber":
Ihr redet andauern aneinander vorbei! Und anstatt Mr OberSnob Weber mal sich
von seinem Hohen "Ich bin Softwareentwickler, also fallt vor mir in den
Schmutz" Ross herunterbegiebt ist er kein deut besser und Flamed hier eine
genauso große scheisse daher wie schon vor einem Jahr als das ähnliche thema
schonmal aufkam, das der Hamster ein Grundsätzliches Problem mit
MAIL-RELAYING hat. Aber damals waren auch alle "SuperEntwickler" wie Hr
Weber der Meinung "Der Hamster hat kein Problem mit Relaying...denn er
verschickt nicht automatisch Mails ins Internet" (Zitat) - 1. War das schon
immer BULLSHIT und 2. Komisch das vor einiger Zeit in irgend einer der
letzten Beta Versionen eine solche ANTI-RELAYING Funktion eingebaut wurde.
Wozu nur ?! Der Hamster hat doch gar kein Mail-Relaying problem!!!
Vorschlag: Mal mit ihren Vorlauten und frechen bemerkungen langsam treten
und immer hübsch sachlich bleiben Hr Weber. Dann ecken Sie auch nicht
andauernd irgendwo an.
Nun zu Hr. MCSE Wukoutz. Der Hr Weber versucht schon seit einiger Zeit dir
folgendes zu sagen:
1. Es stimmt! Zwischen Standard-Mailservern im Internet findet kein SMTP
Auth statt! Wenn wir SMTP Auth am Hamster einschalten werden zunächst KEINE
Externen Mails mehr per SMTP eingehen können (ausgenommen jemand würde mit
SMTP AUTH arbeiten, unwarscheinlich! bis auf die lokalen clients)
2. Es mag auch stimmen das man durch bestimmte IP Filter und evtl. manchen
FW Anwendungen (Appl proxies, SMTP) das IP Spoofing unterbinden kann. Soll
aber nun mal hier gar nicht das Thema sein.
3. die lokalen bzw auch die mobilen clients im internet können aber
grundsätzlich SMTP AUTH machen um ggf ihre geschriebenen MAils über den
eignen Server abzusetzen. (Dazu brauch ich das SMTP AUTH im Hamster noch
nicht mal einschalten glaube ich.) - Das lassen wir nun erst mal so im Raum
stehen,auch wenns jezt noch keinen Sinn macht das die Clients SMTH AUTH
machen sollen.
4. Da der Hamster nun zunächst immernoch MAIL-RELAY ist und wir das
unterbinden müssen schalten wir kurzer hand einfach mal das "BENÖTIGT SMTP
AUTH ZUM SENDEN" ein!! NUN is erst mal ruhe von aussen! Nur noch diejenigen
die sich per SMTP AUTH authentifizieren können, können noch Mails über den
Hamster absetzen. Mails von "fremden" z.b. andere Mailserver aus dem
Internet werden nun nicht mehr angenommen. (ist noch nicht unter ziel, wir
sind dem aber ein stück näher gekommen)
5. Nun stellen wir im Hamster selbst (über das GUI) noch ein für welche
versch. Domains bzw eMail ggf Adressen der Hamster "zuständig" sein soll bzw
welche er "annehmen darf". Diesen Punkt finden wir unter: EINSTELLUNGEN /
LOKALE SERVER / LOKALE DOMAINS / Lokale Mailauslieferung... Das war nun
wichtig für den nächsten Punkt
6. Diesmal nicht über GUI sondern über die Hamster.ini Datei stellen wir
folgenden Parameter ein:
; Bounce senden, wenn Mails für unbekannte User am lokalen
; SMTP-Server eintreffen.
local.mail.BounceIfUnknownUser=0
; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
local.mail.reqnotauth=1
Und schon sollte dein Problem gelöst sein! Denn speziell der letzte
Parameter "local.mail.reqnotauth=1" soll nun bewirken das TROTZ
eingeschaltetem "BENÖTIGE SMTP AUTH" wieder Leute UND andere Mailserver von
Aussen (und innen) Mails per SMTP jedoch OHNE Authentifizierung zustellen
können, WENN und nur dann ohne Auth., WENN der Empfänger der eingehenden
EMail einer der vorhin eingestellten "lokalen Domains" oder Adressen ist.
Und das können natürlich auch mehrere versch. Domains sein! ALSO... Der
Hamster nimmt ab sofort wieder OHNE SMTP AUTH Mails aus dem Internet
entgegen! Aber eben nur dann wenn sie auch für diesen Server bestimmt sind.
Ansonsten werden sie abgeblockt. Was ist nun mit den lokalen oder mobilen
USern des Servers los?
Die Mail-User die Mails über den Hamster ins Internet schicken wollen MÜSSEN
sich nun jedoch zwingent per SMTP AUTH authentifizieren!!! Denn in Ihren
Mails stehen vermutlich meistens "fremde empfänger Domänen" die also NICHT
Lokal sind. Somit MÜSSEN Sie SMTP AUTH am Hamster machen damit dieser die
Mails überhaupt entgegen nimmt und dann auch weiterleiten kann.
Was wir nun haben ist also ein Mailserver der von Aussen sowie von Innen
Mails per SMTP (OHNE Authentifizierung) annimmt sofern er für die Domains
der Empfängeradresse in der eMail "zuständig" gemacht wurde. Dies können 1.
andere Mailserver oder 2. irgend welche Mail-Clients sein. Die User des
lokalen Hamster-Servers welche jedoch eine Mail an eine "fremde" Domain
senden wollen MÜSSEN sich per SMTP AUTH authentifizieren da der Server sonst
ihre Mails nicht entgegen nimmt. d.h. unser Hamster ist gegen Spamming bzw
Mail-Relaying von "Fremden" abgesichert worden.
Hoffe das das Thema nun abgehandelt ist und es nun klar wurde was Hr Weber
die ganze Zeit so "Programmierer Typisch" sagen wollte.
>>Ich weis was IP - Spoofing ist. Dagegen gibts Firewalls und ausgebildete
Admins.
>>Günter,MCSE
Das Spielchen kann ich auch spielen...
In diesem Sinne...
MfG
Axel
CNE, IBM PSS, AVM ICP, Linux FK
System- & Network Engineer
Wolfgang Jaeth
Joern Weber schrieb in Nachricht
<67db98925803fe26...@blechtrottel.joernweber.de>...
>
>Poste es in die Sourcenmailing-Liste, dann können wir drüber diskutieren.
Keine gute Idee. Die Sourcenliste sollte IMHO von Diskussionen möglichst
freigehalten werden; insbesonderen von Diskussionen, bei denen es mehr um
Prinzipien als um Sourcen selbst geht.
Wolfgang
--
Heiko Studt
> Hoffe das das Thema nun abgehandelt ist und es nun klar wurde was Hr Weber
> die ganze Zeit so "Programmierer Typisch" sagen wollte.
Bisher, auch wenn es langsam Ansätz gab, gab es keine Flames.
Außerdem hat sich die Sache wohl ein wenig klären können, denn Günter hat
einen berechtigten Bug-Report sehr umständlich formluiert. In der
Sourcenlistze hat sich das eigentliche Problem, welches ein Sicherheitsloch
im Hamster darstellt, gezeigt.
Wir haben wohl alle nur die flaschen Worte benutzt. :-/
BTW: 1. Im Usente wird normalerweise geduzt.
2. Du gehörst fast in ein Killfile, auch wenn du IMO berechtigten Ärger
über die Art der "Diskussion" hast. Bitte eine solchen Thread
demnächst auf Ignore stellen, anstatt jeden zu verurteilen.
BTW^2: Günter hatte, genau wie ich, einen wichtigen Teil des geposteten Codes
einfach übersehn ("IsLocalDomain"). Außerdem haben wir einen Bug eingebaut
durch Benutzung einer Funktion, die "zuviel" kann.
Fix ist in der Sourcenliste gepostet, ich werde jetzt eine 163-er Version
zusammenschustern, welche einstweilen von denjenigen benutzt werden kann,
welche Hamster als SMTP-Server benutzen.
http://www.goldpool.org/temp/Hamster163.zip
Enthalten:
-mnuHilfe-Fix
-SMTP-Relay-Fix
-Versionsupdate
MFG
--
Heiko Studt
Günter Wukoutz
> Auth statt! Wenn wir SMTP Auth am Hamster einschalten werden zunächst KEINE
> Externen Mails mehr per SMTP eingehen können (ausgenommen jemand würde mit
> SMTP AUTH arbeiten, unwarscheinlich! bis auf die lokalen clients)
Stimmt. Logisch
> 2. Es mag auch stimmen das man durch bestimmte IP Filter und evtl. manchen
> FW Anwendungen (Appl proxies, SMTP) das IP Spoofing unterbinden kann. Soll
> aber nun mal hier gar nicht das Thema sein.
Ist klar, Hier gehts ja um einen Mailserver und nicht um IP Spoofing. Das wäre ja Netzwerksicherheit.
> 3. die lokalen bzw auch die mobilen clients im internet können aber
> grundsätzlich SMTP AUTH machen um ggf ihre geschriebenen MAils über den
> eignen Server abzusetzen. (Dazu brauch ich das SMTP AUTH im Hamster noch
> nicht mal einschalten glaube ich.) - Das lassen wir nun erst mal so im Raum
> stehen,auch wenns jezt noch keinen Sinn macht das die Clients SMTH AUTH
> machen sollen.
Ganz meine Meinung
> 4. Da der Hamster nun zunächst immernoch MAIL-RELAY ist und wir das
> unterbinden müssen schalten wir kurzer hand einfach mal das "BENÖTIGT SMTP
> AUTH ZUM SENDEN" ein!! NUN is erst mal ruhe von aussen! Nur noch diejenigen
> die sich per SMTP AUTH authentifizieren können, können noch Mails über den
> Hamster absetzen. Mails von "fremden" z.b. andere Mailserver aus dem
> Internet werden nun nicht mehr angenommen. (ist noch nicht unter ziel, wir
> sind dem aber ein stück näher gekommen)
Grundsätzlich ja. Aber Hamster hat bis gestern ein Problem mit folgenden RCPT TO: Adressen gehabt: <"user...@domain.tld">
Diese SIND durchgekommen. Ein Test mit Telnet auf Abuse hat das bewiesen.
> 5. Nun stellen wir im Hamster selbst (über das GUI) noch ein für welche
> versch. Domains bzw eMail ggf Adressen der Hamster "zuständig" sein soll bzw
> welche er "annehmen darf". Diesen Punkt finden wir unter: EINSTELLUNGEN /
> LOKALE SERVER / LOKALE DOMAINS / Lokale Mailauslieferung... Das war nun
> wichtig für den nächsten Punkt
Aha. Das hätte mit schon am Samstag gesagt werden können. Ich war der Meinung das Feld FQDN ist dafür zuständig. Habe ich aber auch erwähnt. Keiner hatte was dagegen.
Vorschlag: In die Hilfe aufnehmen.
> 6. Diesmal nicht über GUI sondern über die Hamster.ini Datei stellen wir
> folgenden Parameter ein:
> ; Bounce senden, wenn Mails für unbekannte User am lokalen
> ; SMTP-Server eintreffen.
> local.mail.BounceIfUnknownUser=0
>
> ; Nicht autorisierte User am lokalen SMTP-Server trotz eingeschaltetem
> ; SMTP-Auth das einliefern von Mails für lokale Empfänger gestatten
> local.mail.reqnotauth=1
Interessant.
Des Pudels Kern. Eine Schaltfläche in der GUI ist hier von Vorteil. Sollte auch in der Hilfe aufscheinen.
> Und schon sollte dein Problem gelöst sein! Denn speziell der letzte
> Parameter "local.mail.reqnotauth=1" soll nun bewirken das TROTZ
> eingeschaltetem "BENÖTIGE SMTP AUTH" wieder Leute UND andere Mailserver von
> Aussen (und innen) Mails per SMTP jedoch OHNE Authentifizierung zustellen
> können, WENN und nur dann ohne Auth., WENN der Empfänger der eingehenden
> EMail einer der vorhin eingestellten "lokalen Domains" oder Adressen ist.
> Und das können natürlich auch mehrere versch. Domains sein! ALSO... Der
> Hamster nimmt ab sofort wieder OHNE SMTP AUTH Mails aus dem Internet
> entgegen! Aber eben nur dann wenn sie auch für diesen Server bestimmt sind.
> Ansonsten werden sie abgeblockt. Was ist nun mit den lokalen oder mobilen
> USern des Servers los?
So will ichs haben.
> Die Mail-User die Mails über den Hamster ins Internet schicken wollen MÜSSEN
> sich nun jedoch zwingent per SMTP AUTH authentifizieren!!! Denn in Ihren
> Mails stehen vermutlich meistens "fremde empfänger Domänen" die also NICHT
> Lokal sind. Somit MÜSSEN Sie SMTP AUTH am Hamster machen damit dieser die
> Mails überhaupt entgegen nimmt und dann auch weiterleiten kann.
Genau
> Was wir nun haben ist also ein Mailserver der von Aussen sowie von Innen
> Mails per SMTP (OHNE Authentifizierung) annimmt sofern er für die Domains
> der Empfängeradresse in der eMail "zuständig" gemacht wurde. Dies können 1.
> andere Mailserver oder 2. irgend welche Mail-Clients sein. Die User des
> lokalen Hamster-Servers welche jedoch eine Mail an eine "fremde" Domain
> senden wollen MÜSSEN sich per SMTP AUTH authentifizieren da der Server sonst
> ihre Mails nicht entgegen nimmt. d.h. unser Hamster ist gegen Spamming bzw
> Mail-Relaying von "Fremden" abgesichert worden.
>
> Hoffe das das Thema nun abgehandelt ist und es nun klar wurde was Hr Weber
> die ganze Zeit so "Programmierer Typisch" sagen wollte.
Obwohl ich seit 15 Jahren im Geschäft - auch als Programmierer - bin. Ich hab´s nicht verstanden.
Das sieht man wieder was eine "Anleitung" so alles bewirken kann.
Das Ganze hätten wir auch einfacher haben können.
> Das Spielchen kann ich auch spielen...
> In diesem Sinne...
> MfG
> Axel
> CNE, IBM PSS, AVM ICP, Linux FK
> System- & Network Engineer
Ach ja. PSS, PSE bin ich auch noch.
CCNA in Vorbereitung.
Ist eigendlich nicht mein Stil mit den Zertifizierungen um mich zu werfen. Hier war es mir aber ein Bedürfnis.
Günter Wukoutz
> einen berechtigten Bug-Report sehr umständlich formluiert. In der
> Sourcenlistze hat sich das eigentliche Problem, welches ein Sicherheitsloch
> im Hamster darstellt, gezeigt.
Na ja. Bis dahin kannte ich die "geheimen" Schalter nicht.
Also war mein Posting wohl berechtig - meine ich.
> Wir haben wohl alle nur die flaschen Worte benutzt. :-/
>
> BTW: 1. Im Usente wird normalerweise geduzt.
> 2. Du gehörst fast in ein Killfile, auch wenn du IMO berechtigten Ärger
> über die Art der "Diskussion" hast. Bitte eine solchen Thread
> demnächst auf Ignore stellen, anstatt jeden zu verurteilen.
Bin abgehärtet.
Jedoch sollte jeder für konstruktive Kritik offen sein. Ich für meinen Teil - so glaube ich - bin es. Jedoch muß sich jeder damit selbst auseinandersetzen.
> BTW^2: Günter hatte, genau wie ich, einen wichtigen Teil des geposteten Codes
> einfach übersehn ("IsLocalDomain"). Außerdem haben wir einen Bug eingebaut
> durch Benutzung einer Funktion, die "zuviel" kann.
> Fix ist in der Sourcenliste gepostet, ich werde jetzt eine 163-er Version
> zusammenschustern, welche einstweilen von denjenigen benutzt werden kann,
> welche Hamster als SMTP-Server benutzen.
Was mit noch immer nicht klar ist. Welches Feld in der GUI frägt "IsLocalDomain" ab. Ich hab´s erst später bemerkt, das es eigendlich eine Funktion ist.
> http://www.goldpool.org/temp/Hamster163.zip
> Enthalten:
> -mnuHilfe-Fix
> -SMTP-Relay-Fix
> -Versionsupdate
>
>
> MFG
>
> --
> Heiko Studt
Günter
Heiko Studt
> Ist klar, Hier gehts ja um einen Mailserver und nicht um IP Spoofing. Das wäre ja Netzwerksicherheit.
Ein Mailserver muß aber auch sicher konfigurierbar sein, ohne daß man gleich
ein Firewall-Konzept kreieren muß. Und Hamster ist gerade für den Sub-
Proffessionellen Bereich gedacht aka Home-Netzwerk/_kleine_ Firmennetzwerke.
Außerdem nützt dir ein total sicheres Netz nichts gegen einen _laufenden_
Server, welcher dir alles erlaubt.
> Grundsätzlich ja. Aber Hamster hat bis gestern ein Problem mit folgenden RCPT TO: Adressen gehabt: <"user...@domain.tld">
> Diese SIND durchgekommen. Ein Test mit Telnet auf Abuse hat das bewiesen.
Bis zur Mailingliste hast du das nicht erwähnt. Und daß PKR auf die Schnelle
die Lösung gefunden hat hätte auch niemand wissen können, stümmt's?
> > LOKALE SERVER / LOKALE DOMAINS / Lokale Mailauslieferung... Das war nun
> Vorschlag: In die Hilfe aufnehmen.
Äähm... <hüstel>
Der Punkt ist *mit Sicherheit* beschrieben...
> > local.mail.BounceIfUnknownUser=0
> > local.mail.reqnotauth=1
> Interessant.
???
Welche INI-Schalter predige ich schon die ganze Zeit?
> Des Pudels Kern. Eine Schaltfläche in der GUI ist hier von Vorteil.
In 1.3.23.160 ist dies der Fall.
> Sollte auch in der Hilfe aufscheinen.
In der BETA-Hilfe kannst du sie bekommen.
Bitte wundere dich nicht daß nicht alle Funktionen in der 1.3.23.4er-Hilfe
aus 1.3.23.160 beschrieben sind. Nein, die aktuelle Hilfe wird AFAIR bei den
BETAs nicht mitgeliefert...
Unter www.joernweber.de kannst du sie downloaden.
> > Hoffe das das Thema nun abgehandelt ist und es nun klar wurde was Hr Weber
> > die ganze Zeit so "Programmierer Typisch" sagen wollte.
> Obwohl ich seit 15 Jahren im Geschäft - auch als Programmierer - bin. Ich hab´s nicht verstanden.
> Das sieht man wieder was eine "Anleitung" so alles bewirken kann.
> Das Ganze hätten wir auch einfacher haben können.
Naja, ich hätte es so nicht verstanden, sondern eher wie Joern es erklärt
hatte... *g*
> Ist eigendlich nicht mein Stil mit den Zertifizierungen um mich zu werfen. Hier war es mir aber ein Bedürfnis.
Ich bin Vollberuflicher Schüler... ;-P
MFG
--
Heiko Studt
Heiko Studt
> Na ja. Bis dahin kannte ich die "geheimen" Schalter nicht.
Sorry, ich verstehe dich nicht.
Ich hatte ihn dir *zweimal* hier in der Gruppe vorgelesen.
Soll ich dir die MIDs besorgen? Ja, du hast geantwortet... :-P
> Also war mein Posting wohl berechtig - meine ich.
Nur daß es mehrmals nicht gesehen wurde, was du wirklich willst.
> > 2. Du gehörst fast in ein Killfile, auch wenn du IMO berechtigten Ärger
> Bin abgehärtet.
Das war *nicht* an dich gerichtet.
> Jedoch sollte jeder für konstruktive Kritik offen sein. Ich für meinen Teil - so glaube ich - bin es. Jedoch muß sich jeder damit selbst auseinandersetzen.
Es sieht so aus. :o)
BTW: *Bitte* schalte den Zeiulenumbruch ein oder setze ihn nach max 80
Zeichen manuell. Das lesen/antworten wird dann erheblich einfacher.
> Was mit noch immer nicht klar ist. Welches Feld in der GUI frägt "IsLocalDomain" ab.
k.A.
Du kannst doch Delphi...
> Ich hab´s erst später bemerkt, das es eigendlich eine Funktion ist.
Was doch eigentlich fast klar ist. IMO. ;-P
> > http://www.goldpool.org/temp/Hamster163.zip
Ich werde jetzt den "Announce" machen.
MFG
--
Heiko Studt
Axel Werner
"Heiko Studt" <Usene...@goldpool.org> schrieb im Newsbeitrag
news:actbo...@Heiko.Studt.dialin.t-online.de...
> Wir haben wohl alle nur die flaschen Worte benutzt. :-/
>
> BTW: 1. Im Usente wird normalerweise geduzt.
> 2. Du gehörst fast in ein Killfile, auch wenn du IMO berechtigten
Ärger
> über die Art der "Diskussion" hast. Bitte eine solchen Thread
> demnächst auf Ignore stellen, anstatt jeden zu verurteilen.
> Heiko Studt
Stimmt! Du hast recht! entschuldige mich gerne auch nochmal bei Allen
beteiligten, aber mir ging dieses zum Teil arogante Geschwätz auf den Sack!
After all siehts nun jedenfalls so aus das ich zum Teil doch damit helfen
konnte und zudem sogar ein sicherheitsloch gefixed wurde. Na also!
MfG
Axel
Axel Werner
"Günter Wukoutz" <g...@aon.at> schrieb im Newsbeitrag
news:w6pI8.122890$ze7.1...@news.chello.at...
~~~~~~~
Aha. Das hätte mit schon am Samstag gesagt werden können. Ich war der
Meinung das Feld FQDN ist dafür zuständig. Habe ich aber auch erwähnt.
Keiner hatte was dagegen.
Vorschlag: In die Hilfe aufnehmen.
~~~~~~~
Das stimmt! Diese Info wurde in dieser Form wohl unterschlagen. Er ging wohl
davon aus das man sich schon mit der alten Doku des Hamster
auseinandergesetzt hatte und einem dieses Feld bekannt ist. MAcht aber nix.
Jetz hammers ja gefunden :)
~~~~~~~
Interessant.
Des Pudels Kern. Eine Schaltfläche in der GUI ist hier von Vorteil. Sollte
auch in der Hilfe aufscheinen.
~~~~~~~
Ich denke das wird sofern es noch nicht drinn steht noch passieren. Hab erst
neulich irgendwo gelesen das die Help Files sowieso noch nicht ganz auf
Stand sind. Daher würde es mich nicht wundern. Ich hoffe aber das dies der
Fall ist wenn das neue Final released wird. Darauf freue ich mich schon
sehr! Und richtig freue ich mich erst wenn der HAmster bald auch
selbstständig eine direkten Mail-Forward vornehmen kann!!
~~~~~~~
Obwohl ich seit 15 Jahren im Geschäft - auch als Programmierer - bin. Ich
hab´s nicht verstanden.
Das sieht man wieder was eine "Anleitung" so alles bewirken kann.
Das Ganze hätten wir auch einfacher haben können.
~~~~~~~
Das stimmt allerdings!!! Deshalb sollte auch kein Vollblut-Programmierer
alleine versuchen eine User-Doku zu schreiben ;)
Besonderen Dank übrigens nochmals an Volker G. und seinen Hamster-Seiten!
Die sind wirklich eine EXCELENTE Einstiegs-Doku für den Hamster!!!
~~~~~~~
> Das Spielchen kann ich auch spielen...
> In diesem Sinne...
> MfG
> Axel
> CNE, IBM PSS, AVM ICP, Linux FK
> System- & Network Engineer
Ach ja. PSS, PSE bin ich auch noch.
CCNA in Vorbereitung.
~~~~~~~
OH MANN!! Den PSE hat man mir nicht zuerkannt, diese Schweinebacken!! Weil
ich als CNE und der Dummheit meines Cheffes in der MSCE PSE Schulung
gelandet bin ;)) Habe diese mitgemacht und sogar die Prüfung erfolgreich
abgelegt, aber IBM wollts mir einfach nicht anerkennen. Dreckbacken ;)
MfG
Axel
Joern Weber
"Axel Werner" <awe...@meinpc.homeip.net> schrieb/wrote:
> An die Herren MCSE "Günter Wukoutz" und versnobter Superentwickler "Joern
> Weber":
Dafür hättest du eher ein Plonk verdient.
> MAIL-RELAYING hat. Aber damals waren auch alle "SuperEntwickler" wie Hr
> Weber der Meinung "Der Hamster hat kein Problem mit Relaying...denn er
> verschickt nicht automatisch Mails ins Internet" (Zitat) -
Das ist übrigens Out of the Box noch heute so, da die lokalen Server auf
eine Bindung an den Loopback Adapter (127.0.0.1,localhost) voreingestellt
sind.
> 1. War das schon
> immer BULLSHIT und 2. Komisch das vor einiger Zeit in irgend einer der
> letzten Beta Versionen eine solche ANTI-RELAYING Funktion eingebaut wurde.
> Wozu nur ?! Der Hamster hat doch gar kein Mail-Relaying problem!!!
Solange der Hamster "nur" eine Mail-Proxy war, dessen lokale Server nur im
Intranet arbeiteten, war das Relaying kein Problem. Denn wo kein Server im
Internet dort kein Relaying und kein Problem. Wenn man das Konzept des
SMTP-Servers aber auf das Internet ausdehnen will, hat man letztendlich
ein Problem mit Relaying-Versuchen fertig zu werden.
> Vorschlag: Mal mit ihren Vorlauten und frechen bemerkungen langsam treten
> und immer hübsch sachlich bleiben Hr Weber. Dann ecken Sie auch nicht
> andauernd irgendwo an.
Gegenvorschlag: Leistung für den Hamster erbringen dann weiter maulen.
Solange du aus einem Napf frist das andere füllen, musst du mit diesen
Dingen leben, unteranderem mit der Tatsache von mir ungehobelte Antworten
zu bekommen. Es steht dich frei mich zu ignorieren.
Frei nach Lutz Donnerhacke:
[kompetent, freundlich, kostenlos]
Wähle zwei und nur zwei.
> Nun zu Hr. MCSE Wukoutz. Der Hr Weber versucht schon seit einiger Zeit dir
> folgendes zu sagen:
> Und schon sollte dein Problem gelöst sein!
Nein. Selbst du Allwissender hast des Pudels Kern übersehen. Günther
wollte uns sagen, das die Realy-Sperre einen Bug hat. Das er dieses in
einer anderen Sprache tat als die hier übliche und dabei Newuser-Probleme
vor sich herschiebt, hat die Sache nicht erleichtert. Ihm muss ich aber
dir gegenüber zu gute halten, das er versucht hat seine tatsächlich
vorhandenen Problem selber mit einem Quelltext-Patch abzuhelfen. Über
dessen Sinnhaltigkeit kann man und muss man natürlich streiten. Aber
ersteinmal ist mir dieser Streit lieber als Dein Geschwätz. Günther würde
ich, da er Eigeninitiative und Zähigkeit bewiesen hat, jederzeit wieder
helfen, wenn es mir möglich ist. Bei Dir müsste ich stark darüber
nachdenken.
Joern Weber
"Thomas G. Liesner" <t...@gmx.de> schrieb/wrote:
> Joern Weber schrieb:
>> Relaying an IP-Adressen fest zu machen geht aber nur über meine Leiche,
>> sprich meiner weiteren Mitarbeit an dem Projekt.
>
> Müssen gleich solche Drohungen sein? Es reicht, die Probleme/Nachteile
> vorgeschlagener Änderungen verständlich zu machen, Entscheidungen für
> oder gegen treffe ich bei kritischen Sachen normalerweise nicht einfach
> so.
Ich hatte von dir dazu einen unkritischen Kommentar gelesen. Und ja, ich
stehe zu dem, was ich schreibe. Ich bin nicht bereit etwas in die Doku zu
schreiben, was meiner Überzeugung total widerspricht. Sorry aber damit
müsst ihr leben oder ein anderer es besser machen. Schon die IPAccess.hst
ist nüchtern aus heutiger Sicht betrachtet, ein schwer verdaulicher
Brocken für mich. IP-Adressen zu fälschen gehört heute zu Handwerkszeug
eines jeden Scriptkiddy. Leider war ich zum Zeitpunkt als Jürgen diesen
Schutz für den Hamster schrieb, noch nicht in Sicherheitsfragen so fit wie
heute.
> Im konkreten Fall sehe ich es so, daß Günter die aktuelle Technik noch
> nicht wirklich verstanden hat.
Ack. Das wird er sicherlich noch lernen, wenn er seine Gehirnwäsche bei M$
verdaut hat. Aber ich sehe die Diskussion trotzdem Positiv. Durch Günters
Unvoreingenommenheit konnte von Heiko ein Sicherheitsrelevanter Bug
gefunden werden.
> Ob eine _Ergänzung_ über die IP-Erkennung
> nützlich/suboptimal/schädlich ist, kann ich noch nicht 100%ig
> beurteilen,
Du darfst gerne eine Anfrage in dcsm zu Sicherheit eine
IP-Quelladress-Authentifizierung stellen.
> einen Abbau der momentanen Sicherungen, den du in der
> Mailinglist festgestellt hast (ich selber habe mir den vorgeschlagenen
> Code noch nicht angeguckt), halte ich auf jeden Fall für falsch.
Ich halte es ebenfalls für falsch, Placebos in den Hamster einzubauen. Die
IPAccess.hst ist nach meinem jetzigen Kenntnissstand auch solch ein Teil.
es ist zu mindestens Konzepten bei denen die lokalen Server ans
Internet-Interface gebunden werden eine unsichere Schutzmethode. Ich habe
leider nicht die Zeit um sie zumindesten um eine Methode zu ergänzen
welche statt Quelladressen Netzwerkinterface-Adressen als Filterkritärium
verwendet. Bei Windows-System wäre das, im Gegensatz zu Linux, eine
sichere Schutzmethode zur Trennung von Internet und Intranet.
Nocheinmal zum allgemeinen Verständnis:
Eine TCP-Verbindung wird immer durch eine Quell-IP-Adresse und eine
Ziel-IP-Adresse gekennzeichnet. Der Hamster Filter zur Zeit auf die
Quell-IP-Adresse. Die Quell-IP-Adresse wird vom Absender, in unseren Fall
dem Rechner des Mailreaders, in das Paket eingesetzt. Diese Adresse kann
bei allen System gefälscht, aka ersetzt, werden welche Zugriff auf
RAW-Sockets erlauben. Das sind alle unixiden Systeme und Windows ab WinXP,
welches einen BSD Unix-TCP/IP Stack mitbringt. Es gibt in der unixiden
Szene Toolkits mit denen man sich einen generischen TCP/IP-Stream zusammen
bauen kann. Der Angreifer hat bei dieser Art Angriff nur ein Problem, er
sieht die Server-Antworten des Hamsters nicht. Diese sind allerdings im
Falle des SMTP-Protokolls auch nicht erforderlich. Weder die
Envelope-Antworten noch das OK nach dem Data benötigt man wirklich, um
eine Mail abzusetzen. Beim POP3-Protoll ist ein IP-Spofing daher sowieso
nutzlos. Beim NNTP-Protokoll ist das absetzen eines Postings mit
gefälschte IP-Adresse auch möglich aber schon schwieriger, da hier die
abbonierten Newsgruppen erraten werden müssen.
Joern Weber
Daniel Srostlik
"Axel Werner" <awe...@meinpc.homeip.net> wrote:
> An die Herren MCSE "Günter Wukoutz" und versnobter Superentwickler
> "Joern Weber":
Ich schlage vor, daß Du einen Gang runterschaltest. Deine
Beleidigungen (gesieze) gegenüber Jörn und Günter sind absolut
unangebracht.
> wie schon vor einem Jahr als das ähnliche thema schonmal aufkam,
> das der Hamster ein Grundsätzliches Problem mit MAIL-RELAYING hat.
> Aber damals waren auch alle "SuperEntwickler" wie Hr Weber der
> Meinung "Der Hamster hat kein Problem mit Relaying...denn er
> verschickt nicht automatisch Mails ins Internet" (Zitat)
Vollständige Quellangabe?
1. man kann jeden Hamster so fehlkonfigurieren, daß er ein Mailrelay
ist.
2. man kann auch eine suchere Lösung mit 2 Hamstern anstreben, wurde
in diesem Thread auch schon erwähnt.
> - 1. War das schon immer BULLSHIT und 2. Komisch das vor einiger
> Zeit in irgend einer der letzten Beta Versionen eine solche
> ANTI-RELAYING Funktion eingebaut wurde. Wozu nur ?!
Du hast es nicht wirklich verstanden, oder?
> CNE, IBM PSS, AVM ICP, Linux FK
> System- & Network Engineer
Jetzt fehlt nur noch der Kurs:
Kommunikation im Usenet: 40 Std. Intensivkurs für schwere Fälle
Daniel
--
DS_ManTime: Scripte zum autom. und manuellen Austausch von News und Mails,
ueber Menues konfigurierbar. Den Scheduler kann man auch inkl. Einwahl und
Provider einstellen. Neue Version V1.34 am 03.05.2002
http://micha-wr.bei.t-online.de/hamster/files/hs2-051-DS_ManTime.zip
Joern Weber
"Axel Werner" <awe...@meinpc.homeip.net> schrieb/wrote:
> "Günter Wukoutz" <g...@aon.at> schrieb im Newsbeitrag
> news:w6pI8.122890$ze7.1...@news.chello.at...
>
> ~~~~~~~
> Aha. Das hätte mit schon am Samstag gesagt werden können. Ich war der
> Meinung das Feld FQDN ist dafür zuständig. Habe ich aber auch erwähnt.
> Keiner hatte was dagegen.
> Vorschlag: In die Hilfe aufnehmen.
> ~~~~~~~
Gute Idee. Schreibst Du eine FAQ für die Hilfe-Datei zu diesem Thema?
>
> Das stimmt! Diese Info wurde in dieser Form wohl unterschlagen. Er ging wohl
> davon aus das man sich schon mit der alten Doku des Hamster
> auseinandergesetzt hatte und einem dieses Feld bekannt ist. MAcht aber nix.
> Jetz hammers ja gefunden :)
Die bisherige stable Version sah vom Konzept her den Einsatz als SMTP-MX
nicht vor. Der Version fehlten dazu die notwendigen Feature (nicht nur der
Relay-Schutz). Weiter erforderliche Schutzmechanismen wie das Limit für
Client-Threads am lokalen Server, Login-Timeout u.ä. sind erst in den
letzten Versionen hinzugekommen. Das müsste mal in einfachen Worten
zusammengefasst werden.
> Ich denke das wird sofern es noch nicht drinn steht noch passieren. Hab erst
> neulich irgendwo gelesen das die Help Files sowieso noch nicht ganz auf
> Stand sind. Daher würde es mich nicht wundern.
Nein, die Help-Files habe ich angepasst. Allerdings enthalten die Menü-
Erläuterungen kein zusammengefasstes Know How zu einem speziellen Thema.
Dazu enthält die Hilfe themenbezogene FAQ's. Diese fehlt noch zu dem
MX-Thema. Wenngleich ich eben nochmal eine knappe Erläuterung zu diesem
Thema hinzugefügt habe. Diese ist aber kein Mittel zur Beschaffung von
allgemeinen Know How zu diesem Thema.
> Ich hoffe aber das dies der
> Fall ist wenn das neue Final released wird. Darauf freue ich mich schon
> sehr! Und richtig freue ich mich erst wenn der HAmster bald auch
> selbstständig eine direkten Mail-Forward vornehmen kann!!
Der Maintainer des französischen Hamster arbeitet nach eigener Aussage
daran. Bis so das serienreif ist dauert es aber sicher noch einige Zeit.
> Das stimmt allerdings!!! Deshalb sollte auch kein Vollblut-Programmierer
> alleine versuchen eine User-Doku zu schreiben ;)
Willst Du den Job machen?
Heiko Studt
> Frei nach Lutz Donnerhacke:
> [kompetent, freundlich, kostenlos]
> Wähle zwei und nur zwei.
Der ist gut! Sehr gut sogar... :-)
> Nein. Selbst du Allwissender hast des Pudels Kern übersehen. Günther
> wollte uns sagen, das die Realy-Sperre einen Bug hat. Das er dieses in
> einer anderen Sprache tat als die hier übliche und dabei Newuser-Probleme
> vor sich herschiebt, hat die Sache nicht erleichtert. Ihm muss ich aber
ACK.
> dir gegenüber zu gute halten, das er versucht hat seine tatsächlich
> vorhandenen Problem selber mit einem Quelltext-Patch abzuhelfen. Über
ACK.
> dessen Sinnhaltigkeit kann man und muss man natürlich streiten. Aber
> ersteinmal ist mir dieser Streit lieber als Dein Geschwätz. Günther würde
ACK.
> ich, da er Eigeninitiative und Zähigkeit bewiesen hat, jederzeit wieder
> helfen, wenn es mir möglich ist. Bei Dir müsste ich stark darüber
> nachdenken.
Me too. Ich würde ihm auf jedem Fall versuchen zu helfen.
Die Kommunikation muß natürlich ein wenig optimiert werden, aber das sollte
kein Problem sein...
MFG,
--
Heiko Studt
Günter Wukoutz
> wollte uns sagen, das die Realy-Sperre einen Bug hat. Das er dieses in
> einer anderen Sprache tat als die hier übliche und dabei Newuser-Probleme
> vor sich herschiebt, hat die Sache nicht erleichtert. Ihm muss ich aber
> dir gegenüber zu gute halten, das er versucht hat seine tatsächlich
> vorhandenen Problem selber mit einem Quelltext-Patch abzuhelfen. Über
> dessen Sinnhaltigkeit kann man und muss man natürlich streiten. Aber
> ersteinmal ist mir dieser Streit lieber als Dein Geschwätz. Günther würde
> ich, da er Eigeninitiative und Zähigkeit bewiesen hat, jederzeit wieder
> helfen, wenn es mir möglich ist. Bei Dir müsste ich stark darüber
> nachdenken.
Das freut mich aber.
Innsbesondere, das wir nun diesen Super-Thread abschließen können. Auf die
Version .163? bin ich schon gespannt.
So Long - Bis zum nächsten mal
Günter
Heiko Studt
> Das freut mich aber.
> Innsbesondere, das wir nun diesen Super-Thread abschließen können. Auf die
ACK... Puuuh. ;-)
> Version .163? bin ich schon gespannt.
http://www.goldpool.org/temp/Hamster163.zip
MFG, HTH
--
Heiko Studt