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

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

Backscatter/Bounces durch Weiterleitungen verhindern?

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

Contents

  Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-06 17:49 +0000
    Re: Backscatter/Bounces durch Weiterleitungen verhindern? Arno Welzel <usenet@arnowelzel.de> - 2017-04-06 22:15 +0200
      Re: Backscatter/Bounces durch Weiterleitungen verhindern? "Juergen P. Meier" <nospam-1984@jors.net> - 2017-04-07 06:00 +0000
        Re: Backscatter/Bounces durch Weiterleitungen verhindern? Arno Welzel <usenet@arnowelzel.de> - 2017-04-07 10:04 +0200
    Re: Backscatter/Bounces durch Weiterleitungen verhindern? "Juergen P. Meier" <nospam-1984@jors.net> - 2017-04-07 05:48 +0000
      Re: Backscatter/Bounces durch Weiterleitungen verhindern? Tim Ritberg <tim@server.invalid> - 2017-04-07 11:54 +0200
        Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-07 15:27 +0000
          Re: Backscatter/Bounces durch Weiterleitungen verhindern? Paul Muster <exp-311217@news.muster.net> - 2017-04-08 09:21 +0200
            Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-08 11:02 +0000
      Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-07 15:24 +0000
        Re: Backscatter/Bounces durch Weiterleitungen verhindern? "Juergen P. Meier" <nospam-1984@jors.net> - 2017-04-10 06:05 +0000
          Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-11 08:56 +0000
            Re: Backscatter/Bounces durch Weiterleitungen verhindern? Sven Hartge <sh-174@svenhartge.de> - 2017-04-11 13:54 +0200
              Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-11 12:54 +0000
                Re: Backscatter/Bounces durch Weiterleitungen verhindern? Sven Hartge <sh-174@svenhartge.de> - 2017-04-11 15:34 +0200
              Re: Backscatter/Bounces durch Weiterleitungen verhindern? Thomas Hochstein <thh@inter.net> - 2017-04-14 11:37 +0200
                Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-16 18:03 +0000
                  Re: Backscatter/Bounces durch Weiterleitungen verhindern? Sven Hartge <sh-174@svenhartge.de> - 2017-04-16 20:38 +0200
    Re: Backscatter/Bounces durch Weiterleitungen verhindern? Jochen Arndt <joe-usenet@t-online.de> - 2017-04-07 13:14 +0200
      Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-07 15:32 +0000
    Re: Backscatter/Bounces durch Weiterleitungen verhindern? Klaus Maria Pfeiffer <klaus.m.pfeiffer@kmp.or.at> - 2017-04-09 11:41 +0200
      Re: Backscatter/Bounces durch Weiterleitungen verhindern? Joern Bredereck <joern@bredereck.net> - 2017-04-11 08:58 +0000
        Re: Backscatter/Bounces durch Weiterleitungen verhindern? Sven Hartge <sh-174@svenhartge.de> - 2017-04-11 13:55 +0200

Page 1 of 2  [1] 2  Next page →

#5635 — Backscatter/Bounces durch Weiterleitungen verhindern?

Hallo,

wie lässt sich in Zeiten von Backscatter das Problem von bouncenden 
Weiterleitungen lösen?

Gegeben ist ein Postfix-Server, auf dem User sich Weiterleitungen auf 
externe Ziel-Postfächer anlegen können.

Typischer Fall: 

1. Spammer schickt Spam an eine Adresse auf unserem Server, für die eine 
Weiterleitung zu T-Online.de geschaltet ist.

2. Unser Server nimmt die Mail zunächst an und versucht sie dann an den 
T-Online-MX weiterzuleiten.

3. T-Online lehnt die E-Mail als Spam ab.

Unserem Server bleibt nichts anderes übrig als eine 
Nondelivery-Notification zu generieren und als möglichen Backscatter an 
die in der Spam-Mail angegebene Absender-Adresse zu schicken.


Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu 
vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option. 
Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst 
zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in 
solch einem Fall keine Non-Delivery-Notification generiert?


