Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6887 > unrolled thread

DMARC policy Error beim Empfänger

Back to article view | Back to de.comm.software.mailserver

Contents

  DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 08:09 +0200
    Re: DMARC policy Error beim Empfänger Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-10-24 09:48 +0200
      Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 13:05 +0200
        Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 13:09 +0200
        Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-24 14:37 +0200
          Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-24 15:39 +0200
            Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-25 18:15 +0200
              Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-26 07:11 +0200
                Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-26 16:02 +0200
                  Re: DMARC policy Error beim Empfänger Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-10-26 17:17 +0200
                    Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-10-26 19:30 +0200
                      Re: DMARC policy Error beim Empfänger Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-10-26 20:39 +0000
                        Re: DMARC policy Error beim Empfänger Marcus Jodorf <m@bogomips.de> - 2023-11-07 02:33 +0100
                          Re: DMARC policy Error beim Empfänger Arno Welzel <usenet@arnowelzel.de> - 2023-11-07 14:55 +0100
                  Re: DMARC policy Error beim Empfänger Jan Novak <repcom@gmail.com> - 2023-10-27 11:14 +0200

#6887 — DMARC policy Error beim Empfänger

Hallo,

habe gerade diese Fehlermeldung beim Versand einer Mail bekommen:

  host
     smail-swn-mta1.dts-security.de[212.101.206.83] said: 554 5.7.5 
Permanent
     error evaluating DMARC policy (in reply to end of DATA command)


Was genau heisst das?
Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen 
DMARC Eintrag) oder von der Empfängerseite?
Und was kann ich dagegen tun?

Jan

[toc] | [next] | [standalone]

#6888

Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:

> Was genau heisst das?
> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen 
> DMARC Eintrag) oder von der Empfängerseite?
> Und was kann ich dagegen tun?

Mit welcher Domain schickst du weg?

Ist da DMARC eingerichtet?
Setzt der Empfänger ggf. DMARC voraus?

[toc] | [prev] | [next] | [standalone]

#6889

Am 24.10.23 um 09:48 schrieb Marco Moock:
> Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:
> 
>> Was genau heisst das?
>> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
>> DMARC Eintrag) oder von der Empfängerseite?
>> Und was kann ich dagegen tun?
> 
> Mit welcher Domain schickst du weg?
> 
> Ist da DMARC eingerichtet?
> Setzt der Empfänger ggf. DMARC voraus?
> 

Hallo Marco,

ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.

Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen 
Einfluss, bzw. weiss nicht, was er vorraus setzt.

Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne 
korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und 
besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet 
werden).

Jan

[toc] | [prev] | [next] | [standalone]

#6890

Am 24.10.23 um 13:05 schrieb Jan Novak:
> Am 24.10.23 um 09:48 schrieb Marco Moock:
>> Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:
>>
>>> Was genau heisst das?
>>> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
>>> DMARC Eintrag) oder von der Empfängerseite?
>>> Und was kann ich dagegen tun?
>>
>> Mit welcher Domain schickst du weg?
>>
>> Ist da DMARC eingerichtet?
>> Setzt der Empfänger ggf. DMARC voraus?
>>
> 
> Hallo Marco,
> 
> ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.
> 
> Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen 
> Einfluss, bzw. weiss nicht, was er vorraus setzt.
> 
> Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne 
> korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und 
> besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet 
> werden).

Muss wohl an meinem Mailserver liegen. Hab die gleiche Mail (aus dem 
gleichen Thunderbird) über mein google gesendet, die kam an und wurde 
sofort bestätigt.


Jan

[toc] | [prev] | [next] | [standalone]

#6891

Jan Novak, 2023-10-24 13:05:

> Am 24.10.23 um 09:48 schrieb Marco Moock:
>> Am 24.10.2023 um 08:09:11 Uhr schrieb Jan Novak:
>>
>>> Was genau heisst das?
>>> Der DMARC policy Error stammt von meinem Mailserver (und dem dortigen
>>> DMARC Eintrag) oder von der Empfängerseite?
>>> Und was kann ich dagegen tun?
>>
>> Mit welcher Domain schickst du weg?
>>
>> Ist da DMARC eingerichtet?
>> Setzt der Empfänger ggf. DMARC voraus?
>>
> 
> Hallo Marco,
> 
> ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.

