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

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

Exim received_header_text = ''

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

Contents

  Exim received_header_text = '' Paul Muster <exp-311219@news.muster.net> - 2019-06-19 22:02 +0200
    Re: Exim received_header_text = '' Andreas Metzler <ametzler@bebt.de> - 2019-06-20 13:33 +0200
    Re: Exim received_header_text = '' Kay Martinen <kay@martinen.de> - 2019-06-20 20:52 +0200
      Re: Exim received_header_text = '' Volker Englisch <eh@rsli.inka.de> - 2019-06-21 16:39 +0000
        Re: Exim received_header_text = '' Kay Martinen <kay@martinen.de> - 2019-06-21 20:32 +0200
          Re: Exim received_header_text = '' Volker Englisch <eh@rsli.inka.de> - 2019-06-21 20:24 +0000

#6080 — Exim received_header_text = ''

Hallo,

bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die 
E-Mails, die er empfängt bzw. weiterleitet:

> Received: from ipservice-092-217-164-105.092.217.pool.provider.de ([92.217.164.105] helo=Pauls-Handy.fritz.box)
> 	by mx1.domain.tld with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
> 	(Exim 4.89)
> 	(envelope-from <paul@domain.tld>)
> 	id 1hbVYK-0008Mo-VQ; Thu, 13 Jun 2019 21:38:31 +0200

Nun macht man sich ja durchaus Gedanken über Datenschutz bzw. 
Datenvermeidung und denkt darüber nach, einfach
received_header_text = ''
in
/etc/exim4/conf.d/main/000_localmacros ¹
zu setzen, sodass Exim diese Informationen nicht mehr einfügt.

Welche Nebenwirkungen hätte das, von den Mehraufwänden beim Debugging 
abgesehen? Ist obiges Vorgehen der richtige Weg oder sollte man das 
besser anders lösen?

¹ Ja, Debian mit split config.


Danke & viele Grüße

Paul

[toc] | [next] | [standalone]

#6081

Paul Muster <exp-311219@news.muster.net> wrote:
> Hallo,

> bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die 
> E-Mails, die er empfängt bzw. weiterleitet:

>> Received: from ipservice-092-217-164-105.092.217.pool.provider.de ([92.217.164.105] helo=Pauls-Handy.fritz.box)
>>       by mx1.domain.tld with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
>>       (Exim 4.89)
>>       (envelope-from <paul@domain.tld>)
>>       id 1hbVYK-0008Mo-VQ; Thu, 13 Jun 2019 21:38:31 +0200

> Nun macht man sich ja durchaus Gedanken über Datenschutz bzw. 
> Datenvermeidung und denkt darüber nach, einfach
> received_header_text = ''
[...]

So langweilig muss mir erst mal werden, dass ich anfange mir Gedanken
über Datenschutz zu machen die weit über DSGVO hinausgehen.

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

#6082

Am 19.06.2019 um 22:02 schrieb Paul Muster:
> 
> bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die

> Nun macht man sich ja durchaus Gedanken über Datenschutz bzw.
> Datenvermeidung und denkt darüber nach, einfach
> 
> Welche Nebenwirkungen hätte das, von den Mehraufwänden beim Debugging
> abgesehen? 

Ich bin da kein Experte aber eine Nebenwirkung ist wohl klar. Weder du
noch andere könnten dann rekonstruieren ob die mail wirklich über deinen
Mailserver ging oder nicht. Frag dich selbst ob du das willst?

Daten wie interne IPs oder "Pauls-Handy.fritz.box" würde ich pers. aber
in received-zeilen nicht sehen wollen. Wenn du was filtern willst dann
eher das. Meine Meinung!



Kay

-- 
Sent via SN (Eisfair-1)

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

#6083