vg
jb

[toc] | [next] | [standalone]

#5636

Joern Bredereck wrote:

> Hallo,
> 
> wie lässt sich in Zeiten von Backscatter das Problem von bouncenden 
> Weiterleitungen lösen?
> 
> Gegeben ist ein Postfix-Server, auf dem User sich Weiterleitungen auf 
> externe Ziel-Postfächer anlegen können.
> 
> Typischer Fall: 
> 
> 1. Spammer schickt Spam an eine Adresse auf unserem Server, für die eine 
> Weiterleitung zu T-Online.de geschaltet ist.
> 
> 2. Unser Server nimmt die Mail zunächst an und versucht sie dann an den 
> T-Online-MX weiterzuleiten.
> 
> 3. T-Online lehnt die E-Mail als Spam ab.
> 
> Unserem Server bleibt nichts anderes übrig als eine 
> Nondelivery-Notification zu generieren und als möglichen Backscatter an 
> die in der Spam-Mail angegebene Absender-Adresse zu schicken.

Wieso muss er das? Die Weiterleitung ist einzig Sache der Person, die
das haben will. Dem Absender kann egal sein, ob das klappt oder nicht.
Der Server hat die Mail angenommen. Ob die vom Empfänger gewünschte
Weiterleitung an eine andere Adresse dann auch noch klappt, ist nur noch
für den Empfänger wichtig.

> Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu 
> vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option. 
> Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst 
> zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in 
> solch einem Fall keine Non-Delivery-Notification generiert?

"Weiterleitung" an eine *andere* Adresse als die, die in E-Mail als Ziel
angegeben ist, ist kein Teil eines Standards. Daher ist auch ein NDR
keineswegs vorgeschrieben.

Zur Behandlung von Bounces, siehe hier:

<http://www.postfix.org/postconf.5.html#notify_classes>

<http://www.postfix.org/postconf.5.html#bounce_notice_recipient>


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

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

#5638

Arno Welzel <usenet@arnowelzel.de>:
> Wieso muss er das? Die Weiterleitung ist einzig Sache der Person, die
> das haben will. Dem Absender kann egal sein, ob das klappt oder nicht.
> Der Server hat die Mail angenommen. Ob die vom Empfänger gewünschte
> Weiterleitung an eine andere Adresse dann auch noch klappt, ist nur noch
> für den Empfänger wichtig.

Interessante Rechtsauffassung. Darueber laesst sich leider trefflich
streiten (insbesondere vor einem Gericht).

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

#5639

Juergen P. Meier wrote:

> Arno Welzel <usenet@arnowelzel.de>:
>> Wieso muss er das? Die Weiterleitung ist einzig Sache der Person, die
>> das haben will. Dem Absender kann egal sein, ob das klappt oder nicht.
>> Der Server hat die Mail angenommen. Ob die vom Empfänger gewünschte
>> Weiterleitung an eine andere Adresse dann auch noch klappt, ist nur noch
>> für den Empfänger wichtig.
> 
> Interessante Rechtsauffassung. Darueber laesst sich leider trefflich
> streiten (insbesondere vor einem Gericht).

Finde ich nicht.

Der Server hat die Mail ja angenommen. Was danach damit passiert, ist
alleine Sache des Empfängers. Er kann sie auch ungelesen löschen ohne
dass der Absender darüber informiert werden muss. Wenn der Empfänger dem
Server sagt, er möge jede angenommene Nachricht an eine bestimmte
Adresse schicken und das klappt dann nicht, ist das erstmal eine Sache
zwischen Empfänger und Server. Was hat der Absender damit zu tun?


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

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

#5637

Joern Bredereck <joern@bredereck.net>:
>
> wie lässt sich in Zeiten von Backscatter das Problem von bouncenden 
> Weiterleitungen lösen?
>
> Gegeben ist ein Postfix-Server, auf dem User sich Weiterleitungen auf 
> externe Ziel-Postfächer anlegen können.
>
> Typischer Fall: 
>
> 1. Spammer schickt Spam an eine Adresse auf unserem Server, für die eine 
> Weiterleitung zu T-Online.de geschaltet ist.
>
> 2. Unser Server nimmt die Mail zunächst an und versucht sie dann an den 
> T-Online-MX weiterzuleiten.

