Beiträge von agense

Hey Norbert,

auf ein, zwei Punkte deiner letzten Antwort möchte ich nochmal eingehen.

Zitat

Warum eigentlich zwei MTA? erwartest du ständige Downtimes?

Zitat

Ich persönlich halte die Lösung eventuell für oversized, aber ich kanns auch nur anhand deiner Fakten einschätzen.

hmmm... Wenn du das oversized auf die zwei MTAs beziehst könntest du recht haben. Hier war Ausfallsicherheit der Vater meiner Gedanken. 99% garantierte Verfügbarkeit bedeutet, dass übers Jahr son VServer auch mal 3,5 Tage ausfallen darf. Ein Ausfall, der länger als ein paar Stunden dauert ist aber wohl höchstunwarscheinlich. Daher ist dein Einwand an dieser Stelle wohl gerechtfertigt!

Wollte mir ggf. die Möglichkeit auch offen halten Amavis, Spamassasin und ClamAV auf den Postfix-Kisten laufen zu lassen. Das Ganze ist sehr resourcenhungrig. Amavis braucht je nachdem wieviel Prozesse du laufen hast viel RAM (naja..wenn man nich mehere Cores zur Verfügung hat, ist das eh humbuck), Spamasssin belastet - wenn du eine Vielzahl aufweniger RegEX-Prüfungen durchlaufen läßt - die CPU stark. Zumindest ein kleiner VServer (1 gb ram, keine garantierte Cores) hat dann je nach Mailaufkommen ordentlich was zu tun. Daher dachte ich ich kann LoadBalancing mit Ausfallsicherheit kombinieren (anstatt einen dickeren VServer).

Habe aber eh Forefront für Exchange lizenziert. Von daher kann ich auf dem Relay auf Spam- & Virenprüfung verzichten. Damit ist meine ganze Argumentationskette natürlich hinfällig! Hab die Sache wohl nicht zu Ende gedacht. Wie gesagt --> guter Einwand deinerseits. Werde wohl auf einen zweiten MTA verzichten und mir die Sache am Montag noch mal genau durch den Kopp gehen lassen.

Oversized auf Bezug einen eigenen Relay einzusetzten lasse ich jedoch nicht gelten Du hast recht wenn du behauptest ein SMTP-Forward ins LAN ist nur ein sehr kleines Risiko, jedoch lehne ich INet-Dienste im LAN prinzipiel ab. Ich kenn mich, wenn ich Anfang Ausnahmen zuzulassen, packt mich iwann die Bequemlichkeit und schwup die wups wird OWA (https?) und ActiveSync auch ins LAN geroutet.... Ein leitender Angestellter ist eh schon ganz scharf auf OWA und ActiveSync. Nenene

Außerdem wird der SMTP-Dienst nur über eine schmale, schlechte ADSL-Leitung (feste IP) laufen, die eh je nach Zeit überlastet ist. Hab zwar noch ne SDSL-Leitung zur Verfügung, die ich aber außschließlich für VPN/StandortVernetzung (TerminalServer, AD-Replikation und DFS-R) reserviert ist. Tausende eingehende Connections (blind, falsch adressierter Spam) möchte ich der ADSL-leitung nicht noch zusätzlich auflasten.

Zitat

Ja, wobei die Prio egal ist, da bei identischer Priorität sowieso der mit dem alphabetisch ersten Namen die Hauptlast hat.

Hmm funktioniert DNS-RoundRobin bei MX-Einträgen in der Praxis nicht richtig? Geht das nur mit A-Records? Müßte das noch mal nachschlagen. Ist aber höchstwarscheinlich eh hinfällig (wohl doch nur ein MTA)

Zitat

Hmm kenne diese Funktion nicht, aber wenn du es konfigurieren kannst, warum nicht.

Zitat

Ich glaube du überschätzt die anfallende Last. Damit hat ein Exchange keine Probleme. Glaubs mir. Aber ja, deine Lösung hat ihre Vorteile.

Möchte, wenn ich SMTP einsetzte definitiv auf meinem ersten MTA ungültige Empfänger ablehnen, so dass der einliefernde MTA bounced. Ich finde das gehört sich einfach so! Ein Blackhole hatte ich mit der pop/fetchmail-"Lösung". Ist nicht wirklich höflich. Zudem kommt die ADSl-Leitung wieder ins Spiel - wobei allein das rejecten ungültiger Adressen für mich Grund genug ist.

