realraum SMTP needed

[btittelbach]

Rationale

• freie SMTP Server die jede Domain als Absender akzeptieren werden immer rarer. Wenn Mitglieder von @realraum.at schicken wollen, brauchen sie oft einen SMTP Server
• Als Hackerspace ist es uncool, Leute keine Alternative zu gmail/gmx zu bieten. Braucht mehr Aufklärung, das hilft sicher auch. Traurigerweise gibt es viele mit gmail Accounts auf der ML.
• Mailling-Liste ist broken für Leute die @gmail Adressen verwenden, was so einige sind. Weil Google @realraum.at e-Mails verweigert weil die Domain nichtmal einen SPF Eintrag hat. Viele Mitglieder bekommen daher die ML e-Mails nicht.
• SPF Eintrag können wir aber nicht machen, solange jeder seinen eigenen SMTP Server verwendet

Lösungansätze

• Entweder: SMTP Server für Mitglieder via mur.at @equinox0815
• Oder: SMTP Server im r3 Netz mit auth, der via Magenta SMTP weiterschickt.
• realraum.at SPF eintragen, für
  • mur.at MX
  • barfooze.de MX
  • magenta MX
  • chaos-at-home MX (presumably)
  • weitere.. etc

pls discuss

[wilhelmy]

Wie schon kurz im IRC erwähnt:

$ host -t TXT barfooze.de
barfooze.de descriptive text "v=spf1 mx ?all"

Das bedeutet, der MX für die domain darf definitiv emails verschicken und für alle anderen hosts treffe ich keine Aussage. Würde vielleicht ja auch für die r3-ML funktionieren, wenn es so einen SPF record für realraum.at gäbe?

[btittelbach]

sorry Moritz, ich muss mich extrem mißverständlich ausgedrück haben.. Ich probier es nochmal

1. die realraum domain hat keinen SPF DNS Eintrag
2. das war bisher auch so gewollt.
3. Mailserver wie z.b. gmail zwingen einen jetzt aber praktisch dazu einen SPF Eintrag einzurichten, weil sie verweigern die Annahme e-Mails von Domains wo weder SPF noch DKIM verwendet wird.
4. Viele Menschen und Mitglieder sind auf unserer ML mit gmail drauf. Die sind dzt alle nicht erreichbar.
5. Daher wäre zu überlegen, wie wir mit diesem Problem umgehen.
6. Mein Wunsch wäre, wenn wir uns entschließen einen SPF Eintrag zu setzen, auch den barfooze.de MX als gültigen SMTP Server für die domain realraum.at bei realraum.at einzutragen, weil das für mich und max praktisch wäre.
7. natürlich bricht der neue SPF Eintrag e-Mail für viele die derzeit als @realraum.at e-mails senden, daher müssen wir drüber reden. Oder brauchen einen smtp server den diese Leute dann verwenden können.

Beispiel Fehlermeldung von Google

   ----- The following addresses had permanent fatal errors -----
    (reason: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the)

   ----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.26 This mail is unauthenticated, which poses a security risk to the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender must
<<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
<<< 550-5.7.26 DKIM checks did not pass and SPF check for [realraum.at] did not
<<< 550-5.7.26 pass with ip: [5.9.157.210]. The sender should visit
<<< 550-5.7.26  https://support.google.com/mail/answer/81126#authentication for
<<< 550 5.7.26 instructions on setting up authentication. x23-20020a1c7c17000000b003f42166c8a6si7385884wmc.174 - gsmtp
554 5.0.0 Service unavailable

[wilhelmy]

Hi Bernhard, ich hab dich schon genau so verstanden. :)
Meiner Erfahrung nach ist es genug, einen gültigen SPF record zu setzen und man wird nicht für "?all" rejected. Wenn im Record neben "mx" auch "?all" oder "~all" steht, dürfen beliebige Hosts mails von @realraum.at-Adressen verschicken, wenn ich SPF richtig interpretiere. Stünde dort "-all", dürfen andere Hosts nicht senden. Damit wird das altbekannte und für Mailinglisten nützliche Verhalten dass beliebige Hosts Mails von dieser Domain verschicken dürfen explizit als SPF Record formuliert. Das könnte das Problem meiner Meinung nach lösen, anstatt lauter Hosts explizit zu erwähnen und diese Liste auch updaten zu müssen.

Edit: Ich meine, einen "v=spf1 mx ?all" SPF record auch für realraum.at setzen, und habe meinen eigenen als Beispiel angeführt wie ich ihn mir vorstelle.

[wilhelmy]

Du kannst ja mal probieren von einem anderen Server im Internet aus eine barfooze-Mail an gmail zu schicken.

[btittelbach]

Guter Punkt, das hab ich tatsächlich nicht bedacht, das SPF ja auch eine Option für "alles erlaubt" hat. Danke. Das könnte tatsächlich helfen. Könnte ich mal eintragen.

