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

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

SPF-Probleme nach email forwarding

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

Contents

  SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-08-27 12:58 +0000
    Re: SPF-Probleme nach email forwarding Sven Hartge <sh-178@svenhartge.de> - 2017-08-27 15:43 +0200
      Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-08-27 13:57 +0000
        Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-08-27 16:15 +0200
        Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-08-28 01:28 +0200
    Re: SPF-Probleme nach email forwarding Nomen Nescio <nobody@dizum.com> - 2017-08-28 01:53 +0200
      Re: SPF-Probleme nach email forwarding Sven Hartge <sh-178@svenhartge.de> - 2017-08-28 10:24 +0200
        Re: SPF-Probleme nach email forwarding Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2017-08-28 17:43 +0200
          Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-08-30 22:58 +0200
            Re: SPF-Probleme nach email forwarding Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2017-08-31 07:32 +0200
              Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-08-31 15:47 +0000
                Re: SPF-Probleme nach email forwarding Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2017-08-31 18:22 +0200
                  Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-08-31 17:27 +0000
                    Re: SPF-Probleme nach email forwarding Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2017-08-31 20:06 +0200
                      Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-08-31 18:23 +0000
                        Re: SPF-Probleme nach email forwarding Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2017-08-31 22:06 +0200
                        Re: SPF-Probleme nach email forwarding Paul Muster <exp-311217@news.muster.net> - 2017-09-04 21:03 +0200
                          Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-09-04 19:31 +0000
                            Re: SPF-Probleme nach email forwarding Paul Muster <exp-311217@news.muster.net> - 2017-09-04 22:04 +0200
                              Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-04 22:53 +0200
                                Re: SPF-Probleme nach email forwarding Paul Muster <exp-311217@news.muster.net> - 2017-09-18 22:53 +0200
                Re: SPF-Probleme nach email forwarding Klaus Maria Pfeiffer <klaus.m.pfeiffer@kmp.or.at> - 2017-08-31 19:45 +0200
      Re: SPF-Probleme nach email forwarding Arno Welzel <usenet@arnowelzel.de> - 2017-08-28 13:45 +0200
        Re: SPF-Probleme nach email forwarding Matthias Andree <matthias.andree@gmx.de> - 2017-09-04 20:18 +0200
          Re: SPF-Probleme nach email forwarding Arno Welzel <usenet@arnowelzel.de> - 2017-09-17 14:51 +0200
    Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-08-28 01:28 +0200
      Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-08-30 23:04 +0200
        Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-03 00:30 +0200
          Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-10 13:58 +0200
            Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-10 23:39 +0200
              Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-17 11:43 +0200
                Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-17 13:32 +0200
                  Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-17 14:57 +0200
                    Re: SPF-Probleme nach email forwarding dseppi@a1.net (David Seppi) - 2017-09-17 15:22 +0000
                      Re: SPF-Probleme nach email forwarding "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-09-19 22:40 +0200
                        Re: SPF-Probleme nach email forwarding dseppi@a1.net (David Seppi) - 2017-09-19 22:01 +0000
                    Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-17 16:56 +0200
      Re: SPF-Probleme nach email forwarding Matthias Andree <matthias.andree@gmx.de> - 2017-09-04 20:15 +0200
        Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-10 22:54 +0200
          Re: SPF-Probleme nach email forwarding Martin Τrautmann <t-usenet@gmx.net> - 2017-09-11 05:57 +0000
            Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-16 19:56 +0200
          Re: SPF-Probleme nach email forwarding Matthias Andree <matthias.andree@gmx.de> - 2017-09-13 17:57 +0200
            Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-16 18:27 +0200
      Re: SPF-Probleme nach email forwarding Thomas Hochstein <thh@inter.net> - 2017-09-17 10:39 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#5808

On 04.09.2017 22:53, Peter J. Holzer wrote:
> On 2017-09-04 20:04, Paul Muster <exp-311217@news.muster.net> wrote:
>> On 04.09.2017 21:31, Martin Τrautmann wrote:
>>> On Mon, 4 Sep 2017 21:03:52 +0200, Paul Muster wrote:

