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

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

SRS mit Exim in Debian

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

Contents

  SRS mit Exim in Debian Paul Muster <exp-311216@news.muster.net> - 2016-05-27 19:02 +0200
    Re: SRS mit Exim in Debian Thomas Hochstein <thh@inter.net> - 2016-05-28 15:29 +0200
      Re: SRS mit Exim in Debian Frank Elsner <frank.elsner@spamfence.net> - 2016-06-08 12:57 +0200
        Re: SRS mit Exim in Debian dseppi@a1.net (David Seppi) - 2016-06-08 14:06 +0000
        Re: SRS mit Exim in Debian Thomas Hochstein <thh@inter.net> - 2016-06-08 21:11 +0200
    Re: SRS mit Exim in Debian Frank Elsner <frank.elsner@spamfence.net> - 2016-06-08 12:52 +0200
      Re: SRS mit Exim in Debian Thomas Hochstein <thh@inter.net> - 2016-06-08 21:38 +0200
        Re: SRS mit Exim in Debian Andreas Barth <aba+nospam@not.so.argh.org> - 2016-06-09 09:43 +0000

#5408 — SRS mit Exim in Debian

Hallo,

wie in de.comm.provider.mail deutlich wird, hat kürzlich GMX (oder 
United Internet komplett, keine Ahnung) inbound die Prüfung von 
SPF-Records scharfgeschaltet. D.h. es werden E-Mails von Absendern, zu 
deren Domain entsprechende SPF-Einträge im DNS existieren, von GMX nur 
noch diesen Einträgen gemäß akzeptiert.

Nun habe ich mit meinem Exim einige Weiterleitungen realisiert, d.h. ich 
brauche jetzt SRS. (Oder ich kann nichts mehr zu GMX weiterleiten.)

Hat jemand dafür ein funktionierendes, erprobtes Kochrezept oder kann 
einen der - durchaus vorhandenen - Suchtreffer empfehlen?


Danke & viele Grüße

Paul

[toc] | [next] | [standalone]

#5409

[Multipart message — attachments visible in raw view] — view raw

Paul Muster schrieb:

> Nun habe ich mit meinem Exim einige Weiterleitungen realisiert, d.h. ich 
> brauche jetzt SRS. (Oder ich kann nichts mehr zu GMX weiterleiten.)

Ja, das Thema hatte ich 2012 ...

(Freu Dich darauf, wenn auch der From: geprüft wird, wie das
mittlerweile wohl hotmail/live/outlook.com und andere machen. Ich
musste mich gerade für einige Mailinglisten darum kümmern ... Das geht
dann nicht mehr mit Bordmitteln und ohne Seiteneffekte).

> Hat jemand dafür ein funktionierendes, erprobtes Kochrezept oder kann 
> einen der - durchaus vorhandenen - Suchtreffer empfehlen?

Ich habe das, wie gesagt, 2012 unter Debian Wheezy implementiert; ich
nutze allerdings nicht die Debian-typische "split config" für Exim,
sondern eine monolitische Konfigurationsdatei, und zwar die vom
Upstream mitgelieferte, ohne die ganzen Konfigurationsmakros. Das
dürfte aber keinen Unterschied machen, Du musst halt ggf. die richtige
Stelle in der richtigen Datei finden, um die Router einzufügen.

SRS funktioniert so: die Mail bekommt einen neuen Envelope-Absender
mit einer Deiner Domains und einem Localpart, in dem die alte
Absenderadresse einkodiert ist, und zwar so, dass nur Du gültige
Localparts dieser Art erzeugen kannst. Das Weiterleitungsziel sieht
jetzt "aha, eine Mail mit einem Absender aus der Domain xyz kommt von
einem Rechner, der für die Domain xyz senden darf, alles okay".
Bounced eine Mail doch mal, kannst Du die ursprüngliche Adresse aus
dem Localpart extrahieren und den Bounce weitersenden.

Ich nutze den srsd und zwei passende Router; einmal, um Bounces an den
echten Absender weiterzuleiten, und einmal, um den Envelope
ausgehender Mails umzuschreiben.

----------------------------------------------------------------------

Als Kochrezept - geht bestimmt professioneller, tut aber für mich -:

1) srsd installieren

| $ aptitude install srs

Ich habe mir damals dafür im wesentlichen per copy&paste noch ein
Initscript angelegt, damit er automatisch gestartet wird. Das macht
man sicherlich besser anders ...

Das ging dann so:
| $ vim /etc/init.d/srsd
[siehe Anhang für das Scrit]
| $ chmod 755 /etc/init.d/srsd
| $ update-rc.d srsd defaults

SRS basiert darauf, dass nur Du ein geheimes Token kennst, mit dem der
neue Envelope-Absender erzeugt wird, damit der Spammer das nicht kann.
Also brauchen wir ein "Geheimnis":