Erster Fehler.

Jetzt bist du fuer die Mail (egal ob Spam oder Ham) verantwortlich.

Und zwar auch im rechtlichen (!) Sinne.

> 3. T-Online lehnt die E-Mail als Spam ab.
>
> Unserem Server bleibt nichts anderes übrig als eine 
> Nondelivery-Notification zu generieren und als möglichen Backscatter an 
> die in der Spam-Mail angegebene Absender-Adresse zu schicken.

Zweiter Fehler. (eigentlich ein Folgefehler)

> Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu 
> vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option. 

Keine Annahme ohne Verifikation dass die Weiterleitung funktioniert.
(das schliesst eine Weiterleitung via procmail/formail/.forward etc. aus
mit Postfix kannst du deswegen nur canonical/recipient-rewriting maps
verwenden)

> Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst 
> zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in 
> solch einem Fall keine Non-Delivery-Notification generiert?

Leider nicht. Wenn du Mailrelay machst, musst du dich auch an die
Regeln halten.

Was du tun kannst ist:

Deine Spam-Filter und Spam-Blocks mindestens genauso restriktiv zu
bauen wie die Maildienstleiter an die du weiterleitest. Das verhindert
die Annahme von Spam der beim Weiterleiten Bounced.

Nur so kannst du Backscatter-Spam verhindern ohne dich der
Unterdrueckung legitimer Mail schuldig zu machen.


http://www.postfix.org/BACKSCATTER_README.html


Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

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

#5640

Am 07.04.2017 um 07:48 schrieb Juergen P. Meier:

> 
>> Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst 
>> zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in 
>> solch einem Fall keine Non-Delivery-Notification generiert?
> 
> Leider nicht. Wenn du Mailrelay machst, musst du dich auch an die
> Regeln halten.
> 
> Was du tun kannst ist:
> 
> Deine Spam-Filter und Spam-Blocks mindestens genauso restriktiv zu
> bauen wie die Maildienstleiter an die du weiterleitest. Das verhindert
> die Annahme von Spam der beim Weiterleiten Bounced.
> 
> Nur so kannst du Backscatter-Spam verhindern ohne dich der
> Unterdrueckung legitimer Mail schuldig zu machen.
> 
> 
> http://www.postfix.org/BACKSCATTER_README.html
> 
> 
> Juergen
> 

Meine Server lehnen Mails schon direkt in SMTP ab. Dort kann Postfix
auch sagen, ob ein Konto existiert und auch annimmt.

Die Regel müsste reject_unverified_recipient sein.

Tim

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

#5643

Tim Ritberg <tim@server.invalid> wrote:


> Meine Server lehnen Mails schon direkt in SMTP ab. Dort kann Postfix
> auch sagen, ob ein Konto existiert und auch annimmt.
> 
> Die Regel müsste reject_unverified_recipient sein.

Bei einer Weiterleitung ändert sich der recipient aber. Während der 
Einlieferung der Mail wird nur geprüft, ob es sich um einen lokalen 
gültigen Empfänger handelt. Ob dieser Empfänger dann wiederum an eine 
weitere Adresse weiterleitet wird beim Postfix-Verify nicht geprüft. 
Zumindest wüsste ich nicht, wie?

Außerdem prüft die Verifizierung nur, ob der Adressat existiert. Diese 
Prüfung würde ja in fast allen Fällen erfolgreich verlaufen. Der 
Ziel-Server kann dann allerdings trotzdem nach der Übertragung des 
Bodies noch die Annahme ablehnen. 

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

#5645

On 07.04.2017 17:27, Joern Bredereck wrote:
> Tim Ritberg <tim@server.invalid> wrote:

>> Meine Server lehnen Mails schon direkt in SMTP ab. Dort kann Postfix
>> auch sagen, ob ein Konto existiert und auch annimmt.
>>
>> Die Regel müsste reject_unverified_recipient sein.
>
> Bei einer Weiterleitung ändert sich der recipient aber. Während der
> Einlieferung der Mail wird nur geprüft, ob es sich um einen lokalen
> gültigen Empfänger handelt. Ob dieser Empfänger dann wiederum an eine
> weitere Adresse weiterleitet wird beim Postfix-Verify nicht geprüft.
> Zumindest wüsste ich nicht, wie?

Bei exim geht das wohl mit "cutthrough_delivery".

> Außerdem prüft die Verifizierung nur, ob der Adressat existiert. Diese
> Prüfung würde ja in fast allen Fällen erfolgreich verlaufen. Der
> Ziel-Server kann dann allerdings trotzdem nach der Übertragung des
> Bodies noch die Annahme ablehnen.

Müsste man alles mal durchdenken und ausprobieren.


mfG Paul

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

#5646

Paul Muster <exp-311217@news.muster.net> wrote:

>> Außerdem prüft die Verifizierung nur, ob der Adressat existiert. Diese
>> Prüfung würde ja in fast allen Fällen erfolgreich verlaufen. Der
>> Ziel-Server kann dann allerdings trotzdem nach der Übertragung des
>> Bodies noch die Annahme ablehnen.
> 
> Müsste man alles mal durchdenken und ausprobieren.

Bei einem 30 Jahre alten Medium wie der E-Mail wäre das wirklich 
erstaunlich. Man würde ja eigentlich vermuten, dass es dafür bereits 
etablierte und erprobte Lösungen gäbe... :-/

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

#5642

Juergen P. Meier <nospam-1984@jors.net> wrote:

>> 1. Spammer schickt Spam an eine Adresse auf unserem Server, für die eine 
>> Weiterleitung zu T-Online.de geschaltet ist.
>>
>> 2. Unser Server nimmt die Mail zunächst an und versucht sie dann an den 
>> T-Online-MX weiterzuleiten.
> 
> Erster Fehler.
> 
> Jetzt bist du fuer die Mail (egal ob Spam oder Ham) verantwortlich.

Alternative?

> Und zwar auch im rechtlichen (!) Sinne.

naja, die Weiterleitung hat der Kunde veranlasst. Wenn die Weiterleitung 
fehl schlägt (z.B. weil er sich beim Weiterleitungs-Ziel vertippt hat, 
oder weil die Mailbox des Weiterleitungs-Ziels voll ist), dann ist das 
wohl kaum mir als Betreiber des Servers anzulasten. Der Kunde hat die 
Weiterleitung zu verantworten und muss auch damit leben, wenn die 
Weiterleitung nicht klappt.

>> Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu 
>> vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option. 
> 
> Keine Annahme ohne Verifikation dass die Weiterleitung funktioniert.

Wie ginge das in der Praxis? T-Online lehnt die E-Mail ggf. erst nach 
der Übertragung des Bodies ab. 

> Was du tun kannst ist:
> 
> Deine Spam-Filter und Spam-Blocks mindestens genauso restriktiv zu
> bauen wie die Maildienstleiter an die du weiterleitest. Das verhindert
> die Annahme von Spam der beim Weiterleiten Bounced.

Ja, theoretisch wohl der richtige Ansatz in der Praxis aber kaum 
praktikabel, da ich keine Kontrolle darüber habe, wie restriktiv oder 
kaputt die Spam-Filter der Weiterleitungs-Ziele sind. Wenn z.B. einfach 
die Mailbox des Weiterleitungs-Ziel voll ist, dann kann ich das kaum bei 
der Mail-Annahme berücksichtigen.


vg
jb

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

#5648