>>>> Vielleicht kann dann mail3 die SPF-Prüfung für Mails, die von mail2
>>>> kommen, abschalten.
>>>
>>> Das war mein Wunsch, geht aber wohl nicht. Daher die Frage hier,
>>> vielleicht hätte jemand gewusst ob's geht.
>>
>> Natürlich _geht_ das. Wenn der Admin von mail3 will.
> 
> Bei manchen Admins kann es durchaus auch am Können scheitern, nicht nur
> am Wollen.

Ja, nun, dann muss er halt ein bisschen lesen....


mfG Paul

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

#5762

On 08/31/2017 05:47 PM, Martin Τrautmann wrote:
> alias@mail2.org ist z.B. so etwas wie kontakt@mail2.org.

falls bei mail2.org ein dovecot mit sieve läuft könnte man dort den
freundlichen postmaster bitten, daß der dovecot bei einer
mail-weiterleitung den envelope-from auf den ursprünglichen empfänger
verdreht, dann ist SPF auch wieder gut.

  sieve_redirect_envelope_from = orig_recipient

gre3tings, Klaus

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

#5752

Nomen Nescio:

> Martin Τrautmann <t-usenet@gmx.net> wrote:
> 
>> wie löst man folgendes SPF Problem?
> 
> Indem man die SPF-Validierung abschaltet und/oder die SPF-Einträge aus dem 
> DNS entfernt.
> 
> SPF ist Mist und versucht ein Problem zu lösen, das es nicht gibt. Es 
> verursacht sehr viel mehr Ärger und wird nur von MXen genutzt, die 
> möglichst garkeine Mail annehmen wollen.

Also GMail, GMX, web.de...


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#5768

Am 28.08.2017 um 13:45 schrieb Arno Welzel:
> Nomen Nescio:
> 
>> Martin Τrautmann <t-usenet@gmx.net> wrote:
>>
>>> wie löst man folgendes SPF Problem?
>>
>> Indem man die SPF-Validierung abschaltet und/oder die SPF-Einträge aus dem 
>> DNS entfernt.
>>
>> SPF ist Mist und versucht ein Problem zu lösen, das es nicht gibt. Es 
>> verursacht sehr viel mehr Ärger und wird nur von MXen genutzt, die 
>> möglichst garkeine Mail annehmen wollen.
> 
> Also GMail, GMX, web.de...

Genau. Wenig Mail annehmen und aggressiv filtern spart Personalkosten
bei den eigenen Admins.

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

#5785

Matthias Andree:

> Am 28.08.2017 um 13:45 schrieb Arno Welzel:
>> Nomen Nescio:
>>
>>> Martin Τrautmann <t-usenet@gmx.net> wrote:
>>>
>>>> wie löst man folgendes SPF Problem?
>>>
>>> Indem man die SPF-Validierung abschaltet und/oder die SPF-Einträge aus dem 
>>> DNS entfernt.
>>>
>>> SPF ist Mist und versucht ein Problem zu lösen, das es nicht gibt. Es 
>>> verursacht sehr viel mehr Ärger und wird nur von MXen genutzt, die 
>>> möglichst garkeine Mail annehmen wollen.
>>
>> Also GMail, GMX, web.de...
> 
> Genau. Wenig Mail annehmen und aggressiv filtern spart Personalkosten
> bei den eigenen Admins.

In wie weit spart man Kosten bei den Admins, wenn man weniger Mail annimmt?


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#5754

Martin ?rautmann schrieb:

> Wie löst man nun dieses Problem?
> Wie bringt man mail3.org bei, dass Mails über mail2.org nicht bäh sind?

Das Problem kann man sinnvoll nur beim Weiterleiter lösen: mit SPF.

(Oder man stellt den SPF-Check beim endgültiten Empfänger ab, oder man
veröffentlicht keine SPF-Daten mehr für den Absender, aber das sind
natürlich beides keine Lösungen.)

> Die Installation einer mailing list nur für die Weiterverteilung an drei
> Leute erscheint übertrieben.

Mailinglisten haben ähnliche Probleme, mit SRS wie mit DKIM.

> Oder ist irgendwas bei der Installation von mail1 oder mail2 vermurkst,
> was zur SPF Ablehnung führt?

Nein.

SPF bedeutet, dass simple Weiterleitungen nicht mehr möglich sind,
sondern SRS erfordern.

