Hallo,
ich habe einen Mailserver mit Exim aufgesetzt. Ich versende gerne 8bit-Mails und empfange auch gern solche. Also habe ich im exim "accept_8bitmime = true" und verstoße damit gegen rfc1652. (Exim announced 8BITMIME auf ein EHLO und schickt 8bit-Mails ohne Umkodierung an MTAs weiter, die kein 8BITMIME melden.)
Nun habe ich aber einen MTA in der Nachbarschaft, mit dem ich ab und zu reden muß und der aus 8bit-Mails Schrott macht. Die Mails an diesen MTA würde ich gern nach Quoted-Printable wandeln, bevor ich sie weiterschicke. Hat jemand eine Idee, wie ich das mit Exim realisieren kann?
Reinhard
On Fri, Sep 27, 2002 at 12:37:58AM +0200, Reinhard Foerster wrote:
Hallo,
ich habe einen Mailserver mit Exim aufgesetzt. Ich versende gerne 8bit-Mails und empfange auch gern solche. Also habe ich im exim "accept_8bitmime = true" und verstoße damit gegen rfc1652. (Exim announced 8BITMIME auf ein EHLO und schickt 8bit-Mails ohne Umkodierung an MTAs weiter, die kein 8BITMIME melden.)
Nun habe ich aber einen MTA in der Nachbarschaft, mit dem ich ab und zu reden muß und der aus 8bit-Mails Schrott macht. Die Mails an diesen MTA würde ich gern nach Quoted-Printable wandeln, bevor ich sie weiterschicke. Hat jemand eine Idee, wie ich das mit Exim realisieren kann?
Nein, leider nicht. Ich habe aber ein dickes Buch zu Exim im Schrank stehen. Damit es nicht verstaubt müsste es mal gelesen werden. Du kannst es gerne für ein paar Wochen haben.
thomas
On Fri, 27 Sep 2002 08:19:33 +0200, Thomas Guettler wrote:
Hallo Thomas,
Nein, leider nicht. Ich habe aber ein dickes Buch zu Exim im Schrank stehen. Damit es nicht verstaubt müsste es mal gelesen werden. Du kannst es gerne für ein paar Wochen haben.
Danke fürs Angebot. Das Buch hatte ich schonmal von Heiko. Exim3 hat keine Möglichkeit eingebaut, auf die Meldungen der folgenden MTAs zu reagieren. Die Frage ist, ob sich bei Exim 4 was geändert hat. Ich habe noch nichts dazu in der Doku gefunden.
Reinhard
Hi,
* Reinhard Foerster [02-09-27 00:53:34 +0200] wrote:
ich habe einen Mailserver mit Exim aufgesetzt. Ich versende gerne 8bit-Mails und empfange auch gern solche. Also habe ich im exim "accept_8bitmime = true" und verstoße damit gegen rfc1652. (Exim announced 8BITMIME auf ein EHLO und schickt 8bit-Mails ohne Umkodierung an MTAs weiter, die kein 8BITMIME melden.)
Nun habe ich aber einen MTA in der Nachbarschaft, mit dem ich ab und zu reden muß und der aus 8bit-Mails Schrott macht. Die Mails an diesen MTA würde ich gern nach Quoted-Printable wandeln, bevor ich sie weiterschicke. Hat jemand eine Idee, wie ich das mit Exim realisieren kann?
Mit Exim nicht, aber wenn sich Empfaenger-basiert dafuer keine Loesung findet, bleibt immer noch der Client, den man automatisch 7bit verschicken lassen kann.
bye, Rocco
On Fri, 27 Sep 2002 10:51:26 +0200, Rocco Rutte wrote: Moins Rocco,
Mit Exim nicht, aber wenn sich Empfaenger-basiert dafuer keine Loesung findet, bleibt immer noch der Client, den man automatisch 7bit verschicken lassen kann.
Jo, das geht immer. Nur müßten dazu die Leute die Mailclients umkonfigurieren. Das macht doch keiner. QP oder bas64 mails per default ist ja auch eigentlich Kacke. Dann kommen noch Mails von außen über diese 7bit-Schrottkiste und werden dann so verkorkst an meine Kollegen verteilt. Da bin ich ersmal machtlos. Hoffnung, daß sich dort kurzfristig was tut habe ich auch nicht. Was solls ...
Aber nochwas nervt: Da der zentrale Mailsever der Uni (nicht Informatik) kein 8BITMIME annonciert (default bei Exim), schlagen hier massenhaft von fremden sendmails auf base64 oder QP umkodierte Mails auf, die mein exim dann so in die Mailboxen der Nutzer legt. Die Dinger kann man dann nicht per grep durchsuchen oder anderweitg ohne irgendwelche MIME-Filter barbeiten.
Hinter einem sich als 7bit-MTA ausgebendem exim ist man mit einem anderen Exim ziemlich aufgeschmissen. Ich sehe mich schon wieder sendmail installieren.
Rocco, du bist doch Postfix-Nutzer. Kann Postfix QP- oder base64-Mails nach 8bit wandeln, bevor er sie in die Mailboxen legt? Im Archiv der Postfix-Liste gefunden, daß das mal eingebaut werden sollte. Klappt das?
Reinhard
On Fri, 27 Sep 2002 15:08:08 +0200, Reinhard Foerster wrote:
Rocco, du bist doch Postfix-Nutzer. Kann Postfix QP- oder base64-Mails nach 8bit wandeln, bevor er sie in die Mailboxen legt? Im Archiv der Postfix-Liste gefunden, daß das mal eingebaut werden sollte. Klappt das?
Ich habe wohl schon die Antwort. Wietse's neue MIME state machine ist erst in Postfix-Snapshots ab dem 27.5.2002 drin. Im aktuellen stable 1.1.11 fehlt sie noch und somit auch jede Art von Konvertierung. Dann warte ich mal noch ab. Ich finde es Klasse, daß in Postfix sowas eingebaut wird.
Reinhard
Hi,
* Reinhard Foerster [02-09-27 16:37:45 +0200] wrote:
On Fri, 27 Sep 2002 10:51:26 +0200, Rocco Rutte wrote:
Mit Exim nicht, aber wenn sich Empfaenger-basiert dafuer keine Loesung findet, bleibt immer noch der Client, den man automatisch 7bit verschicken lassen kann.
Jo, das geht immer. Nur müßten dazu die Leute die Mailclients umkonfigurieren. Das macht doch keiner.
Stimmt. Aber eine andere Idee waere, einfach das sendmail- bzw. inject-Binary durch ein Skript zu ersetzen, was vor dem Verschicken wandelt und es gleichzeitig auch dem MDA beizubringen. Allerdings ist die Schmerzgrenze ziemlich hoch, um sowas realisieren zu wollen.
Aber nochwas nervt: Da der zentrale Mailsever der Uni (nicht Informatik) kein 8BITMIME annonciert (default bei Exim), schlagen hier massenhaft von fremden sendmails auf base64 oder QP umkodierte Mails auf, die mein exim dann so in die Mailboxen der Nutzer legt. Die Dinger kann man dann nicht per grep durchsuchen oder anderweitg ohne irgendwelche MIME-Filter barbeiten.
Ich hoere immer wieder recht gute Sachen ueber ``grepmail''; aber wenn ich die Homepage so ueberfliege, ist es fuer dich wohl auch keine Loesung.
Ich sehe mich schon wieder sendmail installieren.
Fuer solche (sorry:) Sonderwuensche ist man wohl mit sendmail immer noch am besten beraten, weil der Interpreter fuer sendmail.cf ziemlich leistungsfaehig ist.
Kann Postfix QP- oder base64-Mails nach 8bit wandeln, bevor er sie in die Mailboxen legt?
Auch wenn du das nicht hoeren willst: jein. Nein, weil ist nicht eingebaut (kann mich auch irren, so oft installiere ich keine MTAs). Ja, weil du auf jeden Fall einen Content-Filter angeben kannst, wodurch die Mails geschleust werden (Virenscanner, Shell-/Perl-Skripte, weitere Postfix-Instanzen etc.). D.h., du muesstest dir ein Skript besorgen, was die Pruefungen und Wandlungen vornimmt.
Im Archiv der Postfix-Liste gefunden, daß das mal eingebaut werden sollte. Klappt das?
Ich habe vor Ewigkeiten meine Postfix-Installationen eingerichtet... und seit dem laufen die auch. Das letzte, was ich im Context von Postfix und 8bit gehoert habe, ist, dass man (IIRC) mit einem Switch jetzt Mails mit 8bit-Zeichen (im Header?) ablehnen kann, wenn diese nicht ordnungsgemaess deklariert wurden, um anfallenden Datenmuell zu begrenzen. Das soll sogar einen Teil Spam wegfiltern.
Zur Not gibt es ja auch noch Usenet mit Leuten, die sich (im Gegensatz zu mir) wirklich damit auskennen.
bye, Rocco
On Sat, 28 Sep 2002 13:08:38 +0200, Rocco Rutte wrote:
Hallihallo,
Ich sehe mich schon wieder sendmail installieren.
Fuer solche (sorry:) Sonderwuensche ist man wohl mit sendmail immer noch am besten beraten, weil der Interpreter fuer sendmail.cf ziemlich leistungsfaehig ist.
ja, ich habe mich schon für sendmail entschieden. Ich habe mir gestern eine Testsumgebung aus 2 sendmails aufgebaut. Die meisten Dinge klappen schon. Allerdings sind das zwei sendmails in Urform (ein selbstgebautes von sendmail.org auf Linux und eins onboard in NetBSD)
Jetz kämpfe ich verzweifelt gegen die debianisierte Variante von sendmail. Das Paket in stable ist eigentlich völlig unbrauchbar. Die Installation geht in die Hose, das Konfigskript erstellt das die debianspezifische sendmail.conf nicht und das 23kB Init-skript will seine obskuren Wünsche befriedigt haben.
Soweit kein Problem, für die Bugs gibts Bugreports und scheinbar auch Fixes - leider landen die nur in testing :-( Ist Nichtfunktion eines Paketes bei Debian kein Grund für ein Update?
Wie bekomme ich die testing Paket nun installiert?
$ dpkg -i sendmail_8.12.6-5_i386.deb dpkg: regarding sendmail_8.12.6-5_i386.deb containing sendmail: sendmail conflicts with mail-transport-agent exim provides mail-transport-agent and is installed. dpkg: error processing sendmail_8.12.6-5_i386.deb (--install): conflicting packages - not installing sendmail Errors were encountered while processing: sendmail_8.12.6-5_i386.deb Exit 1
$ dpkg -I sendmail_8.12.6-5_i386.deb |grep mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent, sendmail-tls Provides: mail-transport-agent
Ist das richtig so? Ein Konflikt auf etwas, was das Paket selbst anbietet?
Zur Not gibt es ja auch noch Usenet mit Leuten, die sich (im Gegensatz zu mir) wirklich damit auskennen.
Ich habe mich wirklich gründlich durch google(+groups) und die Mailinglisten von Exim und Postfix gewühlt. Es gibt die Fraktion der "Einfach-alles-8bit-Sender-egal-ob-das-Ziel-es-versteht" und paar Hanseln, die versuchen, sich an die RFCs zu halten. Die zweiten Gruppe hat noch keine Alternative zu sendmail. Postfix wird bald eine Alternative sein.
Reinhard
On Sat Sep 28, 2002 at 15:27:05 +0200, Reinhard Foerster wrote:
Soweit kein Problem, für die Bugs gibts Bugreports und scheinbar auch Fixes - leider landen die nur in testing :-( Ist Nichtfunktion eines Paketes bei Debian kein Grund für ein Update?
Naja, ganz kaputte Sachen kommen evtl. in ein rX-Release rein, aber normalerweise ist das wohl nur für Sicherheitsupdates. Außerdem sollten Pakete in stable zuvor in testing/frozen ausreichend getestet worden sein. So die Theorie.
Wie bekomme ich die testing Paket nun installiert?
$ dpkg -i sendmail_8.12.6-5_i386.deb dpkg: regarding sendmail_8.12.6-5_i386.deb containing sendmail: sendmail conflicts with mail-transport-agent exim provides mail-transport-agent and is installed. dpkg: error processing sendmail_8.12.6-5_i386.deb (--install): conflicting packages - not installing sendmail Errors were encountered while processing: sendmail_8.12.6-5_i386.deb Exit 1
Exim deinstallieren.
$ dpkg -I sendmail_8.12.6-5_i386.deb |grep mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent, sendmail-tls Provides: mail-transport-agent
Ist das richtig so? Ein Konflikt auf etwas, was das Paket selbst anbietet?
Ja, das sorgt dafür, dass es immer nur einen mail-transport-agent gibt. Ist bei anderen MTAs auch so.
Adam
Hallo Reinhard,
On Sat, Sep 28, 2002 at 03:27:05PM +0200, Reinhard Foerster wrote:
Wie bekomme ich die testing Paket nun installiert?
$ dpkg -i sendmail_8.12.6-5_i386.deb dpkg: regarding sendmail_8.12.6-5_i386.deb containing sendmail: sendmail conflicts with mail-transport-agent exim provides mail-transport-agent and is installed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Solange Du exim installiert hast, wird sich dpkg weigern, einen anderen MTA zu installieren, es sei denn, Du kannst es mit einer der force-Optionen davon ueberzeugen, dass Du weisst was Du tust.
dpkg: error processing sendmail_8.12.6-5_i386.deb (--install): conflicting packages - not installing sendmail Errors were encountered while processing: sendmail_8.12.6-5_i386.deb Exit 1
$ dpkg -I sendmail_8.12.6-5_i386.deb |grep mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent, sendmail-tls Provides: mail-transport-agent
Ist das richtig so? Ein Konflikt auf etwas, was das Paket selbst anbietet?
Bei 'Conflicts:' ist das Paket selber ausgenommen, d.h. ein Paket hat mit den von ihm bereitgestellten virtuellen Paketen keine Probleme.
Holger
Am Samstag, dem 28. September 2002 um 15:27:05, schrieb Reinhard Foerster:
Ist Nichtfunktion eines Paketes bei Debian kein Grund für ein Update?
Stable bedeutet eben stabil, updates gibt es nur bei Sicherheitsproblemen und dann sind es in der Regel Rückportierungen.
Wie bekomme ich die testing Paket nun installiert?
Am einfachsten mit apt oder umständlich mit
# dpkg -r exim # dpkg -i sendmail*.deb
Die Fehlermeldung, die bei der ersten Zeile kommt, kannst du getrost ignorieren.
Es gibt die Fraktion der "Einfach-alles-8bit-Sender-egal-ob-das-Ziel-es-versteht" und paar Hanseln, die versuchen, sich an die RFCs zu halten.
Die letzten sind wahrscheinlich solche, die aufgrund ihrer Muttersprache mit schlechten RFCs leben können. Fehlender 8Bit-Support in Unicode-Zeiten klingt einfach völlig buggy.
Torsten
On Fri, 11 Oct 2002 08:37:51 +0200, Torsten Werner wrote:
Am Samstag, dem 28. September 2002 um 15:27:05, schrieb Reinhard Foerster:
Ist Nichtfunktion eines Paketes bei Debian kein Grund für ein Update?
Stable bedeutet eben stabil, updates gibt es nur bei Sicherheitsproblemen und dann sind es in der Regel Rückportierungen.
Nunja. Wegen falscher Zugriffsrechte und Eigentümerschaft nicht funktionierende Pakete als sicher zu definieren ist schon seltsam.
Es gibt die Fraktion der "Einfach-alles-8bit-Sender-egal-ob-das-Ziel-es-versteht" und paar Hanseln, die versuchen, sich an die RFCs zu halten.
Die letzten sind wahrscheinlich solche, die aufgrund ihrer Muttersprache mit schlechten RFCs leben können.
Nein, genau umgekehrt. Die letzten sind die, die auch 8bit-Mails *sicher* durch die ganze Welt verschicken wollen. Die Leute mit ASCII-Muttersprache gehören zur ersten Fraktion. Sie stört es nicht, wenn das 8. Bit mal unter den Tisch fällt.
Fehlender 8Bit-Support in Unicode-Zeiten klingt einfach völlig buggy.
Eben. Deshalb kann ich insbesondere die Leute mit exim in default Konfig (also ohne "accept_8bitmime") nicht verstehen. Es ist doch scheinheilig sich als 7bit-MTA auszugeben nur um bei geschrotteten 8bit-Mails sagen zu können: "An mir lag es nicht. Ich habe gesagt ich bin ein 7bit-MTA aber der böse MTA vor mir hat mir trotzdem eine 8bit-Mail geschickt." Da exim genau so ein böser MTA ist, der 8bit-Mails annimmt und an 7bit-MTAs ohne Umwandlung weiterschickt ist das doch eine völlig idiotische Ausrede.
Nebenbei erzwingt ein solcher Exim in default Konfig einen an der Stelle RFC-konformen MTA (sprich sendmail) dazu, alle Mails an den Exim nach 7bit zu wandeln. :-(
Exim in default Konfig gelingt es damit perfekt, alle Dummheiten auf sich zu vereinen. Einerseits ist man sowieso inkompatibel zu 7bit-MTAs und andererseits sorgt man für massenhaft völlig sinnlos nach 7bit konvertierte 8bit-Mails von einliefernden sendmails, indem man sich selbst als 7bit-MTA ausgibt, zu dem man eigentlich selbst inkompatibel ist. Dümmer gehts nimmer.
Die per eximconfig erstellte Konfiguration in Debian woody realisiert übrigens genau diese dümmste aller möglichen Varianten. Ich kann nur allen Exim-Nutzern raten "accept_8bitmime = true" in ihre exim.conf zu schreiben.
Der (ebenfalls nicht RFC-konforme) Ansatz von qmail, sich einfach auf gut Glück immer als 8Bit-MTA auszugeben, obwohl man die Wandlung nach 7bit nicht beherrscht ist wenigstens langfristig gesehen erfolgreich. Damit kommt man irgendwann zu einer Welt, die sich zu 99% als 8bit MTA meldet und könnte dann irgendwann anfangen, Mails an 7Bit-MTAs als unzustellbar zurückzuweisen. Dann ist Mail im Internet 8bit-clean und RFC-konform. Da wollen wir hin.
Tatsächlich sind wohl 9x% der MTAs dieser Welt bereits heute 8bit-clean. Leider sind darunter massenhaft dumme Exims ohne accept_8bitmime, die weiterhin bockig den 7bit-MTA spielen. Dank solcher Exims kann man es sich auch in Zukunft nicht leisten, Mails an 7bit-MTAs einfach als Fehler zurückzuweisen um damit die letzten 7bit-MTAs endgültig zu beerdigen.
Es wäre so schön, wenn alle auf eine Beendigung der grausamen Zeit der 7bit-Mails hinarbeiten würden.
BTW: Wer noch nie was über 8bit-Fähigkeit von MTAs gelesen hat und nicht versteht, wovon ich hier rede, möge rfc1426 lesen. Dieser RFC ist das Tor zu Mails mit 8bittigem MIME-Body heraus aus der ursprünglich rein 7bittigen Welt, die durch rfc822 in Stein gemeißelt wurde. Keine Angst: Das sind nur 3 Seiten. Der Absatz mit "A client SMTP has two options ..." ist der interessante Teil für die Interaktion mit "alten" 7bit-MTAs wie exim ohne accept_8bitmime.
Reinhard
Am Freitag, dem 11. Oktober 2002 um 11:00:05, schrieb Reinhard Foerster:
Nunja. Wegen falscher Zugriffsrechte und Eigentümerschaft nicht funktionierende Pakete als sicher zu definieren ist schon seltsam.
Das sendmail-Problem kenne ich zugegebenermaßen nicht. Manchmal ist es aber so, dass bekannte Probleme in stable deswegen nicht gefixt werden, weil es wiederum bekannte Workarounds gibt, die man nicht mit einen reparierten Paket kaputt machen will. Stable heisst eben stable, auch wenn es nicht völlig fehlerfrei ist.
"An mir lag es nicht. Ich habe gesagt ich bin ein 7bit-MTA aber der böse MTA vor mir hat mir trotzdem eine 8bit-Mail geschickt."
Das verstehe ich nicht, exim ist auch ohne "accept_8bitmime = true" 8bit-clean, nur das SMTP EHLO wird durch die Option geändert. Und in der Doku wird auch begründet, weswegen "no_accept_8bitmime" Standard ist. Im übrigen ist das keine Eigenart des Debianpakets.
Den Rest deiner Argumentation verstehe ich nicht, weil mir nicht klar ist, was "accept_8bitmime = true" wirklich ändern soll. Das interne Verhalten von exim ändert es jedenfalls nicht.
Der (ebenfalls nicht RFC-konforme) Ansatz von qmail, sich einfach auf gut Glück immer als 8Bit-MTA auszugeben, obwohl man die Wandlung nach 7bit nicht beherrscht ist wenigstens langfristig gesehen erfolgreich.
Das ist dasselbe wie "accept_8bitmime = true" in exim.
Torsten
On Fri, 11 Oct 2002 14:46:16 +0200, Torsten Werner wrote:
Am Freitag, dem 11. Oktober 2002 um 11:00:05, schrieb Reinhard Foerster:
Nunja. Wegen falscher Zugriffsrechte und Eigentümerschaft nicht funktionierende Pakete als sicher zu definieren ist schon seltsam.
Das sendmail-Problem kenne ich zugegebenermaßen nicht. Manchmal ist es aber so, dass bekannte Probleme in stable deswegen nicht gefixt werden, weil es wiederum bekannte Workarounds gibt, die man nicht mit einen reparierten Paket kaputt machen will. Stable heisst eben stable, auch wenn es nicht völlig fehlerfrei ist.
Ich glaube es wurde Nutzer und Gruppe X:X erstellt, dann aber chown Y:Y gemacht. Jedenfalls fiel das sofort auf weil der MTA nicht in seine Verzeichnisse schreiben konnte. Das Paket aus sarge funktionierte.
"An mir lag es nicht. Ich habe gesagt ich bin ein 7bit-MTA aber der böse MTA vor mir hat mir trotzdem eine 8bit-Mail geschickt."
Das verstehe ich nicht, exim ist auch ohne "accept_8bitmime = true" 8bit-clean, nur das SMTP EHLO wird durch die Option geändert.
Richtig.
Und in der Doku wird auch begründet, weswegen "no_accept_8bitmime" Standard ist.
Und diese Begründung ist ein Witz.
Im übrigen ist das keine Eigenart des Debianpakets.
Ja.
Den Rest deiner Argumentation verstehe ich nicht, weil mir nicht klar ist, was "accept_8bitmime = true" wirklich ändern soll. Das interne Verhalten von exim ändert es jedenfalls nicht.
Intern nicht. Wenn aber exim Ziel-MTA ist und die Quelle ein standardkonformer MTA ist, wandelt der Quell-MTA 8bit-Mails nach 7bit (QP oder base64) um, bevor er sie an den exim mit no_accept_8bitmime weiterschickt. Dieser 7bit-Müll landet dann so in den Mailboxen der Emfpänger obwohl in 99% der Fälle abgesehen vom fehlenden 8BITMIME auf EHLO des exims kein Grund für die Umwandlung bestand. Exim sorgt also dafür, daß fleißig sinnloserweise nach 7bit umgewandelt wird.
Ist der Quell-MTA auch ein exim (oder qmail,...) bekommt der Zielexim auch ohne 8BITMIME zu melden 8bit-Mails aufgedrängt und nimmt diese an. In diesem Fall unterhalten sich 2 eigentlich kaputte MTAs und es klappt trotzdem :-) (Zumindest wenn nicht noch ein wirklicher 7bitter folgt)
no_accept_8bitmime bringt also genau folgendes: Exim bekommt nach wie vor 7 und 8bit-Mails von anderen MTAs, zwingt aber standardkonforme MTAs dazu, 8bit-Mails nach 7bit zu wandeln. Ich sehe da nur nachteiel, keine Vorteile. (abgesehen von der Alibi-Ausrede im Fehlerfall, die ich in der vorherigen Mail schon beschrieb und die - etwas blumiger formuliert - als Grund für no_accept_8bitmime in der Exim-Doku steht)
Der (ebenfalls nicht RFC-konforme) Ansatz von qmail, sich einfach auf gut Glück immer als 8Bit-MTA auszugeben, obwohl man die Wandlung nach 7bit nicht beherrscht ist wenigstens langfristig gesehen erfolgreich.
Das ist dasselbe wie "accept_8bitmime = true" in exim.
Richtig. Das ist nicht wirklich schön aber noch besser als ohne accept_8bitmime.
Wenn ich dir z.B. eine Mail mit Umlauten in iso-8859-1, encoding 8bit an email@twerner42.de schicke, wandelt mein sendmail hier auf der Kiste diese 8bit-Mail nach 7bit wenn er deinen Mailprovider kontaktiert. Bei Schlund gibts kein 8BITMIME - denen darf man also keine 8bit-Mails schicken.
Wenn kein 8BITMIME kommt ist Umwandlung nach 7bit neben einem permanenten Fehler die einzige erlaubte Variante. Sendmail behandelt das seit mindestens 5 Jahren korrekt. Würde ich mit exim an Schlund liefern, würde der exim die 8bit-Mail einfach an Schlund durchblasen. Das geht vermutlich gut, aber eben nur vermutlich. Ich bin daran interessiert, daß meine Mail ordentlich ankommt, nicht nur vermutlich ordentlich. Dazu habe ich keine Chance, wenn ich hier exim laufen hätte.
Wenn Schlunds MTA wirklich kein 8bit kann (und das behauptet er), würde meine Mail an dich Schrott werden, wenn ich hier mit exim arbeiten würde. Kann Schlunds MTA 8bit, sollte er es auch melden und mir somit die Umwandlung sparen. Aber vielleichst stehst du ja auf QP- oder base64-kodierte Textmails in deiner mbox. Ich mag sowas nicht sonderlich.
Mit bei mir reinkommenden Mails habe ich keine Probleme. Wenn bei mir solche sinnloserweise nach 7bit gewandelten Mails eintrudeln (der MTA vor meinem MTA ist ein exim ohne 8BITMIME) wandelt mein MTA die Mail noch fix zurück nach 8bit bevor er sie in die mbox wirft. Das nenne ich Qualität :-)
Reinhard
On Fri, Sep 27, 2002 at 12:37:58AM +0200, Reinhard Foerster wrote:
ich habe einen Mailserver mit Exim aufgesetzt. Ich versende gerne 8bit-Mails und empfange auch gern solche. Also habe ich im exim "accept_8bitmime = true" und verstoße damit gegen rfc1652. (Exim announced 8BITMIME auf ein EHLO und schickt 8bit-Mails ohne Umkodierung an MTAs weiter, die kein 8BITMIME melden.)
Nun habe ich aber einen MTA in der Nachbarschaft, mit dem ich ab und zu reden muß und der aus 8bit-Mails Schrott macht. Die Mails an diesen MTA würde ich gern nach Quoted-Printable wandeln, bevor ich sie weiterschicke. Hat jemand eine Idee, wie ich das mit Exim realisieren kann?
Ist das mal wieder der URZ-Mailserver? Warum kann man den verantwortlichen Leuten dort nicht mal was auf die Mütze geben? Das Problem existiert ja nicht erst seit heute. Wahrscheinlich muß erst jemand den sendmail dort mit Gewalt in die Knie zwingen (nein, das ist definitiv kein Aufruf dazu), damit mal was passiert, wie z.B. daß das alles mal ordentlich gemacht wird. *grusel*
Eric
On Sat, Sep 28, 2002 at 07:15:57PM +0200, Eric Schaefer wrote: ^^^^^^
Ist das schon wieder die Liste oder hat mein MTA einen Schluckauf?
Eric
lug-dd@mailman.schlittermann.de