[Eisfair] Mail "richtig" konfigurieren?

[Kay Martinen]

Am 14.08.22 um 20:14 schrieb Marcus Röckrath:
> Hallo Kay,
> 
> Kay Martinen wrote:
> 
>> Das ist doch eigentlich ganz einfach. Früher (TM) war es ja standard das
>> ein Mailserver ausgehende mails direkt zustellt.
> 
> Achja? Solange ich gmx nutze, das sind schon über 20 Jahre, war es normal,
> Mails auch über den smtp von gmx zu versenden.
> Genau das stand auch immer in den Anleitungen und Mailprogramme wie TB
> wurden gemaäß vorliegender Anleitungen in der Regel so konfiguriert.

Verwexelst du da jetzt grade das was ein MUA macht mit dem was ein MTA tut?

Bei einem MUA der ein Externes Konto (bei gmx o.a.) anspricht ist das ja
usus. Aber wenn du einen Lokalen MTA dazwischen schaltet dann KANNST du
ausgehendes natürlich immer noch direkt an gmx senden, oder eben über
den MTA. Der muß dann aber m.e. einen Smarthost für deine gmx-adresse
kennen - mit den zugangsdaten dafür. Und ggf. mit Zertifikats-gedöns.

> Dass es Empfängerserver gab, die auch für sie bestimmte Mail sofort
> angenommen haben, wird noch aus den Frühzeiten des Internet stammen und
> solange die Mails auch von "registrierten" Mailservern stammen, wäre das
> auch ein brauchbares Verfahren.

Ja sicher. Mit Fester IP Registriert im dns mit einem A, PTR und MX
Record. Und ggf. mit ganz vielen CNAME die auf den A verweisen und darum
jede Zertifikatsprüfung in die Tonne hauen weil der Host unter A EIN
Zertifikat zeigt - das aber nicht auf den CNAME match't den ich bei so
einem provider bekomme.

> Natürlich haben Trolle und Spammer sehr schnell begriffen, was man damit so
> anstellen kann.

Natürlich. Es sind immer die Idioten die die Welt ein bisschen kaputter
machen als sie es vorher war.

> Nun nehmen also Mailserver nur für sie bestimmte Mails an, wenn die Mail
> auch vom zuständigen SMTP-Server des Versenders kommt.
> 
> Mit SPF hat aber auch der Provider (im Beispiel gmx) seine Hände im Spiel;
> dieser kann damit vorschreiben, dass nur er überhaupt berechtigt ist, Mails
> von gmx-Users an einen anderen Mailserver zuzustellen.

Sender Policy Framework oder wie das heißt hab ich noch nicht begriffen.
Aber so ungefähr wird das wohl laufen.

>> Die Smarthosts sind ja eben genau dies. Eine Krücke mit der du sagen
>> kannst "wenn das von/an den kommt/geht schick es zu XYZ" und der letzte
>> Notnagel wäre dann eben, suche im dns den MX mit niedrigster Präferenz
>> und versuche es dort... u.s.w. mit höheren Pref-werten wenn da.
> 
> IMHO ist das keine Krücke.

Verglichen mit der direkten Zustellung an den MX der domain schon.

Ich war früher im Fidonet Mailboxverbund als BBS-Betreiber aktiv. Die
mailer dort kannten Netmail (=eMail die über x hosts geroutet wird) und
Crashmail. Sobald eine solche Mail im Mailer auftauchte schaute der ob
er darf und hat dann direkt das zielsystem angerufen und die Mail sofort
beim Eigentlichen Empfänger eingeworfen.

Aus der Sichtweise (anfang der 1990'er) ist Internet Mail die nicht mehr
direkt zugestellt werden kann; weil idioten alles kaputt machten; ein
Rückschritt in die Vergangenheit.

> Als Kunde von gmx, also Besitzer einer gmx-Adresse, ist die gmx-Rechnerfarm
> der für mich ein- und ausgangsseitig zuständige Mailserver.

Sicher. Aber gmx geht vermutlich davon aus das du einen MUA wie TB o.a.
verwendest. Das sich jemand einen eigenen Mailserver aufsetzt ist für
die ja nicht unbedingt etwas mit dem sie rechnen oder leben müssten.

Insofern: Wenn $Provider quer steht ist das deine Krücke.

>> Von DialUp-IP wird's aber vermutlich nicht klappen also bleibt nur
>> Smarthost. Einer für alle oder pro Adresse einen...
> 
> Mit einer eigenen Domain und einem Dyn-DNS-Service und korrekten DNS-Records
> könnte es auch mit Dial-Up klappen.

Mich hat an dem Setup immer abgeschreckt das ich dazu meine WAN-IP beim
dyn-DNS Dienst öffentlich machen muß, das ich einen Portforward von der
WAN-IP zum MTA brauche und das damit quasi rückwärts durch das NAT
hindurch externe IP's in meinem LAN auftreten. Und die Sorge das bei
einmal nicht aufpassen, eine Sicherheitslücke übersehen, nicht schnell
genug update gemacht das System schon kompromittiert sein kann.

Außerdem dauert es AFAIR mehrere Sekunden (oder länger) bis nach einem
Reconnect des Routers die DynIP wieder aktuell ist. Und bei Ausfall von
DynIP Aktualisierung oder des Routers landen Mail-zustellungen für
unbestimmte zeit auf einer IP die schon längst nicht mehr die meine ist.
Der Zustellversuch Zerschellt bei den meisten zwar üblicherweise am NAT
oder Paketfilter - wenn $Provider es denn überhaupt zu mir durch lässt
aber das sind mir zu viele unwägbarkeiten.


> Wr X-Mailadressen bei y-Mailhostern betreibt, muss dass auch mit einem
> lokalen Mailserver generell so konfigurieren, dass die Mail ausgangsseitig
> korrekt verteilt wird.

Damit hab ich per Se kein Problem, nur aktuell bin ich uneins wie ich
das zuordnen/übersetzen will.

kay at localhost -> kay at martinen.de wäre eine Möglichkeit.

Ich mag das intern aber nicht als @localhost haben.

Meine Interne domain (für's LAN) will ich da eigentlich auch nicht für
nehmen. Die externe Domain kann ich kaum nehmen weil ich dann so was
hätte wie

km at martinen.de (intern) -> kay at martinen.de (extern)

Was mir noch bescheuerter erscheint.

Bleibt wohl doch nur alles intern auf @localhost. Oder?

M.W. kann es nicht gehen wenn ich auf dem MTA-Host genau die gleiche
Mailadresse hätte wie sie auch extern genutzt wird. Weil dann doch nicht
mehr klar zuzuordnen ist was wohin geschickt werden sollte
(intern/Extern unterscheidung) Oder habe ich da einen Denkfehler drin?


Ｂｙｅ／
   ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)