SRS ist eine zwingende Folge von SPF.

Das hat allerdings längst noch nicht jeder, der Mailweiterleitungen
anbietet, und auch noch nicht jeder Betreiber von Mailinglisten
mitbekommen (oder es mitbekommen, aber noch nicht umsetzen können).

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<http://th-h.de/infos/email/>

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

#5757

On 2017-08-27 23:28, Thomas Hochstein <thh@inter.net> wrote:
> Martin ?rautmann schrieb:
>> Wie löst man nun dieses Problem?
>> Wie bringt man mail3.org bei, dass Mails über mail2.org nicht bäh sind?
>
> Das Problem kann man sinnvoll nur beim Weiterleiter lösen: mit SPF.
>
> (Oder man stellt den SPF-Check beim endgültiten Empfänger ab, oder man
> veröffentlicht keine SPF-Daten mehr für den Absender, aber das sind
> natürlich beides keine Lösungen.)

Den SPF-Check beim endgültiten Empfänger abzustellen, halte ich sehr
wohl für eine Lösung: Denn der weiß, dass es eine Weiterleitung gibt
(ziemlich sicher hat er sie selbst eingerichtet, und wenn nicht, dann
wurde das mit seiner Zustimmung gemacht - sonst ist es eh Spam und SPF
erfüllt seinen Zweck) und kann daher zielgerichtet Mails, die vom Relay
kommen, vom SPF-Check ausnehmen.

Dass diverse Freemail-Provider das nicht anbieten ... deren Problem,
bzw. das ihrer Kunden^WProdukte.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

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

#5773

Peter J. Holzer schrieb:

> Den SPF-Check beim endgültiten Empfänger abzustellen, halte ich sehr
> wohl für eine Lösung: Denn der weiß, dass es eine Weiterleitung gibt
> (ziemlich sicher hat er sie selbst eingerichtet, und wenn nicht, dann
> wurde das mit seiner Zustimmung gemacht - sonst ist es eh Spam und SPF
> erfüllt seinen Zweck) und kann daher zielgerichtet Mails, die vom Relay
> kommen, vom SPF-Check ausnehmen.

Wenn man das so spezifisch konfiguriert, klar - aber das ist in der
üblichen Konstellation, bei der der Empfänger Endnutzer mit wenig
Einfluß auf die Serverkonfiguration ist (und der Postmaster wenig
willig ist, jedem Nutzer irgendwelche Sonderlocken zu drehen), wenig
wahrscheinlich.

Ansonsten wäre das freilich eine denkbare, wenn auch eher schlecht
skalierende Lösung.

-thh

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

#5774

On 2017-09-02 22:30, Thomas Hochstein <thh@inter.net> wrote:
> Peter J. Holzer schrieb:
>> Den SPF-Check beim endgültiten Empfänger abzustellen, halte ich sehr
>> wohl für eine Lösung: Denn der weiß, dass es eine Weiterleitung gibt
>> (ziemlich sicher hat er sie selbst eingerichtet, und wenn nicht, dann
>> wurde das mit seiner Zustimmung gemacht - sonst ist es eh Spam und SPF
>> erfüllt seinen Zweck) und kann daher zielgerichtet Mails, die vom Relay
>> kommen, vom SPF-Check ausnehmen.
>
> Wenn man das so spezifisch konfiguriert, klar - aber das ist in der
> üblichen Konstellation, bei der der Empfänger Endnutzer mit wenig
> Einfluß auf die Serverkonfiguration ist (und der Postmaster wenig
> willig ist, jedem Nutzer irgendwelche Sonderlocken zu drehen), wenig
> wahrscheinlich.

Das trifft aber auf beide Server zu, den auf dem die Weiterleitung
eingerichtet wurde und das Ziel der Weiterleitung. In beiden Fällen hat
der Endbenutzer wenig Einfluss auf die Serverkonfiguration und der
Betreiber will keine Sonderlocken einrichten.

Beim Relay wird der Betreiber argumentieren, dass ihn SPF nicht
interessiert und es nicht sein Problem ist, wenn ein Benutzer eine
Weiterleitung zu einem anderen Provider einrichtet, der SPF auf
inkompetente Art überprüft. Warum soll er da die Adresse auf
komplizierte Art umschreiben? Soll der Benutzer halt seine Mails
woanders hin forwarden, oder - noch besser - gleich bei ihm lesen.