Was alleine noch nicht viel bedeutet.

> Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen 
> Einfluss, bzw. weiss nicht, was er vorraus setzt.
> 
> Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne 
> korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und 
> besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet 
> werden).

Und ist der laut SPF-Record zulässig für die Domain, die in der E-Mail
benutzt wurde?

Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
wird recht detailliert angezeigt, wenn etwas nicht passt.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6892

Am 24.10.23 um 14:37 schrieb Arno Welzel:

>> ich sende eine Mail für meine Domain, für welche auch DMARC gesetzt ist.
> 
> Was alleine noch nicht viel bedeutet.
> 
>> Auf den Empfänger (großes Unternehmen) habe ich natürlich keinen
>> Einfluss, bzw. weiss nicht, was er vorraus setzt.
>>
>> Der dmarc checker bei https://mxtoolbox.com/ gibt für meine Domäne
>> korrekte Daten aus. Der Mailserver selbst ist eine andere Domain und
>> besitzt keinen dmarc Eintrag (weil in dessen Namen keine Mails gesendet
>> werden).
> 
> Und ist der laut SPF-Record zulässig für die Domain, die in der E-Mail
> benutzt wurde?

Ja (siehe unten).

> 
> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
> wird recht detailliert angezeigt, wenn etwas nicht passt.

Guter Tipp:
Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):

-0.1	DKIM_SIGNED	Message has a DKIM or DK signature, not necessarily valid
Diese Regel wird angewendet, wenn die E-Mail eine DKIM Signatur 
aufweist, aber weitere positive Regeln werden bei einer gültigen DKIM 
Signatur ebenfalls angewendet. Bitte beachten Sie den folgenden Absatz.
0.1	DKIM_VALID	Message has at least one valid DKIM or DK signature
Wunderbar! Ihre Signatur ist gültig.
0.1	DKIM_VALID_AU	Message has a valid DKIM or DK signature from author's 
domain
Großartig! Ihre Signatur ist gültig und sie kommt von der ausgewiesenen 
Domain
0.1	DKIM_VALID_EF	Message has a valid DKIM or DK signature from 
envelope-from domain
0.001	SPF_HELO_PASS	SPF: HELO matches SPF record
0.001	SPF_PASS	SPF: sender matches SPF record
Wunderbar! Ihr SPF-Eintrag ist gültig.


Lediglich

"Klicken Sie hier, um Ihre Nachricht anzuzeigen
SpamAssassin mag Ihre E-Mail
Sie sind vollständig berechtigt
Ihre Nachricht könnte verbessert werden
Sie werden in keiner Blacklist geführt."

Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein 
Name, nur das Wort "test")

Von daher scheint das alles OK zu sein.

Jan

[toc] | [prev] | [next] | [standalone]

#6893

Jan Novak, 2023-10-24 15:39:

> Am 24.10.23 um 14:37 schrieb Arno Welzel:
[...]
>> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
>> wird recht detailliert angezeigt, wenn etwas nicht passt.
> 
> Guter Tipp:
> Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):

[...]

> Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein 
> Name, nur das Wort "test")
> 
> Von daher scheint das alles OK zu sein.

Ja, sehe ich auch so. Ich würde genau *das* dem Empfänger mitteilen und
darum bitten, den Bug in deren System zu beheben.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6894

Am 25.10.23 um 18:15 schrieb Arno Welzel:
> Jan Novak, 2023-10-24 15:39:
> 
>> Am 24.10.23 um 14:37 schrieb Arno Welzel:
> [...]
>>> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
>>> wird recht detailliert angezeigt, wenn etwas nicht passt.
>>
>> Guter Tipp:
>> Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):
> 
> [...]
> 
>> Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein
>> Name, nur das Wort "test")
>>
>> Von daher scheint das alles OK zu sein.
> 
> Ja, sehe ich auch so. Ich würde genau *das* dem Empfänger mitteilen und
> darum bitten, den Bug in deren System zu beheben.