Dann bleibt die Frage ob das andere von Leuten berichtet Problem tatsächlich ein anderes ist, oder nur dieses, aber falsch interpretiert wurde. Dass nämlich gmail (und gmx?) die Annahme von ML e-Mails verweigern, weil im From eine e-Mail Domain steht, für welche der Maillinglisten-Software-SMTP keinen SPF Eintrag hat. Das kann ich mir aber kaum vorstellen, weil Gmail müsste eigentlich auf die Sender/Return-Path/List-ID Header schauen.

[btittelbach]

schauen wir mal ob es hilft:

;; ANSWER SECTION:
realraum.at.            3600    IN      TXT     "v=spf1 mx ?all"

sonst machen wir es im nächstens Schritt mehr permissiv ;-) ohne ?

schaut im ersten Test mal gut aus.

[wilhelmy]

Das von dir beschriebene andere Problem klingt nach einem Fall für https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

Aber stimmt schon, das sollte eigentlich nur den Envelope anfassen wenn ich das gerade richtig lese.. aber weiß nicht wie das in der Praxis genau aussieht.

[btittelbach]

aktueller Test von single e-mail:

   ----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.26 This mail is unauthenticated, which poses a security risk to the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender must
<<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
<<< 550-5.7.26 DKIM checks did not pass and SPF check for [realraum.at] did not
<<< 550-5.7.26 pass with ip: [5.9.157.210]. The sender should visit
<<< 550-5.7.26  https://support.google.com/mail/answer/81126#authentication for
<<< 550 5.7.26 instructions on setting up authentication. z17-20020a05600c03d100b003f33aed5424si89760wmd.19 - gsmtp
554 5.0.0 Service unavailable

mit

> dig @1.1.1.1 TXT realraum.at +short
"v=spf1 mx ?all"

reicht wohl doch nicht...

[btittelbach]

dann experimentieren wir mal, weiterhin mit ?all drinnen, damit wir nix kaputt machen, bzw es für alle anderen wie vorher sein sollte. Wenn es damit in einer Weile besser geht... verweigert google im Fall von realraum.at auch sender die unter ?all fallen. Da das bei deiner Domain nicht so ist, würde das nahelegen dass als realraum.at Spam verschickt wurde. Vermutlich der [email protected] Mail-Alias über den soviel Spam rausgeht, u.a. an Leute mit gmail.

> dig @9.9.9.9 TXT realraum.at +short
"v=spf1 +mx +mx:barbarfooze.de +mx:kabsi.at +mx:tugraz.at ip4:89.106.215.28 ip4:89.106.211.32/27 a:s11.telematica.at +mx:magenta.at +mx:a1.at ?all"

[btittelbach]

ja. So ist es wohl leider. realraum.at ist bei u.a. gmail verbrannt und ohne SPF + Eintrag wird die e-Mail anscheinend nicht mehr akzeptiert. Mit geht es sofort und einwandfrei.

Lösungsansätze:

1. SPF Eintrag für uns bekannte MX (done)
2. SPF Eintrag für Leute die sich noch melden
3. DRINGEND: keine gmail/gmx Adressen mehr auf ungefilterte Mail-Alias registrieren. Also niemand auf olga@ und vorstand@ darf ne gmx oder gmail Adresse haben. Weil damit haben wir uns das vermutlich erst eingehandelt
4. eigenen SMTP Server, den alle weiteren Leute verwenden können. (mal testen mit anderer Domain)

[btittelbach]

1. AV und Ich werden mal mur.at Bitten olga auf eine modierierbare ML umzustellen.
2. für vorstand@, wo das gleiche große DRINGENDE Problem besteht, brauchen wir noch eine Lösung.

• Postfach zum abholen (blöd wenn jemand was löscht)
• keine hosting e-mail Addressen im alias
• mail-alias an mehrere interne IMAP Mailboxen für Vorstand bei mur.at oder selbst gehostet

Bessere Lösungen fällt mir jetzt ned ein.

[btittelbach]

Das von dir beschriebene andere Problem klingt nach einem Fall für https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme

Aber stimmt schon, das sollte eigentlich nur den Envelope anfassen wenn ich das gerade richtig lese.. aber weiß nicht wie das in der Praxis genau aussieht.

ja, das wäre prinzipiell ein Lösungsansatz

• Aber, auf der ML wo man Software dazwischen hätte die das vielleicht könnte, haben wir das Problem gar nicht, weil dort eh ein Moderator Spam rausfiltert
• Und dort wo wir das Problem haben, beim Mail-Alias der einfach dumm e-mails weiterverteilt, ist dzt keine Software dazwischen.

für den einen Alias tun wir jetzt eben eine ML Software dazwischen. (Angefragt bei mur.at)
und für den anderen Alias... weiß ich noch nicht. Das einfachste für's erste wäre mal zu schauen wer da mit cloud-Adressen drauf ist und die Leute bitten eine andere ihrere e-Mail Adressen einzutragen. (teilw schon gemacht)