Beim Endempfänger wird der Betreiber argumentieren, dass es ja SRS gibt
und es nicht sein Problem ist, wenn der Benutzer eine Weiterleitung
ausgerechnet bei einem Provider konfiguriert, der das nicht unterstützt.
Soll sich der Benutzer sich halt ein kompetenteres Relay suchen, oder -
noch besser - gleich die Adresse der Mailbox verwenden, die er liest.

Beide Argumentationen haben etwas für sich, beide sind nicht sehr
benutzerfreundlich (aber bei einem Gratisaccount bist Du halt nur
Benutzer und nicht Kunde). In Summe scheint mir die Position des
Beteibers der Empfängermailbox aber etwas schwächer. Immerhin setzt er
SPF bewusst ein und ist daher dafür verantwortlich, dass das keine
negativen Auswirkungen hat. Den Aufwand auf andere abzuschieben, ist
natürlich betriebswirtschaftlich sinnvoll, aber moralisch zweifelhaft.

> Ansonsten wäre das freilich eine denkbare, wenn auch eher schlecht
> skalierende Lösung.

Skaliert mit der Menge der Empfänger von Weiterleitungen, das andere mit
der Menge der Relays. Ich weiß nicht, was schlechter ist.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

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

#5779

Peter J. Holzer schrieb:

> Beim Relay wird der Betreiber argumentieren, dass ihn SPF nicht
> interessiert und es nicht sein Problem ist, wenn ein Benutzer eine
> Weiterleitung zu einem anderen Provider einrichtet, der SPF auf
> inkompetente Art überprüft.

Wieso "auf inkompetente Art"? Die Überprüfung erfolgt genau so, wie
sie vorgesehen ist.

> Warum soll er da die Adresse auf
> komplizierte Art umschreiben? Soll der Benutzer halt seine Mails
> woanders hin forwarden, oder - noch besser - gleich bei ihm lesen.

Das halte ich allerdings für keine überzeugende Argumentation. SPF ist
nicht neu, und wer seinen Nutzern Forwarding anbietet, muss eben SRS
implementieren (oder kein Forwarding anbieten).

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

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

#5781

On 2017-09-10 21:39, Thomas Hochstein <thh@inter.net> wrote:
> Peter J. Holzer schrieb:
>
>> Beim Relay wird der Betreiber argumentieren, dass ihn SPF nicht
>> interessiert und es nicht sein Problem ist, wenn ein Benutzer eine
>> Weiterleitung zu einem anderen Provider einrichtet, der SPF auf
>> inkompetente Art überprüft.
>
> Wieso "auf inkompetente Art"? Die Überprüfung erfolgt genau so, wie
> sie vorgesehen ist.

Ich habe das natürlich etwas überspitzt formuliert, weil es die Aussage
des einen Server-Betreibers über den anderen sein sollte (und da will
natürlich jeder der Serverbetreiber begründen, warum er nichts ändern
muss sondern der andere).

Aber im Kern halte ich die Aussage für richtig. Es war nie vorgesehen,
SPF *Überall* zu prüfen, sondern nur dort, wo Mail aus der Orignalquelle
kommt. Hinter einer legitimen Weiterleitung ist das natürlich nicht der
Fall, und dort soll man natürlich nicht prüfen. Triviales Beispiel: Wenn
Du einen MX und einem Mailbox-Server hast, darfst Du am Mailbox-Server
nicht auf SPF prüfen, weil der alle Mails vom MX erhält, und eine
SPF-Prüfung daher alle Mails ablehnen würde. Eine von einem Benutzer
eingerichtete Weiterleitung ist im Prinzip das gleiche: Die Mail wird
von einem MX empfangen (dort ist eine SPF-Prüfung sinnvoll), und dann an
andere Systeme weitergeleitet, die im Einflussbereich des *Empfängers*
stehen. Daher ist dort eine SPF-Prüfung nicht mehr sinnvoll. 