Kay Martinen wrote on 20.06.2019 20:52:
> Am 19.06.2019 um 22:02 schrieb Paul Muster:
>> 
>> bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die
> 
>> Nun macht man sich ja durchaus Gedanken über Datenschutz bzw.
>> Datenvermeidung und denkt darüber nach, einfach
>> 
>> Welche Nebenwirkungen hätte das, von den Mehraufwänden beim Debugging
>> abgesehen? 
> 
> Ich bin da kein Experte aber eine Nebenwirkung ist wohl klar. Weder du
> noch andere könnten dann rekonstruieren ob die mail wirklich über deinen
> Mailserver ging oder nicht. Frag dich selbst ob du das willst?

Ich bin auch kein wirklicher Experte, aber im RFC 5321 steht in Absatz
4.4 sinngemäß: "Wenn ein SMTP-Server eine Mail zur Zustellung oder
weiteren Verarbeitung erhält, MUSS er Verfolgungsinformationen (klingt
auf Englisch besser: Trace information) am Anfang der Nachricht
einfügen." Wäre also möglicherweise ein Verstoß gegen der RFC,

> Daten wie interne IPs

Wodurch könnten interne IPs gefährlich werden? 

> oder "Pauls-Handy.fritz.box" 

Das ist sowieso bääääh. Das möchte ich in der Message auch nicht stehen
haben ;-)

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

#6084

Am 21.06.2019 um 18:39 schrieb Volker Englisch:
> Kay Martinen wrote on 20.06.2019 20:52:
>> Am 19.06.2019 um 22:02 schrieb Paul Muster:
>>>
>>> bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die
>>
>>> Welche Nebenwirkungen hätte das, von den Mehraufwänden beim Debugging
>>> abgesehen? 
>>
>> noch andere könnten dann rekonstruieren ob die mail wirklich über deinen
>> Mailserver ging oder nicht. 

> Ich bin auch kein wirklicher Experte, aber im RFC 5321 steht in Absatz
> 4.4 sinngemäß: "Wenn ein SMTP-Server eine Mail zur Zustellung oder
> weiteren Verarbeitung erhält, MUSS er Verfolgungsinformationen (klingt
> auf Englisch besser: Trace information) am Anfang der Nachricht
> einfügen." Wäre also möglicherweise ein Verstoß gegen der RFC,

Offensichtlich ein Verstoß würde ich meinen. Und ich meine
Datenschutzbedenken gegen received-header i.allg. sollten nachrangig
sein wenn es um Verfolgbarkeit des Versandweges geht.

Jetzt könnte man bestenfalls noch bei abholung durch Fetchmail
argumentieren das hier (normalerweise) nur eine lokale zustellung statt
findet und das keinen header erzeugen müsste. Aber, ich wüßte im moment
auch nicht ob das überhaupt passiert. Und wenn, dann eher durch exim
"reveived from fetchmail via localhost" oder so...

>> Daten wie interne IPs
> 
> Wodurch könnten interne IPs gefährlich werden? 

Ich hab da ein bißchen schräg weiter gedacht. Interne IP werden ja
regulär eingetragen wenn man von einem internen Client über einen MTA
sendet. Und wenn; durch welche Umstände auch immer; die Mail in falsche
Hände gerät (Böze Buben, Spammer, Hacker, NSA, suchdirwasaus) dann haben
diese schon mal eine IP-range und es ggf. leichter ein zu dringen.

>> oder "Pauls-Handy.fritz.box" 
> 
> Das ist sowieso bääääh. Das möchte ich in der Message auch nicht stehen
> haben ;-)

Dito. :-) Ein Grund mehr einen internen DNS zu haben den der MTA auch
befragt. Dann steht da evtl. nur xyz.intern.meins.tld oder was auch
immer. Und auch das kann man ggf. durch ein Muster maskieren, oder
umschreiben lassen.

So wie meine Artikel zwar von meiner Domain kommen, aber mein nntp host
einen anderen internen Namen hat der aber nicht im Header auftaucht.

Kay