| $ openssl rand -base64 12 > /etc/exim4/srsd.secret

----------

2) Exim konfigurieren

In dem Teil der Exim-Config, der mit
| ######################################################################
| #                      ROUTERS CONFIGURATION                         #
| #               Specifies how addresses are handled                  #
| ######################################################################
| #     THE ORDER IN WHICH THE ROUTERS ARE DEFINED IS IMPORTANT!       #
| # An address is passed to each router in turn until it is accepted.  #
| ######################################################################
|
| begin routers
beginnt, sollten als erstes (!) die beiden folgenden Router stehen.

Erst einmal der für Bounces (also für Mails, die an eine per SRS
umgeschriebene neue Absenderddresse aus Deiner Domain gehen):

| # SRS routers have to executed first
| # Rewrite incoming bounces to original address
| srs_bounce:
|   debug_print = "R: srs_bounce for $local_part@$domain"
|   driver = redirect
|   allow_fail
|   allow_defer
|   domains = $primary_hostname
|   local_part_prefix = srs0+ : srs0- : srs0= : srs1+ : srs1- : srs1=
|   caseful_local_part
|   address_data = ${readsocket{/tmp/srsd}{REVERSE $local_part_prefix$local_part@$domain}{5s}{\n}{:defer: SRS daemon failure}}
|   data = ${if match{$address_data}{^ERROR}{:fail: Invalid SRS address}{$address_data}}

Das setzt voraus, dass Du Deinen Hostnamen ($primary_hostname - muss
ggf. in der Config gesetzt werden) für die Generierung der neuen
Absender verwendest. Heißt Dein Rechner also blabla.muster.net, würden
Adressen der Form irgendwas@blabla.muster.net erzeugen. Natürlich
kannst Du stattdessen auch irgendwas@muster.net oder sonst etwas
nehmen; Du musst nur im nächsten Router dieselbe Variante wählen wie
hier, und Mail an Adressen dieser Domain sollte diesen Exim (oder
einen anderen, identisch konfigurierten, durchlaufen).

| # Rewrite envelope sender for outgoing mail
| # (but not for sender adresses from one of the local domains)
| srs_forward:
|   debug_print = "R: srs_forward for $local_part@$domain"
|   no_verify
|   senders = ! : ! *@+local_domains
|   address_data = ${readsocket{/tmp/srsd}\
|                 {FORWARD $sender_address_local_part@$sender_address_domain $primary_hostname\n}\
|                                         {5s}{\n}{:defer: SRS daemon failure}}
|   errors_to = ${quote_local_part:${local_part:$address_data}}@${domain:$address_data}
|   headers_add = "X-SRS: Sender address rewritten from <$sender_address> to <${quote_local_part:${local_part:$address_data}}@${domain:$address_data}> by $primary_hostname."
|   driver = redirect
|   repeat_use = false
|   allow_defer
|   data = ${quote_local_part:$local_part}@$domain

"headers_add" ist natürlich optional.

Wo in address_data "$primary_hostname" steht, muss dasselbe stehen,
was Du im vorherigen Router bei "domains" hast.

Du musst zudem darüber nachdenken, bei welchen (!) Mails Du den
Envelope-Sender umschreiben willst. Ziemlich sicher nicht bei denen,
deren Absender aus einer Deiner Domains kommt. Ich habe das hier durch
"senders" gelöst; lokal generierte Mail (also ohne Envelope-Sender)
und solche mit einem Envelope-Sender aus einer der Domains, für die
die Maschine Mail annimmt, werden nicht umgeschrieben. Das kann für
Dich so passen, muss aber nicht.