Zur Empfängerprüfung gibts in Kombi Postfix/Exchange wohl drei Lösungen. Hier ist wohl auschließlich die Prüfung (mit gecachten Ergebnissen) die einzig sinnvoll einsetzbare. Die anderen beiden wären manuelles Pflegen der gültigen eMail-Adressen (schrecklich) oder anonmye LDAP-Anfragen im AD zulassen. Wenn ich die zweite Lösung einsetzten würde, würde wohl bei mir im Oberstübchen was falsch laufen, wenn ich mir gleichzeitig über einen SMTP-Dienst im LAN Gedanken mache

Zudem halte ich die SMTP-Prüfung im übrigen für perfekt und elegant gelöst!

Zitat

Dann würde ich dir empfehlen dir den ISA Server bzw. seinen Nachfolger TMG 2010 anzuschauen. Damit kannst du eine Exchangeveröffentlichung auch ohne DMZ realisieren und mit drei NICs, würdest du dir noch die Möglichkeit einer "DMZ" schaffen.

Kenn mich auf diesem Gebiet(Produkte) in der Tat sehr schlecht aus. Werde mir das mal genauer ansehen. Danke für den Tipp!

Gruss gense

ich denke, dass eine obergrenze von 10 mb .. sinnvoll ist! mehr wird bei mir nicht freigeschaltet. smtp wurde entwickelt um text zu versenden. binäre attachements müßem deshalb in asci (7bit) umgewandelt werden. dabei bläht sich ein attachment nach meiner erfahrung um 20-30% auf! zudem kennt smtp keine komprimierung und ist das denkbar schlechteste protokoll um binäre dateien zu versenden. es ist zu eben ein protokll um einfachen text und nicht mehr und nicht weniger zu versenden! eigentlich gehören user, die finger abgehackt wenn sie versuchen große dateien per email zuversenden.

gerade bei kleineren firmen mit dünner upload-bandbreite und ohne implentiertes qos am gateway kann das ganze zu einer plage werden!

für dateitransfers gibts ftp

so long ...gense

Hallo Norbert,

erst mal vielen Dank, dass du dir den ellenlangen Post durchgelesen und dir dann auch noch die Mühe gemacht hast, Stück für Stück auf meine Ansätze - mit deiner Erfahrung - einzugehen. Echt prima

Wenn ich deine Meinung zu diesem Thema zusammenfasse, so komme ich auf folgende aufsteigend präferierte Lösungen deinerseits.

1. Defintiv per SMTP anbinden
2. Wenns aufgrund der Gegebenheiten nicht anderst geht, gerne auch ein SMTP-Portforwarding ins LAN direkt auf den lokalen Exchange
3. Wenn die Möglichkeit einer DMZ besteht, dort einen SMTP-Relay auf Basis minimum Win2kR2 ohne Exchange implentieren
4. Wenn das Netz entsprechend groß ist und genug Mittel vorhanden sind, gerne einen Exchange als EdgeServer in der DMZ

Auch ich hab mir natürlich in der Zwischenzeit meine Gedanken dazu gemacht und ne Nacht darüber geschlafen! POP-Connectoren sind technisch betrachtet einfach nur ne Notlösung, die in seltesten Fällen vertretbar sind.

Bingo... da hassu voll und ganz Recht und ich bin eignetlich gleicher Meinung. Trotzdem scheine ich hier noch einen kleinen Anschubser benötigt zu haben um die POP-Lösung voll und ganz auszuschließen. Naja... kleiner Anschubser ist gut, wäre in Exchange einer enthalten, hätte ich ihn wohl ohne weiter nachzudenken gewöhnheitsmäßig genutzt. Shame about me. Aber ich betrache mich nun als geheilt