-- 
Sent via SN (Eisfair-1)

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

#6085

Kay Martinen wrote on 21.06.2019 20:32:
> Am 21.06.2019 um 18:39 schrieb Volker Englisch:
>> Kay Martinen wrote on 20.06.2019 20:52:
>>> Am 19.06.2019 um 22:02 schrieb Paul Muster:
>>>>
>>>> bislang schreibt mein Exim ganz normale Received:-Headerzeilen in die
>>>
>>>> Welche Nebenwirkungen hätte das, von den Mehraufwänden beim Debugging
>>>> abgesehen? 
>>>
>>> noch andere könnten dann rekonstruieren ob die mail wirklich über deinen
>>> Mailserver ging oder nicht. 
> 
>> Ich bin auch kein wirklicher Experte, aber im RFC 5321 steht in Absatz
>> 4.4 sinngemäß: "Wenn ein SMTP-Server eine Mail zur Zustellung oder
>> weiteren Verarbeitung erhält, MUSS er Verfolgungsinformationen (klingt
>> auf Englisch besser: Trace information) am Anfang der Nachricht
>> einfügen." Wäre also möglicherweise ein Verstoß gegen der RFC,
> 
> Offensichtlich ein Verstoß würde ich meinen. Und ich meine
> Datenschutzbedenken gegen received-header i.allg. sollten nachrangig
> sein wenn es um Verfolgbarkeit des Versandweges geht.

Das denke ich auch. Ich denke allerdings auch, dass "Datenschutz" in
unserem Land etwas zu hoch bewertet wird ;-)

> Jetzt könnte man bestenfalls noch bei abholung durch Fetchmail
> argumentieren das hier (normalerweise) nur eine lokale zustellung statt
> findet und das keinen header erzeugen müsste. Aber, ich wüßte im moment
> auch nicht ob das überhaupt passiert. Und wenn, dann eher durch exim
> "reveived from fetchmail via localhost" oder so...

Fetchmail, ok. Das ist der Empfangsweg. Was da weggefiltert wird dürfte
egal sein. Ist dann ja "nur" noch der eigene Bereich.

>>> Daten wie interne IPs
>> 
>> Wodurch könnten interne IPs gefährlich werden? 
> 
> Ich hab da ein bißchen schräg weiter gedacht. Interne IP werden ja
> regulär eingetragen wenn man von einem internen Client über einen MTA
> sendet. Und wenn; durch welche Umstände auch immer; die Mail in falsche
> Hände gerät (Böze Buben, Spammer, Hacker, NSA, suchdirwasaus) dann haben
> diese schon mal eine IP-range und es ggf. leichter ein zu dringen.

Sind im Regelfall doch nur drei Ranges. Und die werden von aussen nicht
geroutet. Und wenn doch, dann beabsichtigt, dann ist aber festgelegt,
wohin es gehen soll. Oder unbeabsichtigt... Auch dann muss IMO
irgendjemand umsetzen (NAT). Zugegeben, bei IPv6 bin ich mir dann nicht
mehr so sicher.

>>> oder "Pauls-Handy.fritz.box" 
>> 
>> Das ist sowieso bääääh. Das möchte ich in der Message auch nicht stehen
>> haben ;-)
> 
> Dito. :-) Ein Grund mehr einen internen DNS zu haben den der MTA auch
> befragt. Dann steht da evtl. nur xyz.intern.meins.tld oder was auch
> immer. Und auch das kann man ggf. durch ein Muster maskieren, oder
> umschreiben lassen.

Absolut. Wobei die "Vergewaltigung" durch AVM IMO schon grenzwertig
ist.

> So wie meine Artikel zwar von meiner Domain kommen, aber mein nntp host
> einen anderen internen Namen hat der aber nicht im Header auftaucht.

Ich hab' da jetz keine solchen Berührungsängste...

[toc] | [prev] | [standalone]

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

csiph-web