(Realiterist dieser Router bei mir zudem duch "domains" auf exakt eine
Domain beschränkt, denn nur in dieser habe ich solche "naiven
Forwarder" eingerichtet.

----------------------------------------------------------------------

Kommentare dazu gerne. Ich würde das nicht als Weisheit letzter
Schluss bezeichnen; es war ein schneller Hack für eine bestimmte
Situation, in der eine Lösung eilig war, danach habe ich das nicht
mehr angefasst. Es tat aber, und soweit ich sehe, tut es auch noch
heute.

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

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

#5413

On 28.05.2016 15:29, Thomas Hochstein wrote:

  [ ... ]

> SRS funktioniert so: die Mail bekommt einen neuen Envelope-Absender
> mit einer Deiner Domains und einem Localpart, in dem die alte
> Absenderadresse einkodiert ist, und zwar so, dass nur Du gültige
> Localparts dieser Art erzeugen kannst. Das Weiterleitungsziel sieht
> jetzt "aha, eine Mail mit einem Absender aus der Domain xyz kommt von
> einem Rechner, der für die Domain xyz senden darf, alles okay".
> Bounced eine Mail doch mal, kannst Du die ursprüngliche Adresse aus
> dem Localpart extrahieren und den Bounce weitersenden.

Ich halte das Verfahren für rechtlich bedenklich. Wenn eine Domain
in ihrem SPF-Record ein "-all" hat, will sie die Weiterleitung verhindern.
Und das ist zu repektieren. (Envelope-)From umschreiben ist für mich
Adressfälschung.


--Frank Elsner

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

#5414

Frank Elsner schrieb:

> Ich halte das Verfahren für rechtlich bedenklich. Wenn eine Domain
> in ihrem SPF-Record ein "-all" hat, will sie die Weiterleitung verhindern.

Nein. Die wollen, daß ihre Domain nicht mißbraucht wird.

> Und das ist zu repektieren. (Envelope-)From umschreiben ist für mich
> Adressfälschung.

Uhm ... wenn ich Mails an mich sebst weiterleite:
Wo ist da eine Fälschung?
Mailinglisten machen auch erkennbar, daß es sich
um eine Listenmail handelt.

-- 
David Seppi
1220 Wien

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

#5416

Frank Elsner schrieb:

> Ich halte das Verfahren für rechtlich bedenklich. Wenn eine Domain
> in ihrem SPF-Record ein "-all" hat, will sie die Weiterleitung verhindern.

Aber keineswegs - das wäre ja auch eine ziemlich blödsinnige
Überlegung: wen interessiert es gesteigert, wie der Empfänger seine
Mail intern verarbeitet? Sie will vielmehr verhindern, dass Unbefugte
Mail mit ihrer Domain als Absender versenden. Das - nämlich vorgeben
zu können, von welchem Servern legitime Mail "aus dieser Domain",
sprich, mit einer Adresse innerhalb dieser Domain als Absender - ist
der Zweck von SPF.

> Und das ist zu repektieren.

Zu respektieren ist der Wunsch, keine Mail mit Absenderadressen zu
versenden, über die man nicht verfügen darf, ja, wobei die
Weiterleitung einer Mail m.E. dabei unproblematisch ist.

> (Envelope-)From umschreiben ist für mich Adressfälschung.

Wieso das? Der Envelope-From ist die technische Angabe des Absenders
und steuert konkret, wohin Fehlermeldungen gehen, wenn die E-Mail
nicht zustellbar ist. Und die sollen bei einer Mail, die ich
weiterleite, an mich gehe; ich sorge dann schon dafür, dass sie ggf.
weitergeleitet werden.

Zudem ist diese "Adressfälschung" seit Jahrzehnten das Prinzip, nach
dem Mailinglisten funktionieren ...

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

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

#5412

On 27.05.2016 19:02, Paul Muster wrote:
> Hallo,
> 
> wie in de.comm.provider.mail deutlich wird, hat kürzlich GMX (oder United Internet komplett, keine Ahnung) inbound die Prüfung von SPF-Records scharfgeschaltet. D.h. es werden E-Mails von Absendern, zu deren Domain entsprechende SPF-Einträge im DNS
> existieren, von GMX nur noch diesen Einträgen gemäß akzeptiert.
> 
> Nun habe ich mit meinem Exim einige Weiterleitungen realisiert, d.h. ich brauche jetzt SRS. (Oder ich kann nichts mehr zu GMX weiterleiten.)
> 
> Hat jemand dafür ein funktionierendes, erprobtes Kochrezept oder kann einen der - durchaus vorhandenen - Suchtreffer empfehlen?

https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf


--Frank Elsner

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

#5415

Frank Elsner schrieb:

>> Nun habe ich mit meinem Exim einige Weiterleitungen realisiert, d.h.
>> ich brauche jetzt SRS. (Oder ich kann nichts mehr zu GMX
>> weiterleiten.)
>>
>> Hat jemand dafür ein funktionierendes, erprobtes Kochrezept oder kann
>> einen der - durchaus vorhandenen - Suchtreffer empfehlen?
>
> https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf

Da findet sich kein Rezept - und auch keine Anleitung - für die
Realisierung von SRS mit Exim. Insofern ist diese in den Raum
geworfene URL weder eine Antwort auf die Frage noch sonst besonders
hilfreich.

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

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

#5417

Thomas Hochstein wrote:
> Da findet sich kein Rezept - und auch keine Anleitung - für die
> Realisierung von SRS mit Exim. Insofern ist diese in den Raum
> geworfene URL weder eine Antwort auf die Frage noch sonst besonders
> hilfreich.

Jo.

http://www.infradead.org/rpr.html funktioniert hingegen gut.


Viele Grüße,
Andi

[toc] | [prev] | [standalone]

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

csiph-web