Joern Bredereck <joern@bredereck.net>:
> Juergen P. Meier <nospam-1984@jors.net> wrote:
>
>>> 1. Spammer schickt Spam an eine Adresse auf unserem Server, für die eine 
>>> Weiterleitung zu T-Online.de geschaltet ist.
>>>
>>> 2. Unser Server nimmt die Mail zunächst an und versucht sie dann an den 
>>> T-Online-MX weiterzuleiten.
>> 
>> Erster Fehler.
>> 
>> Jetzt bist du fuer die Mail (egal ob Spam oder Ham) verantwortlich.
>
> Alternative?

Gib die Verantwortung jemand anderem.

>> Und zwar auch im rechtlichen (!) Sinne.
>
> naja, die Weiterleitung hat der Kunde veranlasst. Wenn die Weiterleitung 
> fehl schlägt (z.B. weil er sich beim Weiterleitungs-Ziel vertippt hat, 
> oder weil die Mailbox des Weiterleitungs-Ziels voll ist), dann ist das 
> wohl kaum mir als Betreiber des Servers anzulasten. Der Kunde hat die 
> Weiterleitung zu verantworten und muss auch damit leben, wenn die 
> Weiterleitung nicht klappt.

Bau in deinen Vertrag mit dem Kunden ein, dass du fuer aufgrund
irgenendwelcher Zustellfehler des von ihm eingestellten
Weiterleitungs-Ziels keine Haftung fuer verlorene Mails uebernimmst,
und du keine Unzustellbenachtichtigungen an Absender zurueck schickst,
wenn sein Weiterleitungs-ziel eine Mail nicht annimmt.

Dann sorge dafuer, dass dein Postfix keine Bounces dafuer erzeugt.

> Wie ginge das in der Praxis? T-Online lehnt die E-Mail ggf. erst nach 
> der Übertragung des Bodies ab. 

Dann hast du so gut wie verloren.

Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

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

#5649

Juergen P. Meier <nospam-1984@jors.net> wrote:

> Bau in deinen Vertrag mit dem Kunden ein,

[...]

Nimm's mir nicht übel, aber ich würde mich gerne in diesem Thread auf 
die technische Seite des Problems beschränken. Für die rechtlichen 
Aspeke bezahlen wir ein paar Anwälte.

> Dann sorge dafuer, dass dein Postfix keine Bounces dafuer erzeugt.

Lassen sich Bounces explizit für Weiterleitungen deaktivieren, während 
z.B. Bounces für's "normale" Relaying von Kunden-Mails aktiv bleiben?

>> Wie ginge das in der Praxis? T-Online lehnt die E-Mail ggf. erst nach 
>> der Übertragung des Bodies ab. 
> 
> Dann hast du so gut wie verloren.

Wie handhaben das andere Mailserver-Betreiber? Ich bin mit grösster 
Wahrscheinlichkeit nicht der einzige, der dieses Problem hat. 

Wie macht ihr das auf euren Mailservern? Weiterleitungen grundsätzlich 
verbieten?

vg
jb

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

#5651

Joern Bredereck <joern@bredereck.net> wrote:

> Wie handhaben das andere Mailserver-Betreiber? Ich bin mit grösster
> Wahrscheinlichkeit nicht der einzige, der dieses Problem hat. 

> Wie macht ihr das auf euren Mailservern? Weiterleitungen grundsätzlich
> verbieten?

Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
seit geraumer Zeit machen: Bei Weiterleitung wird die originale
Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
und Bounces in das lokale Postfach zugestellt und *nicht* an den
externen Absender zurückgeleitet.

Der Originale-Envelope-Sender wird dabei zu Dokumentationszwecken in
einem X-Orig-Envelope-Sender-Header geschrieben.

Dies funktioniert natürlich nur, weil jeder Benutzer immer einen
voll-funktionsfähigen lokalen Account hat und es keine
hat-nur-Weiterleitung-Benutzer gibt, d.h es gibt immer einen Platz, um
Bounces zu speichern.

S°

-- 
Sigmentation fault. Core dumped.

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

#5653

Sven Hartge <sh-174@svenhartge.de> wrote:

> Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
> seit geraumer Zeit machen: Bei Weiterleitung wird die originale
> Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
> und Bounces in das lokale Postfach zugestellt und *nicht* an den
> externen Absender zurückgeleitet.