Ein Provider, der SPF-Prüfungen einführt, muss diesen Anwendungsfall
bedenken. Wenn er das nicht tut, ist er inkompetent. Wenn er es tut, und
der Meinung ist, dass alle anderen auch was ändern sollen, nur weil er
SPF einführen will, ist er asozial.

>> Warum soll er da die Adresse auf komplizierte Art umschreiben? Soll
>> der Benutzer halt seine Mails woanders hin forwarden, oder - noch
>> besser - gleich bei ihm lesen.
>
> Das halte ich allerdings für keine überzeugende Argumentation. SPF ist
> nicht neu, und wer seinen Nutzern Forwarding anbietet, muss eben SRS
> implementieren (oder kein Forwarding anbieten).

De facto ja. Es gibt genug Provider, die SPF-Prüfungen ohne Möglichkeit
von Whitelists durchführen, dass man Forwarding als Produkt nicht mehr
ohne SRS (oder einen anderen äquivalenten Mechanismus) anbieten kann. 

Zufällig habe ich in den letzten Tagen einen Ausschnitt aus Nassim
Nicholas Talebs /Skin in the Game/ gelesen:
https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15
Die Mechanismen sind nicht ganz die gleichen, aber doch recht ähnlich.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

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

#5784

Peter J. Holzer schrieb:

> Aber im Kern halte ich die Aussage für richtig. Es war nie vorgesehen,
> SPF *Überall* zu prüfen, sondern nur dort, wo Mail aus der Orignalquelle
> kommt.

Das aber weiß man ja nun nicht.

> Hinter einer legitimen Weiterleitung ist das natürlich nicht der
> Fall, und dort soll man natürlich nicht prüfen.

Schon richtig. Es ist aber ein offenkundig vergebliches Unterfangen,
legitime Weiterleitungen alle einzeln zu konfigurieren.

Das bedeutet, es bedarf einer generischen Lösung, und die gibt es in
Form von SRS.

> Triviales Beispiel: Wenn
> Du einen MX und einem Mailbox-Server hast, darfst Du am Mailbox-Server
> nicht auf SPF prüfen, weil der alle Mails vom MX erhält, und eine
> SPF-Prüfung daher alle Mails ablehnen würde.

Richtig. Da weiß ich das aber auch.

> Eine von einem Benutzer
> eingerichtete Weiterleitung ist im Prinzip das gleiche: Die Mail wird
> von einem MX empfangen (dort ist eine SPF-Prüfung sinnvoll), und dann an
> andere Systeme weitergeleitet, die im Einflussbereich des *Empfängers*
> stehen. Daher ist dort eine SPF-Prüfung nicht mehr sinnvoll. 

Auch das ist richtig, aber wer bitte soll das bei einem auch nur etwas
größeren System zuverlässig konfigurieren? Wenn es erst einmal
hunderte, zigtausende oder Millionen Nutzer gibt, wird das sowieso
schlicht unmöglich.

> Ein Provider, der SPF-Prüfungen einführt, muss diesen Anwendungsfall
> bedenken. Wenn er das nicht tut, ist er inkompetent. Wenn er es tut, und
> der Meinung ist, dass alle anderen auch was ändern sollen, nur weil er
> SPF einführen will, ist er asozial.

IBTD.

Es gibt eine definierte Lösung in Form von SRS, und wer
Mailweiterleitungen ermöglicht, sollte das implementieren, jedenfalls
dann, wenn er SPF-"geschützte" Mail annimmt und weiterleitet - sonst
ist *er* inkompetent.

>> Das halte ich allerdings für keine überzeugende Argumentation. SPF ist
>> nicht neu, und wer seinen Nutzern Forwarding anbietet, muss eben SRS
>> implementieren (oder kein Forwarding anbieten).
>
> De facto ja. Es gibt genug Provider, die SPF-Prüfungen ohne Möglichkeit
> von Whitelists durchführen, dass man Forwarding als Produkt nicht mehr
> ohne SRS (oder einen anderen äquivalenten Mechanismus) anbieten kann. 

Und das ist ja nun auch kein unlösbares Problem.

Grüße,
-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

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

#5786