Wenn das mal ginge... habe gestern eine interessanten Beitrag dazu auf 
Heise gelesen. Das ist von den "großen" durchaus so gewollt...

https://www.heise.de/ratgeber/Mailserver-in-Eigenregie-Was-Sie-heute-brauchen-9329490.html

Jan

[toc] | [prev] | [next] | [standalone]

#6895

Jan Novak, 2023-10-26 07:11:

> Am 25.10.23 um 18:15 schrieb Arno Welzel:
>> Jan Novak, 2023-10-24 15:39:
>>
>>> Am 24.10.23 um 14:37 schrieb Arno Welzel:
>> [...]
>>>> Zum Testen kannst Du auch <https://www.mail-tester.com> verwenden. Da
>>>> wird recht detailliert angezeigt, wenn etwas nicht passt.
>>>
>>> Guter Tipp:
>>> Allerdings meldet mir die Seite, dass alles bestens sei (Auszug):
>>
>> [...]
>>
>>> Die "verbessert" liegt am Inhalt der Testmail (keine Signatur, kein
>>> Name, nur das Wort "test")
>>>
>>> Von daher scheint das alles OK zu sein.
>>
>> Ja, sehe ich auch so. Ich würde genau *das* dem Empfänger mitteilen und
>> darum bitten, den Bug in deren System zu beheben.
> 
> Wenn das mal ginge... habe gestern eine interessanten Beitrag dazu auf 
> Heise gelesen. Das ist von den "großen" durchaus so gewollt...
> 
> https://www.heise.de/ratgeber/Mailserver-in-Eigenregie-Was-Sie-heute-brauchen-9329490.html

Der ist leider hinter eine Bezahlschranke.