Ich habe eigentlich genug Fachwissen um einen MTA sicher zu konfigurieren und bilde mir zumindest ein zu wissen, was ich konfigurieren möchte und muss. Direkt im Internet betreibe ich bisher jedoch nur einen privaten Fun- und Test-MTA mit Postfix. Lokal habe ich ne handvoll Postfix-MTAs aufgesetzt (jedoch immer nur per fetchmail/pop angbunden). Trotzdem - so bin ich überzeugt 8-) - reicht mein Fachwissen und meine Erfahrung aus, Postfix sicher als Internet-SMTP-Relay zu betreiben.

Weiterhin bin ich mittlerweile der Meinung,dass ich mittelfristig in meinem LAN nicht mehr ohne DMZ auskommen werde. Irgendwann werden User (mittleres Management) OWA fordern, sich ActiveSync für Ihr Android wünschen oder Terminalserver-Sessions von außerhalb und überall und am besten ohne Client nutzen wollen. Einen unüberlegten Schnellschuss werde ich deshalb trotzdem nicht riskieren. Invewerden. Derzeit sind wir noch nicht so weit .... aber diese Wünsche werden kommen.

Aus diesen Gründen habe ich mich vorerst für folgende Lösung entschieden. Bin mir sicher, du hälst es für "amateurhaftes Gefrickel", bin aber unter Abwägung der Gegenheiten und aller Vor- und Nachteile von dieser Lösung überzeugt.

Ich werde bei zwei verschiedenen Hostern (ggf. hetzner, HostEurope, Strato, usw) jeweils einen virtuellen Server mieten und auf beiden Postfix als MTA laufen lassen. Postfix wird per SMTP beim Exhange die Empfänger in Echtzeit auf Gültigkeit überprüfen und die Ergebnisse in einer lokalen DB(Hash) cachen. Dies ist nötig, da wir pro Tag eine mittlere 4stellige Zahl an blind und falsch addressierten Spammails bekommen.

Beide MTAs werden mit gleicher Prio als MX im DNS eingetragen (auf entsprechende PTR-Einteräge achte ich natürlich). So sollte per DNS-Roundrobin eine Lastverteilung stattfinden und die Erreichbarkeit hoch sein (2 verschiedene Rechenzentren).

Exchange kann dann von unnötiger Last befreit (tausende smtp-anfragen durch falsch adressierte Spams) lokal und sicher abgeschottet seine Stärken auspielen. Insgesammt halte ich das für ein gelungene Lösung (auch wenn ich wiederspruch von dir zu erwarten habe?))

Mittelfristig steht dann aber sichrlich iwann eine DMZ an. Dies Bedarf aber weiterer Plaungen und Investionen (Internetanbindung - wir sind aufgrund regionalen Begebenheiten nicht gerade bevorzugt -, weitere Firewall, IPSec-WAN-Verbindugen, weitere Hardware und weitere Services) ...naja... noch Zukunftsmusik.

Dir aber noch mal vielen Dank, dass du dich mit meinen Gedankenansätzen auseinander gesetzt hast!

So long.... grus gense

<doppelt>

Hallo zusammen,

eigentlich ist dieser Post nicht unbedingt Versions-spezifisch, da es jedoch keine allgemeine Exchange-Sektion gibt post ich es unter 2007 (der Version, die wir einsetzten werden).

Offen und ehrlich gesagt,benutze ich zum erstenmal ein Forum für eine berufliche Angelegenheit. Ich hoffe hier aber auf Admins ähnlich kleiner Netzwerke zu stoßen und von Ihren Meinungen und Erfharungen profitieren zu können. Bin mir bei der strategischen Entscheidung der Netzanbindung eines Exchange-Servers nicht ganz sicher.

Ausgangssituation ist, dass ich ein Netz mit ca. 70 Workstations (Tendenz leicht steigend) administriere. Bisher haben wir keinen Exchange Server bzw Groupware-server eingesetzt. Als Mailsystem diente ne Debian-Box mit Postfix als MTA und Dovecote als IMAP/POP-Server. Mails habe ich aus 3 DomainSammelacounts per fetchmail/pop abgeholt. Probleme mit Envelope-Recieptiens habe ich alle elemeniert Das "Implentieren" dieser Lösung (fetchmail/pop) tat mir aber seelisch ungemein weh