On 2017-09-17 11:32, Thomas Hochstein <thh@inter.net> wrote:
> Peter J. Holzer schrieb:
>> Aber im Kern halte ich die Aussage für richtig. Es war nie vorgesehen,
>> SPF *Überall* zu prüfen, sondern nur dort, wo Mail aus der Orignalquelle
>> kommt.
>
> Das aber weiß man ja nun nicht.
>
>> Hinter einer legitimen Weiterleitung ist das natürlich nicht der
>> Fall, und dort soll man natürlich nicht prüfen.
>
> Schon richtig. Es ist aber ein offenkundig vergebliches Unterfangen,
> legitime Weiterleitungen alle einzeln zu konfigurieren.

Das finde ich nun wieder überhaupt nicht offenkundig vergeblich.
Derjenige, der eine Weiterleitung einrichtet, muss halt nicht dort, wo
er weiterleitet, etwas konfigurieren, sondern auch dort, wo er empfangen
will. Minimaler Mehraufwand und skaliert perfekt.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

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

#5794

Peter J. Holzer schrieb:

> Derjenige, der eine Weiterleitung einrichtet, muss halt nicht dort, wo
> er weiterleitet, etwas konfigurieren, sondern auch dort, wo er empfangen
> will. Minimaler Mehraufwand und skaliert perfekt.

Derjenige ist aber idR nicht Mailadmin des Empfängersystems.
Wie soll er das konfigurieren?

-- 
David Seppi
1220 Wien

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

#5814

On 2017-09-17 15:22, David Seppi <dseppi@a1.net> wrote:
> Peter J. Holzer schrieb:
>> Derjenige, der eine Weiterleitung einrichtet, muss halt nicht dort, wo
>> er weiterleitet, etwas konfigurieren, sondern auch dort, wo er empfangen
>> will. Minimaler Mehraufwand und skaliert perfekt.
>
> Derjenige ist aber idR nicht Mailadmin des Empfängersystems.
> Wie soll er das konfigurieren?

Mit Hilfe des Konfigurationsinterfaces, das ihm der Admin zur Verfügung
gestellt hat.

Ja, das muss möglicherweise erst implementiert/erweitert werden. So,
what? SRS ist auch nicht vom Himmel gefallen.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

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

#5815

Peter J. Holzer schrieb:

> On 2017-09-17 15:22, David Seppi <dseppi@a1.net> wrote:
[...]
>> Derjenige ist aber idR nicht Mailadmin des Empfängersystems.
>> Wie soll er das konfigurieren?
> 
> Mit Hilfe des Konfigurationsinterfaces, das ihm der Admin zur Verfügung
> gestellt hat.

... das deutlich aufwendiger einzurichten ist als SRS.
Letzteres gibt es für viele Mailserver fertig als Paket, ersteres wirft
sicherheitsrelevante Fragen auf und muß von Laien bedienbar sein.
Außerdem kann der MX dann erst nach Bekanntgabe des Empfängers filtern.

-- 
David Seppi
1220 Wien

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

#5799

Peter J. Holzer schrieb:

> Derjenige, der eine Weiterleitung einrichtet, muss halt nicht dort, wo
> er weiterleitet, etwas konfigurieren, sondern auch dort, wo er empfangen
> will. Minimaler Mehraufwand und skaliert perfekt.

Solange jeder sich seinen eigenen Mailserver gönnt, mag das richtig
sein. Wenn "dort, wo er empfangen will" der Arbeitgeber, Verein oder
ein Mailprovider ist, dann skaliert da gar nichts mehr.

Niemand will für hunderte oder tausende Nutzer jeweils die möglichen
Forwarder einpflegen.

(Und wenn "dort, wo er weiterleitet" ebenfalls eine Maschine mit einer
Vielzahl von Nutzern ist - man denke an eine Weiterleitung von GMX an
Google o.ä. -, dann will man den Host, der weiterleitet, auch nicht
global whitelisten.)

-thh

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

#5767

Am 28.08.2017 um 01:28 schrieb Thomas Hochstein:

> SRS ist eine zwingende Folge von SPF.
> 
> Das hat allerdings längst noch nicht jeder, der Mailweiterleitungen
> anbietet, und auch noch nicht jeder Betreiber von Mailinglisten
> mitbekommen (oder es mitbekommen, aber noch nicht umsetzen können).