Ja, diese Lösung hört sich am sinnvollsten an. Verwendet ihr zufällig 
Postfix? Falls ja, spräche etwas dagegen, wenn du über das genaue Setup 
sprichst oder mir einen Pointer in die richtige Richtung gibst, wie sich 
diese Lösung mit Postfix implementieren lässt? 

vg
jb

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

#5654

Joern Bredereck <joern@bredereck.net> wrote:
> Sven Hartge <sh-174@svenhartge.de> wrote:

>> Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
>> seit geraumer Zeit machen: Bei Weiterleitung wird die originale
>> Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
>> und Bounces in das lokale Postfach zugestellt und *nicht* an den
>> externen Absender zurückgeleitet.

> Ja, diese Lösung hört sich am sinnvollsten an. Verwendet ihr zufällig
> Postfix? 

Nein, Exim4.

S°

-- 
Sigmentation fault. Core dumped.

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

#5655

Sven Hartge schrieb:

> Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
> seit geraumer Zeit machen: Bei Weiterleitung wird die originale
> Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
> und Bounces in das lokale Postfach zugestellt und *nicht* an den
> externen Absender zurückgeleitet.

Ja, das habe ich für meinen "Hostingserver" auch schon vor vielen
Jahren so gelöst. :)

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

#5656

Thomas Hochstein <thh@inter.net> wrote:
> Sven Hartge schrieb:
> 
>> Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
>> seit geraumer Zeit machen: Bei Weiterleitung wird die originale
>> Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
>> und Bounces in das lokale Postfach zugestellt und *nicht* an den
>> externen Absender zurückgeleitet.
> 
> Ja, das habe ich für meinen "Hostingserver" auch schon vor vielen
> Jahren so gelöst. :)
> 

Könnte mir jemand einen Hinweis geben, wie sich das mit Postfix realisieren
lässt? Mit Bordmitteln scheint das nach meinen Recherchen nicht zu
funktionieren. Bin für jeden Hinweis dankbar. 

Viele Grüße,
Jörn Bredereck 

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

#5657

Joern Bredereck <joern@bredereck.net> wrote:
> Thomas Hochstein <thh@inter.net> wrote:
>> Sven Hartge schrieb:
>> 
>>> Wir (Deutsche Hochschule) machen das so, wie GMX und Web.de das schon
>>> seit geraumer Zeit machen: Bei Weiterleitung wird die originale
>>> Envelope-Sender-Adresse duch die des weiterleitenden Accounts ersetzt
>>> und Bounces in das lokale Postfach zugestellt und *nicht* an den
>>> externen Absender zurückgeleitet.
>> 
>> Ja, das habe ich für meinen "Hostingserver" auch schon vor vielen
>> Jahren so gelöst. :)
>> 

> Könnte mir jemand einen Hinweis geben, wie sich das mit Postfix
> realisieren lässt? Mit Bordmitteln scheint das nach meinen Recherchen
> nicht zu funktionieren. Bin für jeden Hinweis dankbar. 

Leider kann ich dir nicht direkt helfen, aber evtl. ein paar Ideen auf
den weg geben:

Grundsätzlich sind zwei Dinge zu lösen, eins davon einfach, das andere
ein wenig komplexer.

1) Absender umschreiben. Postfix sollte diverse Mapping-Möglichkeiten
   dafür bieten. sender_canonical_maps zusammen mit 
   "sender_canonical_classes = envelope_sender" könnte nützlich sein.

2) Verhindern, dass Bounces auch wieder weitergeleitet werden und somit
   zu einem ewigen Kreisverkehr führen würden, wenn die Ziel-Adresse
   länger nicht erreichbar ist (z.B. wg. Mailquota voll).

   Bei $arbeitgeber wird dabei nicht auf die normal Adresse des Benutzers
   umgeschrieben (z.B. thomas.mustermann@dom.ain) sondern ein Prefix
   davor gehangen: realmail-thomas.mustermann@dom.ain. Diese Adresse ist
   von der Weiterleitung ausgenommen und wird stattdessen lokal in das
   Postfach des Benutzers zugestellt.

