SMTP und A1

[lordpeng]

da magst du wohl recht haben, aber ausser dem bequemlichkeitsfaktor sehe ich keinen grund dies so zu handhaben, eher im gegenteil, es gibt genug mailserver, deren spamfilter nachrichten die über domain-fremde server relayed werden, grundsätzlich schlechter einstufen - und da man fremde mailserver nunmal schlecht kontrollieren kann, ists sicherlich kein fehler die mails über einen für die domain zuständigen server auszuliefern ...

[jutta]

ich hab ja nicht behauptet, dass es ein fehler ist. bloss, dass es in der praxis manchmal umstaendlich ist. und: auf den mailserver meiner domain hab ich nicht mehr einfluss als auf den mailserver meines access-providers. ich kann im einen und im anderen fall nur den support um hilfe bitten.

//ps und slightly offtopic: ein mailzustellproblem, das mir in der letzten zeit zweimal untergekommen ist, bestand deshalb, weil der verhinderte empfaenger seine domain frueher bei inode/upc hatte und von dort wegmigriert hat, ohne dem support zu sagen, was mit seinen mailboxen ist. automatisch geloescht werden sie auch nicht oder jedenfalls erst nach sehr langer zeit. der inode-smtp weiss also von nix und stellt alle mails an diese empfaenger brav in die alten lokalen mailboxen zu.

[lordpeng]

>ich kann im einen und im anderen fall nur den support um hilfe bitten
eigentlich mein ich den empfänger-mailserver nicht den über den du auslieferst ... und da man idR mehr als einen kommunikationspartner hat wirds nicht möglich sein, mit jedem mailserverbetreiber in kontakt zu treten, wenn mal ein mail ned ankommt ... (das wird dann dem hosting- als auch dem access-provider nämlich ziemlich wurscht sein)

[jutta]

du wirst lachen: ich hab bei den mail-admins der empfaenger oft mehr erfolg aber jetzt wird es wirklich offtopic. rest per mail.

[lordpeng]

>//ps und slightly offtopic: ein mailzustellproblem, das mir in der letzten zeit zweimal untergekommen ist, bestand
>deshalb, weil der verhinderte empfaenger seine domain frueher bei inode/upc hatte und von dort wegmigriert hat, ohne
>dem support zu sagen

ja, das problem tritt häufiger auf - providerübergreifend, es ist leider ziemlich nervig, dabei wärs aus providersicht eigentlich gut machbar via script zu prüfen ob noch der eigene server für die eingetragenen domains zuständig ist oder der MX eintrag wo anders hinzeigt und dann eine liste mit weg gezogenen domains auswirft die entweder wiederum automatisiert oder händisch kontrolliert/abgearbeitet wird ...

[jutta]

ergaenzung fuer mitlesende, die dieses problem noch nicht selbst erlebt haben: das fiese daran ist, dass der absender keine fehlermeldung bekommt, da das mail aus sicht des smtp ja korrekt zugestellt wurde. erst wenn der absender sich wundert, dass der empfaenger nicht antwortet und ueber andere wege dort anfragt, faellt es vielleicht auf, dass mails "verschwunden" sind.

[lordpeng]

wenn mans genau nimmt, is das ein grund mehr, den SMTP server des domainhosters zu verwenden

wen du zuerst deine domain beim accessprovider hattest diese dann aber zu einem anderen anbieter transferierst, beim accessprovider diese aber ned löschen lässt, dann hast im grunde das gleiche in blau ... es is ja ned so, dass dies ein seltenes szenario ist, im gegenteil es kommt sogar durchaus häufig vor, dass kunden die domain beim accessprovider dazu nehmen irgendwann aber höhere anforderungen haben und sich dann was bei einem webhoster nehmen ...

[jutta]

den smtp von welchem domain-hoster jetzt? dem vom empfaenger oder den von meinem. das problem besteht ja auf empfaengerseite. und es wird immer dann virulent, wenn der absender zufaellig den frueher fuer die mails des empfaengers zustaendig gewesenen smtp verwendet.

konkretes beispiel:

ich wollte mails mit dem absender ju at netzwerklabor.at an markus at oberleitner biz versenden. smtp ist der von inode.at, weil netzwerklabor.at dort gehostet ist. die mails kamen nicht an, weil sie in die alte mailbox von markus geschickt wurden, von deren existenz (von einem fruehren business-produkt, das er lang nicht mehr hatte) er nichts ahnte.

in dem konkreten fall war es besonders dubios, denn da hat es jahrelang funktioniert. ich hab also den eindruck, dass erst im zusammenhang mit dem wechsel auf sein neues kabel-businessprodukt im fruehjahr die alten einstellungen reaktiviert worden sind.

in der fa haben wir zb das problem, dass wir mails aus dem aktenverwaltungssystem heraus nur via access-provider versenden koennen, da das dumme ding kein smtp-auth kann. und solche dumme dinger wirst du wahrscheinlich mehr kennen (div. firewalls, nas usw, die einem admin berichte und fehlermeldungen zustellen sollen)

[wicked_one]

konkretes beispiel:

ich wollte mails mit dem absender ju at netzwerklabor.at an markus at oberleitner biz versenden. smtp ist der von inode.at, weil netzwerklabor.at dort gehostet ist. die mails kamen nicht an, weil sie in die alte mailbox von markus geschickt wurden, von deren existenz (von einem fruehren business-produkt, das er lang nicht mehr hatte) er nichts ahnte.

Das hat dann aber nichts mit der Philosophie, welcher SMTP zu verwenden ist zu tun, sondern schlicht mit Schlampigkeit des Providers...

[lordpeng]