Bei ersten Tests und Konfig vom Exchange-Sever fiel mir jedoch auf, dass es bei Exchange wohl keinen POP-Connector mehr gibt! Was konsequent gedacht von Microsoft auch die richtige Entscheidung ist. Jedoch wird mir das natürlich ein wenig meine Planung durcheinander.

Aus dem Grund wollte ich einfach mal fragen, wie das Admins von Netzen ähnlicher Größe handhaben. administriere ja jetzt nicht gerade ein MonsterNetz mit dem Sicherheitsbedürfniss von FortKnox. Meine Mittel sind begrenzt.

Folgende Möglichkeiten sehe:

1.Man kauft sich für 80 Euro popcon o.ä holt den Käs per POP ab und gut ist.
Nachteil ist, dass es wohl die schrecklichste Art ist einen lokalen MTA ans Netz anzuschließen. Probleme sind ggf. vorgrammiert (Envelope-Recieptiens - wie sind hier die ConfigMöglichkeiten von popcon?) und alle Mails müßen angenomen werden. Der MTA müßte als Blackhole konfiguriert werden (Keine BounceMails) und man hat große Datenmengen zu verarbeiten (blind adressierte Spams). Natürlich kann man auch Mailempfänger doppelt pflegen... bääh viel zu faul
dafür!

Vorteil: Der sicherst konfigurierte IneternetDienst, ist immer noch der, der erst gar nicht vorhanden ist -> sprich kein SMTP nach außen, keine DMZ, nix... einfach

2. Portforwarding auf den Exchange
Sicherlich die elegantere Art (auf beschissenem niedrigem Niveau) einen SMTP-Server anzubinden.

Vorteil: Unbekannte Empfänger werden abgelehnt, Last aufem Server wird vermieden (spamprüfung von tausenden falsch adressierten Mails) und ehrliche Absender werden sogar von Ihrem eigenen MailServer benachrichtigt,wenn sie ne falsche Empfänger-Adresse verwenden (rfc-konform und irgwndwie höflich )

Nachteil: öhm INet-Services direkt ins LAn routen!? OOoohje! Sicherheit? kenn ich nicht! Okay, es ist nur der SMTP-Port aber trotzdem, grässlich und ggf. schlafraubend... aber einfach und vorteilhafter im vgl zur Pop-Lösung.

3. Der Microsoft-Weg - Edge-Exchange-Server in der DMZ,der als Relay fungiert.

Sicherlich geil, aber sorry, dafür fehlen mir die ressourcen (pinke, pinke) für Hardware und Lizenzen. Außerdem finde ich es etwas übertrieben nen "ganzen Kerl von ExchangeServer" als Relay zu benutzen! Kannonen, Spatzen, usw.

4. Relay in DMZ auf Linux/Postfix aufsetzten
Vorteil: kleine, urarlt Hardware verwendbar - hab en alten Dual-P3-Server, der pro Tag mehere tausend eMails durch Postfix, Amavis, Spamassasin und ClamAV jagt (99,99% Spam ) und das funktiotutet performant und wunderbar!

Recieptiens können per Postfix "address_verify_relayhost" geprüft und auf dem relay gecached werden (postfix frägt per smtp beim exchange an,ob der empfänger gültig ist und cached die antwort - dadurch wenig last auf dem exchange)

wer keine dmz hat (oder am liebsten keine inet-services im lan anbieten will - wie ich - könnte ggf. virtuelle server von billighoster mieten und das dort extern aufsetzen.

Backup-MX ja/nein!? Ooh mann, dass wird immer komplizerter!

Ich bin gespannt auf eure Meinungen, Lösungen und Erfharungen! Wie habt ihr das gelöst? Brauch bei dem Thema einfach mal en bissel Input, wobei es wenn man sowas ernsthaft betreibt,eh nur einen richtigen geben kann.

Gruss Gense

PS. Habe keine DMZ und keine Dienste nach außen freigeschalet, jedoch werde ich wohl um SMTP nicht mehr herumkommen

PSS. ICH WILL ATRN ... aber bietet ja kein Hoster mehr an (sind bei 1&1, da es hier sehr gut mit BCCs und Envelope-recieptiens klappt - 100% Zuordnung zu lokalen Usern)

PSSS. sorry... für die lange Latte an text... warscheinlich ließt das ehkeine Sau ganz durch