Wir nutzen für unser Mailsystem, wie schon gesagt, Exim, weil dieser
einfach flexibler zu konfigurieren ist im Vergleich zu Postfix.
Allerdings würden dir Beispiele daraus nicht weiterhelfen, da die ganze
Chose sehr tief in unsere internen Userdatenbanken integriert ist und
die Hälfte der Konfiguration aus Makros besteht, die spezifische Dinge
dynamisch via MySQL oder LDAP beziehen.

S°

-- 
Sigmentation fault. Core dumped.

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

#5641

Am 06.04.2017 um 19:49 schrieb Joern Bredereck:

> Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu
> vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option.
> Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst
> zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in
> solch einem Fall keine Non-Delivery-Notification generiert?

Auf dem Server Postfächer einrichten in die solche Mails zugestellt 
werden. Benötigt dann natürlich einen POP/IMAP Server.

In den Nutzungsbedingungen festschreiben, dass die User das Postfach 
regelmäßig abfragen. Bei Bedarf ein Quota einrichten und bei 
Überschreitung alle eingehenden Mails ablehnen und eine Nachricht an die 
Weiterleitungsadresse senden.

Das ist m.E. die einzige rechtssichere Methode und behandelt alle Fälle 
von abgelehnter Mail.

Wie werden z.B. andere längerfristige Ablehnungen wie Quota Exceeded zur 
Zeit gehandhabt?

Joe

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

#5644

Jochen Arndt <joe-usenet@t-online.de> wrote:

>> Was wäre das korrekte Vorgehen um Backscatter in diesem Fall zu
>> vermeiden? Weiterleitungen nicht zuzulassen ist leider keine Option.
>> Wäre es valide und möglich die Nondelivery-Notifications gar nicht erst
>> zu erstellen? Falls ja, wie müsste man Postfix beibringen, dass er in
>> solch einem Fall keine Non-Delivery-Notification generiert?
> 
> Auf dem Server Postfächer einrichten in die solche Mails zugestellt 
> werden. Benötigt dann natürlich einen POP/IMAP Server.

Ok, der Ansatz hört sich auf Anhieb am Interessantesten an. Ideal wäre 
so eine art Fall-Trough-Mechanismus:

1. Der Kunde kann eine Weiterleitung auf eine externe Adresse schalten.

2. Wenn Postfix die E-mail erfolgreich auf das Ziel weiterleiten kann, 
bleibt es dabei.

3. Wenn der Remote-Server die Annahme ablehnt, wird die E-Mail 
alternativ in ein lokales IMAP-Postfach zugestellt.


Das wäre dann so eine Art "Best-Effort-Weiterleitung" mit Fallback auf 
eine normales lokales Postfach.

Ließe sich so ein Setup mit Postfix realisieren?

> In den Nutzungsbedingungen festschreiben, dass die User das Postfach 
> regelmäßig abfragen. Bei Bedarf ein Quota einrichten und bei 
> Überschreitung alle eingehenden Mails ablehnen und eine Nachricht an die 
> Weiterleitungsadresse senden.

Yep, das wäre perfekt.

> Das ist m.E. die einzige rechtssichere Methode und behandelt alle Fälle 
> von abgelehnter Mail.

Naja, ich will nicht ausschließen, dass die anderen Methoden auch 
rechtssicher wären, aber diese Lösung wäre wohl die unproblematischste, 
da die bereits angenommene E-Mail auf jeden Fall zugestellt. Entweder 
auf die vom Kunden gewünschte Ziel-Adresse des Remote-Servers, oder 
falls das nicht möglich ist, dann eben lokal ins Fallback-Postfach.

> Wie werden z.B. andere längerfristige Ablehnungen wie Quota Exceeded zur 
> Zeit gehandhabt?

Direkter Bounce bei der Annahme.

vg
jb

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web