Was haben Mailinglisten damit zu tun?  Die setzen eh ihren eigenen
Envelope-Sender, bei mir mit VERP, schalten bei mir auch per SPF-Record
die Empfängerprüfungen Neutral, weil SPF/SRS einfach nur Grütze ist, und
wenn jemand damit ein Thema hat, sollte er den Unterschied zwischen
Envelope und Header verstehen oder sich andere Aufgaben suchen.

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

#5775

Matthias Andree schrieb:

> Am 28.08.2017 um 01:28 schrieb Thomas Hochstein:
>> Das hat allerdings längst noch nicht jeder, der Mailweiterleitungen
>> anbietet, und auch noch nicht jeder Betreiber von Mailinglisten
>> mitbekommen (oder es mitbekommen, aber noch nicht umsetzen können).
>
> Was haben Mailinglisten damit zu tun?  Die setzen eh ihren eigenen
> Envelope-Sender, bei mir mit VERP, schalten bei mir auch per SPF-Record
> die Empfängerprüfungen Neutral, weil SPF/SRS einfach nur Grütze ist, und
> wenn jemand damit ein Thema hat, sollte er den Unterschied zwischen
> Envelope und Header verstehen oder sich andere Aufgaben suchen.

DMARC prüft die Domain im (Header) From: auf entsprechende
DNS-Records. Wenn vorhanden, muss entweder eine valide DKIM-Signatur
für diese Domain vorhanden sein oder ein valider SPF-Check für diese
Domain - soweit ich den RFC verstehe. Da der SPF-Check - wie Du ja
richtig schreibst - auf den Envelope-From erfolgt, muss dessen Domain
mit der im From: identisch sein, damit die Überprüfung ein "pass"
ergibt. Wenn also die Mail keine (valide) DKIM-Signatur enthält, es
aber einen DMARC-Eintrag (und einen SPF-Eintrag) für die Domain im
From: gibt, dann kann die Mail nur durchkommen, wenn die Domain im
From: auch im Envelope-From steht und der SPF-Check positiv ausgeht.

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

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

#5776

On Sun, 10 Sep 2017 22:54:03 +0200, Thomas Hochstein wrote:
> Matthias Andree schrieb:
>
>> Am 28.08.2017 um 01:28 schrieb Thomas Hochstein:
>>> Das hat allerdings längst noch nicht jeder, der Mailweiterleitungen
>>> anbietet, und auch noch nicht jeder Betreiber von Mailinglisten
>>> mitbekommen (oder es mitbekommen, aber noch nicht umsetzen können).
>>
>> Was haben Mailinglisten damit zu tun?  Die setzen eh ihren eigenen
>> Envelope-Sender, bei mir mit VERP, schalten bei mir auch per SPF-Record
>> die Empfängerprüfungen Neutral, weil SPF/SRS einfach nur Grütze ist, und
>> wenn jemand damit ein Thema hat, sollte er den Unterschied zwischen
>> Envelope und Header verstehen oder sich andere Aufgaben suchen.
>
> DMARC prüft die Domain im (Header) From: auf entsprechende
> DNS-Records. Wenn vorhanden, muss entweder eine valide DKIM-Signatur
> für diese Domain vorhanden sein oder ein valider SPF-Check für diese
> Domain - soweit ich den RFC verstehe. Da der SPF-Check - wie Du ja
> richtig schreibst - auf den Envelope-From erfolgt, muss dessen Domain
> mit der im From: identisch sein, damit die Überprüfung ein "pass"
> ergibt. Wenn also die Mail keine (valide) DKIM-Signatur enthält, es
> aber einen DMARC-Eintrag (und einen SPF-Eintrag) für die Domain im
> From: gibt, dann kann die Mail nur durchkommen, wenn die Domain im
> From: auch im Envelope-From steht und der SPF-Check positiv ausgeht.

Warum das? Es ist eine einschränkende Sichtweise, das vom Envelope-From
zu erwarten.

Wer prüfen will, der könnte ja z.B. auch die Received-Einträge auf
Plausibilität prüfen, ob das From dazu passt.

Dass ein Envelope-From angepasst werden SOLLTE, steht das in den RFCs?

Schönen Gruß
Martin

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web