E-Mail-Empfang ist in der Regel absolut problemlos - denn das produziert
ja keinen Spam. Aber das *senden* von E-Mail ist mittlerweile ein echter
Spießrutenlauf :-(.

Was ich auch kenne, ist Blacklisting weil der Server beim großen
Anbieter nicht bekannt ist. So landen E-Mails bei Microsoft gerne mal in
einem schwarzen Loch, ohne dass man es merkt oder man bekommt die
beliebte Meldung S3150, weil gleich ganze Adressblöcke des Hosters bei
Microsoft gesperrt sind. Das gelöst zu bekommen, ohne den Hoster zu
wechseln, ist nahezu unmöglich, weil in solchen Adressblöcken halt auch
oft Server von Hobby-Admins stehen, die nicht immer zuverlässig
Missbrauch ihrer Server für Spam verhindern.

Und die Telekom hat besonders lustige Anforderungen, dass man nicht nur
den sendenden Mail-Server explizit dort anmelden muss mit Angabe von
IP-Adresse und Hostname (der natürlich auch bei rDNS aus der Adresse
auflösbar sein muss) sondern man will unter dem Namen auch eine Website
erreichar haben, auf der ein Impressum des Serverbetreibers angegeben ist.

Leider kann ich meinen Nutzern auch nur schwer vermitteln kann, dass
Telekom-Adressen halt einfach nicht gehen, weil die Telekom blöd ist.
Also gibt es jetzt eben auch eine Website unter dem Namen des
Mail-Relay, damit die Telekom glücklich ist.

Trotz dieser Reifen, durch die man springen muss, weigere ich mich
bisher standhaft, einen Anbieter wie Mailjet, Sendinblue, GMail (was mit
eigener Domain ginge) oder mailbox.org für ausgehende E-Mail zu nutzen.
Der Server steht bei keinem Massenhoster und wird auch anstandslos
selbst bei schwierigen Kandidaten akzeptiert, die sonst gerne kleine
Server per se ablehnen, wie Microsoft, Google oder öffentliche
Institutionen, die so lustige Dinge wie UCEPROTECT nutzen (siehe auch
<https://arnowelzel.de/erfahrungen-mit-uceprotect>). Dafür kostet er
halt auch ein paar EUR mehr als ein billiger virtuelle Server bei einem
der großen Hoster. Bisher bin ich bereit, den Preis für die eigene
Unabhängigkeit zu bezahlen. Ob das auch in 5 oder 10 Jahren noch so ist,
weiß ich aber nicht.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6896

Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:

> E-Mail-Empfang ist in der Regel absolut problemlos - denn das
> produziert ja keinen Spam. Aber das *senden* von E-Mail ist
> mittlerweile ein echter Spießrutenlauf :-(.

Habe ich oft gehört, aber ich konnte das mit meinem Server bisher nicht
erfahren (IPv4/IPv6 bei TAL AS 8820).
Mails an GMail gingen per IPv6 problemlos raus und kamen beim
Empfänger an. Auch bei GMX gab es keine Probleme.
Wundert mich zwar, aber besser so als anders.

> Was ich auch kenne, ist Blacklisting weil der Server beim großen
> Anbieter nicht bekannt ist. So landen E-Mails bei Microsoft gerne mal
> in einem schwarzen Loch, ohne dass man es merkt oder man bekommt die
> beliebte Meldung S3150, weil gleich ganze Adressblöcke des Hosters bei
> Microsoft gesperrt sind. Das gelöst zu bekommen, ohne den Hoster zu
> wechseln, ist nahezu unmöglich, weil in solchen Adressblöcken halt
> auch oft Server von Hobby-Admins stehen, die nicht immer zuverlässig
> Missbrauch ihrer Server für Spam verhindern.

Noch schlimmer: Server von Spammern.
Oft kümmern sich die ISPs gar nicht oder viel zu langsam darum.
Aber auch spammende normale Nutzer sollte man als ISP schnellstmöglich
blockieren.

> Und die Telekom hat besonders lustige Anforderungen, dass man nicht
> nur den sendenden Mail-Server explizit dort anmelden muss mit Angabe
> von IP-Adresse und Hostname (der natürlich auch bei rDNS aus der
> Adresse auflösbar sein muss) sondern man will unter dem Namen auch
> eine Website erreichar haben, auf der ein Impressum des
> Serverbetreibers angegeben ist.

Telekom kann ich nicht testen, da ich da ohne Handynummer kein Konto
erstellen kann und bisher musste ich noch nicht mit einer
T-Online-Adresse schreiben.

> Leider kann ich meinen Nutzern auch nur schwer vermitteln kann, dass
> Telekom-Adressen halt einfach nicht gehen, weil die Telekom blöd ist.
> Also gibt es jetzt eben auch eine Website unter dem Namen des
> Mail-Relay, damit die Telekom glücklich ist.

Wie prüfen die das denn automatisch?

> Trotz dieser Reifen, durch die man springen muss, weigere ich mich
> bisher standhaft, einen Anbieter wie Mailjet, Sendinblue, GMail (was
> mit eigener Domain ginge) oder mailbox.org für ausgehende E-Mail zu
> nutzen. Der Server steht bei keinem Massenhoster und wird auch
> anstandslos selbst bei schwierigen Kandidaten akzeptiert, die sonst
> gerne kleine Server per se ablehnen, wie Microsoft, Google oder
> öffentliche Institutionen, die so lustige Dinge wie UCEPROTECT nutzen
> (siehe auch <https://arnowelzel.de/erfahrungen-mit-uceprotect>).

uceprotect hat aber klare Policies, die nachvollziehbar sind, im
Gegensatz zu MS und Google.
Wer Level 3 einsetzt, tut das in vollem Bewusstsein, dass legitime
Kunden blockiert werden.
Wenn du mal die AS-Nummer von Hetzner eingibst, siehst du, dass da halt
einige Netze gelistet sind, weil da viele Spammer unterwegs waren.

Maßnahmen dagegen gibt es viele, z.B. den SMTP-Port defaultmäßig zu
entsperren und z.B. fürs erste halbe Jahr ne Kaution verlangen wäre ne
Option. Bei massivem Spamversand wird die einbehalten. Dürfte Spammer
von solchen Provider fernhalten, bleiben noch die Leute, die ihre
Systeme nicht im Griff haben.

[toc] | [prev] | [next] | [standalone]

#6897

Marco Moock, 2023-10-26 17:17:

> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
[...]
>> Leider kann ich meinen Nutzern auch nur schwer vermitteln kann, dass
>> Telekom-Adressen halt einfach nicht gehen, weil die Telekom blöd ist.
>> Also gibt es jetzt eben auch eine Website unter dem Namen des
>> Mail-Relay, damit die Telekom glücklich ist.
> 
> Wie prüfen die das denn automatisch?

Gar nicht. Das wird manuell geprüft, weil man mit einem Support-Menschen
den Prozess durchkaspern darf. Und erst wenn der zufrieden ist, wird der
eigene Server freigegeben.

[...]
>> öffentliche Institutionen, die so lustige Dinge wie UCEPROTECT nutzen
>> (siehe auch <https://arnowelzel.de/erfahrungen-mit-uceprotect>).
> 
> uceprotect hat aber klare Policies, die nachvollziehbar sind, im
> Gegensatz zu MS und Google.

Das hilft aber nicht, wenn man einen Server in einem Netz hat, wo
*andere* Server Probleme machen und Empfänger Level 3 blocken.

Die Lösung ist dann nur noch den Hoster zu wechseln und zu hoffen, dass
dessen Adressbereiche nicht gelistet sind. Ob man selbst völlig sauber
arbeitet ist dann völlig egal.

> Wer Level 3 einsetzt, tut das in vollem Bewusstsein, dass legitime
> Kunden blockiert werden.

Ja - hilft mir aber nicht. Meine User meckern dann, dass ihre E-Mail
nicht ankommt.

> Wenn du mal die AS-Nummer von Hetzner eingibst, siehst du, dass da halt
> einige Netze gelistet sind, weil da viele Spammer unterwegs waren.

Deswegen ist der Server, über den ich Mail sende, auch nicht bei Hetzner
(und auch nicht bei Ionos etc.).

> Maßnahmen dagegen gibt es viele, z.B. den SMTP-Port defaultmäßig zu
> entsperren und z.B. fürs erste halbe Jahr ne Kaution verlangen wäre ne
> Option. Bei massivem Spamversand wird die einbehalten. Dürfte Spammer
> von solchen Provider fernhalten, bleiben noch die Leute, die ihre
> Systeme nicht im Griff haben.

Aber Geldgier siegt halt - und dann will man lieber viele Kunden, die
Mist bauen als wenige Kunden, die Kaution zahlen wollen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6898

Arno Welzel <usenet@arnowelzel.de> wrote:
> Marco Moock, 2023-10-26 17:17:
> 
>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
> [...]
>>> Leider kann ich meinen Nutzern auch nur schwer vermitteln kann, dass
>>> Telekom-Adressen halt einfach nicht gehen, weil die Telekom blöd ist.
>>> Also gibt es jetzt eben auch eine Website unter dem Namen des
>>> Mail-Relay, damit die Telekom glücklich ist.
>> 
>> Wie prüfen die das denn automatisch?
> 
> Gar nicht. Das wird manuell geprüft, weil man mit einem Support-Menschen
> den Prozess durchkaspern darf. Und erst wenn der zufrieden ist, wird der
> eigene Server freigegeben.

Hab ich auch schon machen muessen.
Das ist laestig und muehsam, funktioniert aber.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#6915

Ulli Horlacher <framstag@rus.uni-stuttgart.de> schrieb:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>> Marco Moock, 2023-10-26 17:17:
>>
>>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
>> [...]
>>>> Leider kann ich meinen Nutzern auch nur schwer vermitteln kann,
>>>> dass Telekom-Adressen halt einfach nicht gehen, weil die Telekom
>>>> blöd ist.  Also gibt es jetzt eben auch eine Website unter dem
>>>> Namen des Mail-Relay, damit die Telekom glücklich ist.
>>>
>>> Wie prüfen die das denn automatisch?
>>
>> Gar nicht. Das wird manuell geprüft, weil man mit einem
>> Support-Menschen den Prozess durchkaspern darf. Und erst wenn der
>> zufrieden ist, wird der eigene Server freigegeben.
>
> Hab ich auch schon machen muessen.
> Das ist laestig und muehsam, funktioniert aber.

Interessant. Die müssen aber auch noch andere Kriterien haben.
Weil, ich habe kein Problem, von meinen eigenen kleinen V-Servern an
t-online.de Adressen Mails zu schicken - und ich habe niemals irgendwas
dafür machen müssen. Die haben auch keine Webseiten oder sonst was. Und
mehr als spf hab ich auch nicht konfiguriert.

Oder die haben irgendwann vielleicht mal Regeln gebaut mit Listen von
Servern, die sie bis zu einem Stichtag noch nicht kannten und alles
andere bis dahin freigeschaltet?
(Meine Server sind steinalt.)

Aber stimmt schon, die ganze Intransparenz ist zum Kotzen und vestümmelt
email immer mehr.



Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#6916

Marcus Jodorf, 2023-11-07 02:33:

> Ulli Horlacher <framstag@rus.uni-stuttgart.de> schrieb:
> 
>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>> Marco Moock, 2023-10-26 17:17:
>>>
>>>> Am 26.10.2023 um 16:02:47 Uhr schrieb Arno Welzel:
>>> [...]
>>>>> Leider kann ich meinen Nutzern auch nur schwer vermitteln kann,
>>>>> dass Telekom-Adressen halt einfach nicht gehen, weil die Telekom
>>>>> blöd ist.  Also gibt es jetzt eben auch eine Website unter dem
>>>>> Namen des Mail-Relay, damit die Telekom glücklich ist.
>>>>
>>>> Wie prüfen die das denn automatisch?
>>>
>>> Gar nicht. Das wird manuell geprüft, weil man mit einem
>>> Support-Menschen den Prozess durchkaspern darf. Und erst wenn der
>>> zufrieden ist, wird der eigene Server freigegeben.
>>
>> Hab ich auch schon machen muessen.
>> Das ist laestig und muehsam, funktioniert aber.
> 
> Interessant. Die müssen aber auch noch andere Kriterien haben.
> Weil, ich habe kein Problem, von meinen eigenen kleinen V-Servern an
> t-online.de Adressen Mails zu schicken - und ich habe niemals irgendwas
> dafür machen müssen. Die haben auch keine Webseiten oder sonst was. Und
> mehr als spf hab ich auch nicht konfiguriert.

Wenn die Server schon länger in Betrieb sind, war das vielleicht, bevor
sie diese Regeln eingeführt haben. Mein alter Server für den
Mailversand, den ich bis zum Spätsommer 2022 in Betrieb hatte, konnte
auch mit T-Online kommunizieren - aber der war bis dahin auch schon
locker 6 Jahre in Verwendung. Erst beim Wechsel zu einem anderen
Anbieter kam das auf.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6899

Am 26.10.23 um 16:02 schrieb Arno Welzel:
> <https://arnowelzel.de/erfahrungen-mit-uceprotect>). Dafür kostet er
> halt auch ein paar EUR mehr als ein billiger virtuelle Server bei einem
> der großen Hoster. Bisher bin ich bereit, den Preis für die eigene
> Unabhängigkeit zu bezahlen. Ob das auch in 5 oder 10 Jahren noch so ist,
> weiß ich aber nicht.


Dem kann ich mich bedingungslos anschliessen.
Aber es wird immer mehr ein Kampf gegen Windmühlen.

Jan

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web