exim4, Smarthosts und Retries
Peter Mairhofer
Ich mach mir da gerade Sorgen dass exim unter Umstaenden wortlos
Nachrichten nicht zustellt die dann aber abgehen :-(
Folgendes Szenario: Exim4 unter etch als MTA. Empfaengt teilweise direkt
per SMTP (MXen zeigen darauf), grossteils per fetchmail.
Gesendet wird ueber einen Smarthost. Normalerweise sollte es ja so sein,
falls der Smarthost nicht erreichbar ist, dass er die Nachrichten cached
und nacher verschickt.
Nun kommt es aber manchmal (selten) vor, wie gestern z.B., dass sich der
Rechner mit einer anderen IP (anderer ISP) einwaehlt und damit nicht zum
Smarthost verbinden darf.
Genau in diesem Zeitraum ist folgendes passiert:
- Benutzer haben E-Mails versendet, aber keinerlei Benachrichtigungen
behalten dass etwas schiefgegangen ist (im Glauben es sei alles gut
gelaufen)
- Exim4 wollte diese an den Smarthost schicken doch dieser antwortete
"553 sorry, relaying denied from your location".
- Exim4 hat die Mails darauf offenbar ge'frozen'd und in die Queue
geschickt.
Gut, ich meine intuitive Annahme war, dass wenn ich jetzt wieder
temporaer den Smarthost erreichbar mache, die Queue geleert wird und
alles ist in bester Ordnung.
Das hab ich gemacht, weder mailq noch runq taten irgendwas anderes als
lediglich die Queue auszugeben.
Ich will aber das die Mails weggehen!! (Dafuer sind sie ja da). Also
Holzhammermethode:
$ cd /var/spool/exim4/msglog
$ for i in *; do exim4 -M $i; done
Jetzt war endlich die Queue leer.
Aber das schlimme kommt erst: Ein paar Minuten spaeter kommt fuer jede
einzelne Nachricht ein Bounce vom Smarthost zurueck (Relaying denied from
your location, ...) vom Datum des Sendens der Nachricht.
1.) Sind die Mails nun angekommen oder nicht? (Hab zur Sicherheit alle
noch einmal verschickt)
2.) Wie kann ich exim4 die Queue verschicken lassen (auch frozen
messages, wie hier)?
3.) Stellt exim4 garantiert immer alle Nachrichten zu? Ich befuerchte
nicht, denn in meinem alten exim3 Verzeichnis befinden sich noch immer
tausende frozen messages, die nie mehr losgschickt wurden nur weil einmal
ein Fehler aufgetreten ist.
4.) Gibt es eine Konfiguration die das ganze transparent fuer User macht?
D.h. wenn der Smarthost entweder nicht erreichbar ist oder sonst abweist
(z.B. relaying denied from your location) dann soll es exim4 jede Stunde
wieder versuchen, der Originalbenutzer soll dabei jedoch keinen Bounce
bekommen.
Vielen Dank,
Peter
PS: Ich hab die Standardkonfiguration von Debian etch am Laufen
Thomas Hochstein
> Genau in diesem Zeitraum ist folgendes passiert:
>
> - Benutzer haben E-Mails versendet, aber keinerlei Benachrichtigungen
> behalten dass etwas schiefgegangen ist (im Glauben es sei alles gut
> gelaufen)
Das ist nicht die ganze Wahrheit, möchte ich meinen - siehe unten.
> - Exim4 wollte diese an den Smarthost schicken doch dieser antwortete
> "553 sorry, relaying denied from your location".
Also muß Exim Bounces generieren. Das tut er auch, und versucht dann
die Bounces an die Absenderadressen der ursprünglichen Mails
auszuliefern. Das wird vermutlich, wenn die nicht lokal sind, auch
nicht gehen, weil er dafür ja wieder den Smarthost braucht.
> - Exim4 hat die Mails darauf offenbar ge'frozen'd und in die Queue
> geschickt.
Nein, nicht die Mails, die Bounces, d.h. die
Unzustellbarkeitsnachrichten, möchte ich doch ganz stark annehmen.
(Genau sagen kann man das nicht, weil Du uns ja nur Deine Vermutungen,
aber keine Logauszüge usw. mitteilst. Unzustellbare Mails werden aber
nicht eingefroren, sondern gebounced, es sei denn, diese Mails *sind*
schon Bounces.)
> Gut, ich meine intuitive Annahme war, dass wenn ich jetzt wieder
> temporaer den Smarthost erreichbar mache, die Queue geleert wird und
> alles ist in bester Ordnung.
Jein. Dann gehen halt die Unzustellbarkeitsbenachrichtigungen der
ursprünglichen Mails raus, aber natürlich erst dann, wenn sie
"aufgetaut" wurden. "Eingefrorene" Mails faßt Exim idR nicht mehr an,
weil es da einen nicht mehr behebbares Problem gegeben hat.
> Das hab ich gemacht, weder mailq noch runq taten irgendwas anderes als
> lediglich die Queue auszugeben.
mailq *soll* die Queue anzeigen. "runq" sollte einen Queue-Run
anstoßen - aber jedenfalls mußt Du "eingefrorene Mails" Mails vorher
auftauen oder den Queuerun mit "-qff" starten. "exim4 -qff" wäre also
geboten gewesen.
> Aber das schlimme kommt erst: Ein paar Minuten spaeter kommt fuer jede
> einzelne Nachricht ein Bounce vom Smarthost zurueck (Relaying denied from
> your location, ...) vom Datum des Sendens der Nachricht.
Das nehme ich eher nicht an. Das dürften vielmehr die Bounces gewesen
sein, die Dein Exim (!) generiert hatte und jetzt endlich losgeworden
ist.
> 1.) Sind die Mails nun angekommen oder nicht?
Wohl kaum. Du schriebst doch am Anfang, sie konnten nicht versandt
werden:
| - Exim4 wollte diese an den Smarthost schicken doch dieser antwortete
| "553 sorry, relaying denied from your location".
Wenn sie nicht versandt werden konnten, können sie auch nicht
ankommen...
> 2.) Wie kann ich exim4 die Queue verschicken lassen (auch frozen
> messages, wie hier)?
exim4 -qff
> 3.) Stellt exim4 garantiert immer alle Nachrichten zu?
Wenn das geht, ja. Wenn es nicht geht, bouncet er sie. Wenn er den
*Bounce* nicht loswird, dann kann er ja nun nichts mehr machen, weil
den wieder bouncen geht nicht. *Dann* wird die Nachricht eingefroren.
> Ich befuerchte
> nicht, denn in meinem alten exim3 Verzeichnis befinden sich noch immer
> tausende frozen messages, die nie mehr losgschickt wurden nur weil einmal
> ein Fehler aufgetreten ist.
Du solltest einen Mailserver besser überwachen, wenn Du ihn schon
betreibst... Ggf. kannst Du Dir Kopien der Bounces an eine lokal
vorhandene Adresse schicken lassen (errors_copy), siehe dazu
<http://www.exim.org/exim-html-4.67/doc/html/spec_html/ch14.html#SECID117>.
> 4.) Gibt es eine Konfiguration die das ganze transparent fuer User macht?
> D.h. wenn der Smarthost entweder nicht erreichbar ist oder sonst abweist
> (z.B. relaying denied from your location) dann soll es exim4 jede Stunde
> wieder versuchen,
Das tut Exim nur bei *temporären* Fehlern, nicht bei endgültigen
Fehlern. Und es wäre auch nicht gut, wenn Exim eine definitiv nicht
zustellbare Mail tagelang wieder zuzustellen versucht - denn dann will
der Benutzer ja baldmöglichst wissen, daß sie nicht zustellbar ist.
Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
beheben, daß die Verbindung zum Smarthost nur unzuverlässig
funktioniert.
> PS: Ich hab die Standardkonfiguration von Debian etch am Laufen
Du solltest dann vielleicht auch einmal die - bei Exim hervorragende!
- Standarddokumentation lesen. :) Und beachte bitte, daß die
Exim-Config bei Debian vom Normalfall sehr stark abweicht; das steht
aber auch alles in der Debian-Doku.
-thh
--
Informationsschnipsel rund um Mail und Mailserver:
<http://th-h.de/infos/email/>
Peter Mairhofer
> Peter Mairhofer schrieb:
> [...]
>
> Das ist nicht die ganze Wahrheit, möchte ich meinen - siehe unten.
>
>> - Exim4 wollte diese an den Smarthost schicken doch dieser antwortete
>> "553 sorry, relaying denied from your location".
>
> Also muß Exim Bounces generieren. Das tut er auch, und versucht dann
> die Bounces an die Absenderadressen der ursprünglichen Mails
> auszuliefern. Das wird vermutlich, wenn die nicht lokal sind, auch
> nicht gehen, weil er dafür ja wieder den Smarthost braucht.
Danke fuer deine ausfuehrliche Antwort! Jetzt ist mir viel klarer
geworden, vor allem was der Unterschied zwischen "frozen" Mails ist und
die in der normalen Queue.
Wenn ich mir das so durchueberlege duerte es genau so sein wie du hier
erzaehlt hast! Das waren tatsaechlich nur die Bounces, ich hab mich noch
gewundert warum in der mainlog beim queuerun als Ziel immer die
Absenderadresse drin war ;-)
Das bedeutet ich muss exim irgendwie sagen, dass er nicht bouncen soll
wenn er vom Smarthost eine 553 Nachricht bekommt, sondern diese in die
Queue geben soll und diese auch nicht einfrieren soll.
Ist das einfach moeglich? Ich meine damit, dass er /nur/ dann nicht
bouncen soll wenn nicht ueber den Smarthost verschickt werden kann.
>> - Exim4 hat die Mails darauf offenbar ge'frozen'd und in die Queue
>> geschickt.
>
> Nein, nicht die Mails, die Bounces, d.h. die
> Unzustellbarkeitsnachrichten, möchte ich doch ganz stark annehmen.
> (Genau sagen kann man das nicht, weil Du uns ja nur Deine Vermutungen,
> aber keine Logauszüge usw. mitteilst. Unzustellbare Mails werden aber
> nicht eingefroren, sondern gebounced, es sei denn, diese Mails *sind*
> schon Bounces.)
Das erklaert wiederum auch warum alle frozen Mails i.d.R. bounces sind
die ich fand ;-)
>> Das hab ich gemacht, weder mailq noch runq taten irgendwas anderes
>> als lediglich die Queue auszugeben.
>
> mailq *soll* die Queue anzeigen. "runq" sollte einen Queue-Run
> anstoßen - aber jedenfalls mußt Du "eingefrorene Mails" Mails vorher
> auftauen oder den Queuerun mit "-qff" starten. "exim4 -qff" wäre also
> geboten gewesen.
Und das erklaert warum die Queue immer voll blieb :-)
>> 4.) Gibt es eine Konfiguration die das ganze transparent fuer User
>> macht? D.h. wenn der Smarthost entweder nicht erreichbar ist oder
>> sonst abweist (z.B. relaying denied from your location) dann soll es
>> exim4 jede Stunde wieder versuchen,
>
> Das tut Exim nur bei *temporären* Fehlern, nicht bei endgültigen
> Fehlern. Und es wäre auch nicht gut, wenn Exim eine definitiv nicht
> zustellbare Mail tagelang wieder zuzustellen versucht - denn dann will
> der Benutzer ja baldmöglichst wissen, daß sie nicht zustellbar ist.
>
> Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
> beheben, daß die Verbindung zum Smarthost nur unzuverlässig
> funktioniert.
Hmm das stimmt auch wieder. Schwer :-(
Das Problem ist, dass der Rechner mit einem ISP mit Transferlimit
verbunden ist. Geht dieses aus, biege ich einfach die defaultroute um und
verwende einen anderen Router der ins Internet geht.
Danach akzeptiert der Smarthost des ersten ISP natuerlich kein Relaying
mehr da der Request von der falschen IP-Range kommt.
Umgekehrt das gleiche.
Eine Alternative waere zu obigen Vorschlag (nicht Messages nicht zu
bouncen) waeren vermutlich mehrer kaskadierte Smarthosts.
Wuerde exim, wenn ich ihm mehrere Smarthosts gebe, die nacheinander
abarbeiten, auch wenn beim ersten eine Relaying-Denied Meldung kommt?
Dann wuerde ich nehmen:
1.) mail.isp1.net (fuer normal)
2.) mail.isp2.net (wenn Transferlimit aus ist und mail.isp1.net 553
schickt)
3.) mailgate.company.net Als Fallbackmethode einen SMTP Server von Uni,
Firma, GMX (was auch immer) mit Auth, der dafuer von ueberall verbinden
kann.
Wenn das Netzwerk down ist (i.e. ein Server nicht erreichbar ist) wird ja
sowieso gequeued so wie ich das mitbekommen habe.
mfg,
Peter
Peter Mairhofer
> Thomas Hochstein <t...@inter.net> dixit:
> [...]
>
> Eine Alternative waere zu obigen Vorschlag (nicht Messages nicht zu
> bouncen) waeren vermutlich mehrer kaskadierte Smarthosts.
>
> Wuerde exim, wenn ich ihm mehrere Smarthosts gebe, die nacheinander
> abarbeiten, auch wenn beim ersten eine Relaying-Denied Meldung kommt?
>
> Dann wuerde ich nehmen:
> 1.) mail.isp1.net (fuer normal)
> 2.) mail.isp2.net (wenn Transferlimit aus ist und mail.isp1.net 553
> schickt)
> 3.) mailgate.company.net Als Fallbackmethode einen SMTP Server von
> Uni, Firma, GMX (was auch immer) mit Auth, der dafuer von ueberall
> verbinden kann.
Ok, das hab ich probiert und hab folgendes Problem: Das ganze geht gut wenn
mail.isp1.net nicht erreichbar ist. Dann steckt das Mail ein bisschen in
der Queue und nach ein paar Minuten findet sich im Log "mail.isp1.net
Connection timed out" und direkt danach wird ueber den zweiten Smarthost
geschickt.
Es funktioniert aber *nicht* wenn mail.isp1.net abweist (Relaying denied).
Im Internet hab ich tonnenweise Infos zu GMX, Web.de & Co Providern
gefunden mit denen man exim dazu bewegen kann den Smarthost anhand der
Absenderadresse zu waehlen. Auch anhand der Auth-Info.
Gibt es ueberhaupt diese gewuenschte Moeglichkeit?
mfg,
Peter
Joerg Hoh
>
> Das bedeutet ich muss exim irgendwie sagen, dass er nicht bouncen soll
> wenn er vom Smarthost eine 553 Nachricht bekommt, sondern diese in die
> Queue geben soll und diese auch nicht einfrieren soll.
>
> Ist das einfach moeglich? Ich meine damit, dass er /nur/ dann nicht
> bouncen soll wenn nicht ueber den Smarthost verschickt werden kann.
Ein SMTP-Fehlercode "553" ist ein permanenter Fehler. D.h das ganze
erneut zu versuchen wiederspricht eigentlich dem RFC.
An deiner Stelle würde ich das Relaying nicht abhängig von der IP
machen, sondern lieber über smtp auth lösen.
Gruß
Jörg
--
What did you do to the cat? It looks half-dead. -Schroedinger's wife
Peter Mairhofer
> Peter Mairhofer schrieb
>>
>> Das bedeutet ich muss exim irgendwie sagen, dass er nicht bouncen soll
>> wenn er vom Smarthost eine 553 Nachricht bekommt, sondern diese in die
>> Queue geben soll und diese auch nicht einfrieren soll.
>>
>> Ist das einfach moeglich? Ich meine damit, dass er /nur/ dann nicht
>> bouncen soll wenn nicht ueber den Smarthost verschickt werden kann.
>
> Ein SMTP-Fehlercode "553" ist ein permanenter Fehler. D.h das ganze
> erneut zu versuchen wiederspricht eigentlich dem RFC.
>
> An deiner Stelle würde ich das Relaying nicht abhängig von der IP
> machen, sondern lieber über smtp auth lösen.
Ich habs befuerchtet :-(
Aber das Problem ist ja, dass der SMTP Server des ISPs keine
Authentifizierung erlaubt sondern nur von seiner eigenen Range relayen
laesst. Habs bereits probiert.
Da bleibt mir gar nichts anderes uebrig.
Nun habe ich eine temporaere "Loesung" gefunden: Einfach beide ISPs als
Smarthost rein.
Stelle ich das Defaultgateway um, so trag ich in die /etc/hosts ein:
192.168.254.1 email.aon.at
Sag' bloss dass das der elegantere Weg ist als (zu privaten Zwecken) eine
RFC zu ignorieren...
mfg,
Peter
PS: Wie oben ersichtlich ist der primaere ISP A-Online (mit email.aon.at).
Der zweite ISP ist Inode mit smtp.inode.at. Das hier beschriebene Szenario
tritt an vielleicht 1-2 Tagen im Monat auf, wenn ueberhaupt.
Thomas Hochstein
> Das bedeutet ich muss exim irgendwie sagen, dass er nicht bouncen soll
> wenn er vom Smarthost eine 553 Nachricht bekommt, sondern diese in die
> Queue geben soll und diese auch nicht einfrieren soll.
Keine gute Idee, meines Erachtens. 5xx ist ein permanenter Fehler, und
wenn man einmal mit "unsauberen" Lösungen jenseits etablierter
Standards anfängt, wird man irgendwann davon ganz übel in den Hintern
gebissen - jedenfalls meiner Erfahrung nach. :)
> Ist das einfach moeglich? Ich meine damit, dass er /nur/ dann nicht
> bouncen soll wenn nicht ueber den Smarthost verschickt werden kann.
Ich meine mich zu erinnern, daß man Exim beibringen kann, permanente
Fehlercodes nicht als permanent zu behandeln; man dürfte das aber
wohl kaum nur auf diesen einen Fehlerfall beschränken können.
>> Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
>> beheben, daß die Verbindung zum Smarthost nur unzuverlässig
>> funktioniert.
>
> Hmm das stimmt auch wieder. Schwer :-(
Die einfachste Lösung wäre die Verwendung eines Smarthosts, der Dir
unabhängig von der IP den Versand via SMTP-Auth erlaubt (und, wichtige
Einschränkung, dabei jede beliebige Adresse im Absender und im
Envelope-From erlaubt; das tun viele Freemailer nicht). Dann wärest Du
nicht an Deinen Einwahlprovider gebunden, sondern könntest einfach
immer über denselben Smarthost versenden.
Ich würde einfach mal nach solchen Anbietern suchen; ob es da
zuverlässige *und* kostenlose gibt, mag ich nicht beschwören.
> Das Problem ist, dass der Rechner mit einem ISP mit Transferlimit
> verbunden ist. Geht dieses aus, biege ich einfach die defaultroute um und
> verwende einen anderen Router der ins Internet geht.
Wenn Du feststellen kannst, über welche Route Du online bist, dann
könntest Du m.E. den Smarthost einfach abhängig davon setzen. Wenn Du
die Route eh manuell anlegst, könntest Du bspw. auch einfach eine
Datei anlegen oder löschen, je nachdem, welcher Smarthost aktuell ist,
oder den Smarthost aus einer Datei (oder Datenbank, ...) auslesen
lassen.
Dort, wo der Smarthost gesetzt wird (in der Regel ein Router mit einem
Eintrag der Art
| route_list= "* smarthost.provider.example"
), würdest Du Dir dann einen Ausdruck bauen, der den Smarthost aus
einer Datei ausliest. (Sorry, ich muß mir selbst immer erst wieder die
Syntax anlesen, sonst würde ich direkt ein Beispiel bilden. Vielleicht
kann ja einer der anderen Mitleser, die fließender als ich Exim
sprechen, hilfreich einspringen?)
> Eine Alternative waere zu obigen Vorschlag (nicht Messages nicht zu
> bouncen) waeren vermutlich mehrer kaskadierte Smarthosts.
Nein, denn ...
> Wuerde exim, wenn ich ihm mehrere Smarthosts gebe, die nacheinander
> abarbeiten, auch wenn beim ersten eine Relaying-Denied Meldung kommt?
... Exim versucht es nur bei einem *temporären* Fehler erneut.
Eigentlich gilt eben, daß eine Mail, die endgültig abgelehnt wird,
auch endgültig unzustellbar ist.
> Wenn das Netzwerk down ist (i.e. ein Server nicht erreichbar ist) wird ja
> sowieso gequeued so wie ich das mitbekommen habe.
Yep.
Thomas Hochstein
> Es funktioniert aber *nicht* wenn mail.isp1.net abweist (Relaying denied).
Genau.
> Im Internet hab ich tonnenweise Infos zu GMX, Web.de & Co Providern
> gefunden mit denen man exim dazu bewegen kann den Smarthost anhand der
> Absenderadresse zu waehlen. Auch anhand der Auth-Info.
Aber das hilft Dir ja nicht, soweit ich sehe ...
> Gibt es ueberhaupt diese gewuenschte Moeglichkeit?
Wenn Du Exim irgendwie feststellen lassen kannst, welcher Smarthost
jetzt gerade der richtige ist, könntest Du den einfach passend setzen
lassen, ja. Siehe dazu mein anderes Posting,
<dcsm.07043...@windlord.akallabeth.de>.
Grüße,
Nils Ketelsen
>>> Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
>>> beheben, daß die Verbindung zum Smarthost nur unzuverlässig
>>> funktioniert.
>> Hmm das stimmt auch wieder. Schwer :-(
> Die einfachste Lösung wäre die Verwendung eines Smarthosts, der Dir
> unabhängig von der IP den Versand via SMTP-Auth erlaubt (und, wichtige
> Einschränkung, dabei jede beliebige Adresse im Absender und im
> Envelope-From erlaubt; das tun viele Freemailer nicht). Dann wärest Du
> nicht an Deinen Einwahlprovider gebunden, sondern könntest einfach
> immer über denselben Smarthost versenden.
Noch einfacher wäre eigentlich die Verwendung keines Smarthosts.
Nils
--
Wahre Worte gelassen ausgesprochen (2):
"The farther you get away from water, the dumber the people get."
[aus einer Diskussion, warum so viele Leute in Kuestenregionen
leben]
Paul Muster
> Noch einfacher wäre eigentlich die Verwendung keines Smarthosts.
Diverse hysterische Antispammaßnahmen (Bindestriche bedarfsweise bitte
selbst setzen: --) machen das zu einem wenig lustigen Spiel.
mfG Paul
Clemens Zauner
> Aber das Problem ist ja, dass der SMTP Server des ISPs keine
> Authentifizierung erlaubt sondern nur von seiner eigenen Range relayen
> laesst. Habs bereits probiert.
Sicher? Alle beide?
> PS: Wie oben ersichtlich ist der primaere ISP A-Online (mit email.aon.at).
> Der zweite ISP ist Inode mit smtp.inode.at. Das hier beschriebene Szenario
> tritt an vielleicht 1-2 Tagen im Monat auf, wenn ueberhaupt.
Zumindes der Mailserver von INode kann AUTH. Nimm also im Zweifelsfall
einfach den als Haupt-Smarthost. Oder such dir einen anständigen ISP.
Oder schnorr dir irgendwo ein zuverlässiges Relay.
cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS
Nils Ketelsen
Hm? Ich bin in der Lage zu akzeptieren, wenn mein Kommunikationspartner für
sich entschieden hat eine Mail nicht anzunehmen. Halte ich nicht für
sonderlich störend. Wenn er wieder Mails haben will wird er das schon selber
ändern.
Nils
--
I cannot prove that electrons exist, but I believe fervently in their
existence. And if you don't believe in them, I have a high voltage cattle
prod I'm willing to apply as an argument on their behalf. Electrons speak
for themselves. [Seth Lloyd, Quantum Mechanical Engineer]
Paul Muster
>>> Noch einfacher wäre eigentlich die Verwendung keines Smarthosts.
>> Diverse hysterische Antispammaßnahmen (Bindestriche bedarfsweise bitte
>> selbst setzen: --) machen das zu einem wenig lustigen Spiel.
>
> Hm? Ich bin in der Lage zu akzeptieren, wenn mein Kommunikationspartner für
> sich entschieden hat eine Mail nicht anzunehmen. Halte ich nicht für
> sonderlich störend. Wenn er wieder Mails haben will wird er das schon selber
> ändern.
Erklärst du das bitte den Kunden von United Internet (1und1, GMX, web.de
etc.), T-Online, AOL etc.?
Danke!
mfG Paul
Peter Mairhofer
> Thomas Hochstein <t...@inter.net> wrote:
>
>>>> Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
>>>> beheben, daß die Verbindung zum Smarthost nur unzuverlässig
>>>> funktioniert.
>>> Hmm das stimmt auch wieder. Schwer :-(
>> Die einfachste Lösung wäre die Verwendung eines Smarthosts, der Dir
>> unabhängig von der IP den Versand via SMTP-Auth erlaubt (und, wichtige
>> Einschränkung, dabei jede beliebige Adresse im Absender und im
>> Envelope-From erlaubt; das tun viele Freemailer nicht). Dann wärest Du
>> nicht an Deinen Einwahlprovider gebunden, sondern könntest einfach
>> immer über denselben Smarthost versenden.
>
> Noch einfacher wäre eigentlich die Verwendung keines Smarthosts.
Ja, sowie ich das frueher auch hatte.
Der Vorschlag ist heute aber aufgrund von diversen Spammassnahmen nicht
mehr zeitgemaess.
Achja, wenn man einen Businnesszugang hat nicht so ein Problem ich hab aber
einen privaten mit dynamischer IP.
mfg,
Peter
Peter Mairhofer
> Peter Mairhofer <6383...@gmx.net> wrote:
>> Aber das Problem ist ja, dass der SMTP Server des ISPs keine
>> Authentifizierung erlaubt sondern nur von seiner eigenen Range
>> relayen laesst. Habs bereits probiert.
>
> Sicher? Alle beide?
Hab nur bei AON geschaut weil der eben der ist um dens geht.,
>> PS: Wie oben ersichtlich ist der primaere ISP A-Online (mit
>> email.aon.at). Der zweite ISP ist Inode mit smtp.inode.at. Das hier
>> beschriebene Szenario tritt an vielleicht 1-2 Tagen im Monat auf,
>> wenn ueberhaupt.
>
> Zumindes der Mailserver von INode kann AUTH. Nimm also im Zweifelsfall
> einfach den als Haupt-Smarthost. Oder such dir einen anständigen ISP.
> Oder schnorr dir irgendwo ein zuverlässiges Relay.
1.) Na wenigstens was. Bringt mir aber leider nicht so viel in diesem Fall,
umgekehrt waers toll!
2.) Das geht eben nicht weil ich eben im Normalfall nicht mit inode
verbunden bin und auch nicht die Zugangsdaten davon habe.
3.) Anstaendiger ISP waere schon lange faellig aber ich will mein ISDN samt
AON-Complete nicht loswerden
4.) Ich koennte eventuell das von der Uni nehmen. Da muss ich allerdings
erst nachsehen ob der tatsaechlich alle Absender akzeptiert. Generell
wuerde ich das aber eher vermeiden denn der Server ist mir etwas zu
restriktiv.
5.) Ich bleib' mein meiner "eleganten" Methode und lass email.aon.at
einfach auf eine ungueltige IP aufloesen *wuerg*.
mfg,
Peter
Thomas Hochstein
> Noch einfacher wäre eigentlich die Verwendung keines Smarthosts.
Für Nutzer von IP-Adressen aus Dialup-Bereichen ist das aufgrund von
empfängerseitiger Filterung idR nicht mehr praktikabel.
-thh
Peter Mairhofer
> Peter Mairhofer schrieb:
>
>> Das bedeutet ich muss exim irgendwie sagen, dass er nicht bouncen
>> soll wenn er vom Smarthost eine 553 Nachricht bekommt, sondern diese
>> in die Queue geben soll und diese auch nicht einfrieren soll.
>
> Keine gute Idee, meines Erachtens. 5xx ist ein permanenter Fehler, und
> wenn man einmal mit "unsauberen" Lösungen jenseits etablierter
> Standards anfängt, wird man irgendwann davon ganz übel in den Hintern
> gebissen - jedenfalls meiner Erfahrung nach. :)
Das stimmt wohl :-)
>> Ist das einfach moeglich? Ich meine damit, dass er /nur/ dann nicht
>> bouncen soll wenn nicht ueber den Smarthost verschickt werden kann.
>
> Ich meine mich zu erinnern, daß man Exim beibringen kann, permanente
> Fehlercodes nicht als permanent zu behandeln; man dürfte das aber
> wohl kaum nur auf diesen einen Fehlerfall beschränken können.
Ja, das waere aber natuerlich wichtig.
>>> Du solltest nicht an den Symptomen herumdoktern, sondern das Problem
>>> beheben, daß die Verbindung zum Smarthost nur unzuverlässig
>>> funktioniert.
>>
>> Hmm das stimmt auch wieder. Schwer :-(
>
> Die einfachste Lösung wäre die Verwendung eines Smarthosts, der Dir
> unabhängig von der IP den Versand via SMTP-Auth erlaubt (und, wichtige
> Einschränkung, dabei jede beliebige Adresse im Absender und im
> Envelope-From erlaubt; das tun viele Freemailer nicht). Dann wärest Du
> nicht an Deinen Einwahlprovider gebunden, sondern könntest einfach
> immer über denselben Smarthost versenden.
Wie ich im anderen Posting bereits erwahnt hab, ich werd einmal schauen
ob ich entweder tatsaechlich den von inode verwenden kann oder den von
der Uni.
Den von der Uni moechte ich soweit wie moeglich vermeiden.
>> Das Problem ist, dass der Rechner mit einem ISP mit Transferlimit
>> verbunden ist. Geht dieses aus, biege ich einfach die defaultroute um
>> und verwende einen anderen Router der ins Internet geht.
>
> Wenn Du feststellen kannst, über welche Route Du online bist, dann
> könntest Du m.E. den Smarthost einfach abhängig davon setzen. Wenn Du
> die Route eh manuell anlegst, könntest Du bspw. auch einfach eine
> Datei anlegen oder löschen, je nachdem, welcher Smarthost aktuell ist,
> oder den Smarthost aus einer Datei (oder Datenbank, ...) auslesen
> lassen.
Stimmt, das waere fast die elegantere Loesung...
> Dort, wo der Smarthost gesetzt wird (in der Regel ein Router mit einem
> Eintrag der Art
>| route_list= "* smarthost.provider.example"
> ), würdest Du Dir dann einen Ausdruck bauen, der den Smarthost aus
> einer Datei ausliest. (Sorry, ich muß mir selbst immer erst wieder die
> Syntax anlesen, sonst würde ich direkt ein Beispiel bilden. Vielleicht
> kann ja einer der anderen Mitleser, die fließender als ich Exim
> sprechen, hilfreich einspringen?)
Das schaff ich dann selbst - danke ;-)
mfg,
Peter
Nils Ketelsen
Als Sender sollte man sich aber nicht die Probleme der Empfänger zu eigen
machen.
Nils
--
This message will self-destruct after the default expiration-time.
Jakob Hirsch
> 5.) Ich bleib' mein meiner "eleganten" Methode und lass email.aon.at
> einfach auf eine ungueltige IP aufloesen *wuerg*.
Wenn du dich sowieso mit PPP über den Exim-Rechner einwählst, kannst du
den smarthost auch automatisch per /etc/ppp/ip-up(.local) ändern (Linux,
andere Systeme dürften was ähnliches haben), indem du den smarthost in
eine Datei schreiben läßt und diese in der exim-config benutzt, z.B. mit
route_data = ${readfile{CFGDIR/smarthost}}.
Ansonsten kann man sich ja auch bei diversen Anbietern per Tunnel eine
feste IP holen oder sich einen VServer für kleines Geld mieten.
Thomas Hochstein
> Stimmt, das waere fast die elegantere Loesung...
Kann man dann ja auch scripten, zusammen mit dem Umsetzen der Route...
Marc Haber
>Und beachte bitte, daß die
>Exim-Config bei Debian vom Normalfall sehr stark abweicht;
I beg to differ. Es gibt Detailunterschiede, die Funktionsweise ist
bis hin zur Reihenfolge von Routern und ACL-Einträgen sehr ähnlich.
>das steht
>aber auch alles in der Debian-Doku.
Das stimmt.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834