userohnenamen
leider kein name
|
hi
ich hätt eine blöde frage in richtung smtp abwicklung in typo3
wir haben einen managed server und darauf lauft unser webserver mit typo3
da wir vom webserver mails wegschicken wollen/müssen werden diese an unser mailgateway übertragen und von dort aus weggeschickt (damit mx record, reverse dns usw. zusammenpassen)
jetzt hab ich damit natürlich das problem das es zeiten geben wird das unser mailgateway nicht erreichbar ist und somit der webserver die mails nicht an uns weiterreichen kann --> ergo fehlermeldung
jetzt wäre meine idee als smtp fallback die mails direkt vom webserver abschicken zu lassen, aber eben nur dann wenn unser mailgateway nicht erreichbar ist
laut web-agentur würde die implementierung von diesem fallback 3-4 manntage dauern, was mich dahingehend schon etwas wundert, denn rein von meinem verständnis ist das ganze ja nix anderes als ein "try catch" block bei dem ich im fehlerfall einfach eine andere smtp routine ausführe
hat jemand von euch schon mal so etwas in die richtung durchgeführt und erfahrung gemacht um einzuschätzen ob das wirklich die riesige geschichte ist?
tia
|
schizo
Produkt der Gesellschaft
|
Also MX Records und PTR (insofern vorhanden) sollten imho nicht für eine Spamanalyse herangezogen werden.
Warum richtest du kein SMTP Relay auf euren Server ein, welcher die Mails dann weiter bearbeitet? Dann kannst du von deiner Seite aus eventuelle Whitelisteinträge setzen und die Ausfälle des bereits implementierten Mailservers können durch Queueing am Webserver umgangen werden.
|
userohnenamen
leider kein name
|
Also MX Records und PTR (insofern vorhanden) sollten imho nicht für eine Spamanalyse herangezogen werden. gmail machts z.b. definitiv du bekommst dann z.b. sogar eine xtra meldung angezeigt das die mail von dem und dem server verschickt wurde (und das eben nicht der dafür vorgesehene mailserver ist) Warum richtest du kein SMTP Relay auf euren Server ein, welcher die Mails dann weiter bearbeitet? genau das hab ich ja jetzt (ok, beschißen beschrieben von mir) problem ist nur, ich kann für unseren smtp keine 100% uptime garantieren strom/internetausfall, reboot von mir zwecks update oder was weiß ich typo3 kann laut aussage eben so auch kein Queueing damit er probiert die mail dann nochmals abzusetzen vor allem kannst du dann nicht instant auf der webseite beim ausfüllen des formulars eine OK-Meldung ausgeben (sieht man ja immer ala "ihre mail ist jetzt verschickt worden usw")
|
schizo
Produkt der Gesellschaft
|
Warum richtest du kein SMTP Relay auf euren Server ein, welcher die Mails dann weiter bearbeitet?
[/b] Ist halt die Frage, wie das Mail dann weiter behandelt wird, obs in ein Greylisting kommt oder dergleichen. Instant blockiert wirds afair nicht. genau das hab ich ja jetzt (ok, beschißen beschrieben von mir)
problem ist nur, ich kann für unseren smtp keine 100% uptime garantieren
strom/internetausfall, reboot von mir zwecks update oder was weiß ich
typo3 kann laut aussage eben so auch kein Queueing damit er probiert die mail dann nochmals abzusetzen
vor allem kannst du dann nicht instant auf der webseite beim ausfüllen des formulars eine OK-Meldung ausgeben (sieht man ja immer ala "ihre mail ist jetzt verschickt worden usw") Also wenn der Webserver das Mail an den lokalen (am Webserver befindlichen) Mailserver übergibt kann ja sehr wohl eine Meldung ausgegeben werden. Und der Webserver relayed dann einfach über euren Server (bzw. queued, wenn euer Mailserver nicht erreichbar ist). edit: ich gehe davon aus, dass der Webserver derzeit direkt euren Firmeninternen SMTP verwendet, liege ich da eh richtig?
Bearbeitet von schizo am 30.04.2013, 18:04
|
davebastard
Vinyl-Sammler
|
für sowas (erster mailserver down) gibts normalerweise den mx20 eintrag im DNS. das ist dann der server der verwendet wird wenn der erste nicht funktioniert und dann die mails queued. in firmenumgebungen hat man den normalweise auf einem anderen standort bzw. in einem anderen rechenzentrum. in deinem fall könntest den server auf dem der webserver lauft als mx20 nehmen. dazu muss der MTA (exim,qmail,postfix,...) eben als smtp relay eingerichtet werden wie von schizo vorgeschlagen. wenns ein managed server is weiß ich aber nicht wie weit man selber was machen kann. imho sagt ja "managed" dass die das machen oder  (hab damit keine erfahrungen) edit: die manntage halt ich für stark übertrieben, würde das auf einen halben manntag oder so schätzen...auch nur wegen testen usw. hast eine aufstellung was da solang dauern soll ?
|
schizo
Produkt der Gesellschaft
|
Die Lösung mit dem fallback MX halte ich eigentlich nicht für geeignet.
Auf ein Webserver, der nur Formulardaten verschicken soll hat ein Firmenmailserver, und wenns nur ne Fallbacklösung ist im Grunde nix verloren.
Darauf läufts jedoch hinaus, wenn ein MX Record auf diesen zeigt. IP Range Einschränkungen kann man auch nicht einsetzen, da ansonsten die Mails mit ner 500er Meldung abgewiesen werden und diese dadurch nicht erneut zugestellt werden.
Insofern wäre die brauchbarste Lösung einfach einen MTA zu installieren, der von Haus aus die Mails auf den Mailserver relayed und dieser sich um den Rest kümmert.
|
davebastard
Vinyl-Sammler
|
Auf ein Webserver, der nur Formulardaten verschicken soll hat ein Firmenmailserver, und wenns nur ne Fallbacklösung ist im Grunde nix verloren. wieso? seh ich nicht so, solang der server gscheit abgesichert ist seh ich da kein problem. ich finds eher bedenklich das es keinen ausfallserver an anderem standort für mail gibt. was ist wenn der strom ausfällt, was ist wenn das internet ausfällt am hauptstandort usw. IP Range Einschränkungen kann man auch nicht einsetzen, da ansonsten die Mails mit ner 500er Meldung abgewiesen werden und diese dadurch nicht erneut zugestellt werden. musst genauer erklären, wo sollen keine ip-einschränkungen möglich sein ?
|
schizo
Produkt der Gesellschaft
|
Wenns nie gestritten habts werdets ev doch ähnlicher sein als euch eingestehts.
[/b] Ich möchte mich zumindest nicht auf einen managed Server verlassen, auf den ich sicherheitstechnisch keinen Einfluss habe. Dass ein sekundärer Mailserver im Grunde sinnvoll ist bestreite ich ja nicht. Aber wenn, dann richtig und nicht als anhängsel eines Webservers, sondern als eigene (physikalische od. virtualisierte) Instanz. musst genauer erklären, wo sollen keine ip-einschränkungen möglich sein ? Am MTA selber. Wenn eine vorliegende Firewall den Port 25 blockiert ist das natürlich wieder was anderes. Aber warum setzt man dann überhaupt den Fallback MX?
|
davebastard
Vinyl-Sammler
|
Ich möchte mich zumindest nicht auf einen managed Server verlassen, auf den ich sicherheitstechnisch keinen Einfluss habe.
Dass ein sekundärer Mailserver im Grunde sinnvoll ist bestreite ich ja nicht. Aber wenn, dann richtig und nicht als anhängsel eines Webservers, sondern als eigene (physikalische od. virtualisierte) Instanz. ja sicher ist es gscheiter, es ging mir eher darum dass es imho sowieso wichtig ist eine fallback lösung zu haben und das problem mit den formularen dann auch gleich behoben ist. Am MTA selber. Wenn eine vorliegende Firewall den Port 25 blockiert ist das natürlich wieder was anderes. Aber warum setzt man dann überhaupt den Fallback MX? und warum sollen keine ip-einschränkungen möglich sein ? kann ja die selben einschränkungen haben wie am haupt-MTA, dass smtp nicht generell geblockt werden kann ist aber bei einem smtp-server klar...
|
schizo
Produkt der Gesellschaft
|
und warum sollen keine ip-einschränkungen möglich sein ? kann ja die selben einschränkungen haben wie am haupt-MTA, dass smtp nicht generell geblockt werden kann ist aber bei einem smtp-server klar... Wenn du am MTA die IP Adressen einschränkst, von welchen du Mails annimmst werden Mails von sämtlichen anderen IP Adressen mit einer 500er Fehlermeldung abgewiesen. Wenn dann der primäre Mailserver nicht erreichbar ist werden somit sämtliche Mails abgewiesen, anstatt vom absendenden Mailserver gequeued zu werden.
|
userohnenamen
leider kein name
|
danke mal für eure diskussion und anregungen  ein zweites mailgateway würd mir in dem fall auch nix bringen, da es laut agentur eben nicht möglich ist im fehlerfall auf ein zweites zuzugreifen (ohne eben die 4 tage mannzeit) und so für die firma habe ich nicht die vorrausetzungen um das auch wirklich sinnvoll umzusetzen bzw. würds ned viel bringen hinter dem mailgateway ist ein einzelner exchange server usw. und selbst wenn alles down ist, im normalfall wird versucht mails 3 tage lang zuzustellen, von daher seh ich das risiko als annehmbar hin  hat jetzt aber nix mitn topic ansich zu tun postfix scheint auf dem hetzner managed server nicht möglich zu sein (Auch mal die aussage von der agentur, werd morgen wohl nochmals selbst mit hetzner kontakt aufnehmen) dass das thema so lästig ist hätt ich auch ned gedacht 
|
schizo
Produkt der Gesellschaft
|
Ich hab mir jetzt zwar die Hetzner AGB nicht durchgelesen, sondern nur mal eben Google bemüht. Da findet sich im Hetzner Wiki eine Howto für Postfix: http://wiki.hetzner.de/index.php/In...Installation/enhttp://wiki.hetzner.de/index.php/DebianMailserverAlso prinzipiell kann ich mir schon vorstellen, dass es Hoster gibt, die selbst gehostete Mailserver unterbinden wollen, um deren IP Range von Blacklists fern zu halten. Dass ein solcher Hoster dann aber Howtos anbietet würde mich schon etwas wundern edit: mah überlesen, dass die Aussage auf die managed Server bezogen war.
|
davebastard
Vinyl-Sammler
|
Wenn du am MTA die IP Adressen einschränkst, von welchen du Mails annimmst werden Mails von sämtlichen anderen IP Adressen mit einer 500er Fehlermeldung abgewiesen.
Wenn dann der primäre Mailserver nicht erreichbar ist werden somit sämtliche Mails abgewiesen, anstatt vom absendenden Mailserver gequeued zu werden. der sekundäre mailserver muss natürlich genauso alle mails (außer vielleicht DNSBLs) annehmen wie der haupt MTA, das ist aber sowieso klar sonst kann ich ihn ja ned als ersatz für den ersten nehmen, aber wo ist das problem mit 500er ?
|
schizo
Produkt der Gesellschaft
|
Wenn der Server alle Mails annimmt eh keiner.
Nachdem das ganze für mich aber eher danach klingt, als hätte er in weiterer Folge keinen Einfluss auf den Server. Und in einem solchen Fall dort den sekundären Mailserver laufen zu lassen ist eben nicht vernünftig.
Bearbeitet von schizo am 08.05.2013, 11:10
|
userohnenamen
leider kein name
|
jop, ich hab dort leider keinerlei weiteren einfluss, und den switch zum root-server möcht ich mir eben sparen, dort wär das dann ja kein problem
aktuell versuch ich die problematik per SPF eintrag zu lösen, so das gmail und co nicht alarm schlagen
leider scheint upc mit dem spf eintrag noch irgendwas nicht auf die reihe zu bekommen (den kann man bei deren kundenportal nicht selbst setzen, leider)
|
Anmeldung