>den smtp von welchem domain-hoster jetzt? dem vom empfaenger oder den von meinem.
>das problem besteht ja auf empfaengerseite.
stimmt, das problem besteht auf empfängerseite, nur wenn ich jetzt von einem kleinen betrieb mit hausnummer 5 mitarbeitern ausgehe, welche mails hin und her schicken, dann hab ich das problem schon quasi firmenintern ...

natürlich löst das nicht das problem, dass der eintrag providerseitig bereinigt werden muss, aber es kann für technisch weniger versierte anwender bzw. halbwissende durchaus hilfreich sein, den korrekten mailserver zu verwenden ...

[jutta]

> Das hat dann aber nichts mit der Philosophie, welcher SMTP zu verwenden ist zu tun, sondern schlicht mit Schlampigkeit des Providers...

da geb ich dir schon recht, aber nicht jeder provider war im frueheren leben ein amt mit ensprechend buerokratisch organisierten perfekten ablaeufen (siehe auch die bemerkung von lordpeng, dass das provideruebergreifend vorkommt)

so nebenbei: die aon-mailbox zu unserem 2003 gekuendigten adsl-anschluss existiert auch noch immer. forward kann aber keines eingerichtet werden, weil es das account dazu nimmer gibt. wenn du also jemanden kennst, der bei der ta fuers loeschen von mailboxen zustaendig ist, bin ich fuer einen hint dankbar

[local.host]

>ich halte es für eine Unsitte exklusiv über den Hoster die Mails zu relayen
... weil?

ich finde sinnvoller über das netz jenes anbieters zu verschicken, wo auch die domain läuft ...

... und dann das Mail sinnloserweise in ein anderes Netz zu senden wo selten auch das finale Ziel ist, also das auch wieder aus dem anderen Netz rus muss ... wieder in ein anderes Netz rein ...

aber ich bin vmtl. zu alt für den schei** ... die Leute sollen tun was sie wollen ... Aufklärungsarbeit wird zu schlecht bezahlt.


ausserdem: zum Punkt Spambewertung: als ob da dann bei den Hostern in aller Regel auch noch der Hostname richtig drinnen steht und dann agr auch noch der PTR matcht ... *pfah*

[lordpeng]

>... und dann das Mail sinnloserweise in ein anderes Netz zu senden wo selten auch das finale Ziel ist,
>also das auch wieder aus dem anderen Netz rus muss ... wieder in ein anderes Netz rein ...
ich hab schon vermutet, dass die antwort in diese richtung geht - aus ökonomischer sicht, war dies vielleicht auch mal ein durchaus zu berücksichtigendes kriterium - aber IMHO kann man das aufgrund der heute verfügbaren bandbreiten wohl eher vernachlässigen

aus anwendersicht isses sowieso egal was dahinter abläuft, hauptsache ist das ganze funktioniert ohne einschränkungen ...

>ausserdem: zum Punkt Spambewertung: als ob da dann bei den Hostern in aller Regel
>auch noch der Hostname richtig drinnen steht und dann agr auch noch der PTR matcht ... *pfah*
öhm, wo liegt das problem? bei bedarf kann dir das im grunde so ziemlich jeder hoster anbieten ...

[al]

PMJI, aber ihr diskutiert da grade "Luft"... Bei einen "ordentlichen" Provider muß einfach beides möglich sein. Punkt. (und soweit ich weiß passt das - bis auf ein paar Spamfilter-Ausnahmen, für die AOn ja schon berühmt ist - bei A1/AOn).

Es gibt (von Ju genannt) Anwendungsfälle, da kommst Du nicht drum rum, einen "lokalen" Smarthost zu verwenden (zur Not macht man den halt selbst). Es gibt aber auch Anwendungsfälle ("mobile Geräte", die zwischen div. LANs/WLANs und Mobilfunk roamen), da willst Du verdammt nochmal Submission mit Authentication und da gehören dann die z.B. WLAN-Betreiber, die den Submission Port sperren, ... (ich enthalte mich da jetzt näherer Ausführungen)

Dass es für SPF eh nur die eine Möglichkeit gibt, über einen deklariert vertrauenswürdigen Smarthost zu schicken (siehe GMX), eh kloa.

Und auch das "von Netz zu Netz schicken" ist kein Argument, bei einer "client IP" kommst Du um einen Smarthost (der ja dann zustellt) nicht drum rum, und bei wem Du jetzt submittest, kann/muß dem Access Provider egal sein. Er darf nur nicht Port 25 überallhin immer erlauben (für client ranges).

/al

[local.host]

>... und dann das Mail sinnloserweise in ein anderes Netz zu senden wo selten auch das finale Ziel ist,
>also das auch wieder aus dem anderen Netz rus muss ... wieder in ein anderes Netz rein ...
ich hab schon vermutet, dass die antwort in diese richtung geht - aus ökonomischer sicht, war dies vielleicht auch mal ein durchaus zu berücksichtigendes kriterium - aber IMHO kann man das aufgrund der heute verfügbaren bandbreiten wohl eher vernachlässigen

dieses Argument aus der technischen Ecke ist disqualifizierend. Für mich jedenfalls. Es zeugt von "ich putz mich ab, sollen doch die anderen ..."

aus anwendersicht isses sowieso egal was dahinter abläuft, hauptsache ist das ganze funktioniert ohne einschränkungen ...

den ANWENDER interessiert ausser Funktion nie irgendwas. Naja: ausser den Preis.

>ausserdem: zum Punkt Spambewertung: als ob da dann bei den Hostern in aller Regel
>auch noch der Hostname richtig drinnen steht und dann agr auch noch der PTR matcht ... *pfah*
öhm, wo liegt das problem? bei bedarf kann dir das im grunde so ziemlich jeder hoster anbieten ...

well, let's agree to disagree.