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

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

Re: OT: postfix Frage

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: OT: postfix Frage Stefan Förster <cite@incertum.net> - 2017-11-16 08:53 +0100
    Re: OT: postfix Frage Jan Novak <repcom@gmail.com> - 2017-11-16 11:05 +0100
    Re: OT: postfix Frage Jan Novak <repcom@gmail.com> - 2017-11-17 15:09 +0100
      Re: OT: postfix Frage Stefan Förster <cite@incertum.net> - 2017-11-20 09:39 +0100
        Re: OT: postfix Frage Jan Novak <repcom@gmail.com> - 2017-11-20 13:43 +0100
      Re: OT: postfix Frage "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-11-20 20:48 +0100

#5874 — Re: OT: postfix Frage

* Jan Novak:
> ich hoffe, dass meine Frage nicht zu "off Topic" ist:

Na ja, eigentlich schon. Ich poste das hier mal zusätzlich nach
de.comm.software.mailserver und setze auch den "Followup-To"-Header
dahin. Nachdem ich das seit Ewigkeiten nicht mehr getan habe geht das 
garantiert auch schief ;-)

> Wie kann ich einem in der DMZ stehenden Postfix sagen, dass er bestimmte
> (Mail-)Domänen zu bestimmten anderen Postfix Server leiten soll - UND
> dabei prüft, ob die Empfängeradresse auch tatsächlich existiert (unter
> anderemm, damit er kein offenes relay ist).

Die Antwort ist steht in

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall

Im Prinzip definiert man eine Liste von Domains, für die man Relay
spielen will (Parameter relay_domains), spezifiziert die dort
vorhandenen Empfänger (Parameter relay_recipient_maps) und sagt dann,
wie die Mails ausgeliefert werden sollen (Parameter transport_maps).

Postfix kann die Empfänger(!-Adressen auch verifzieren, sofern man keine
Liste dafür hat:

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient

Hilft Dir das als Ansatz?


Ciao,
Stefan

(xpost&fup2 de.comm.software.mailserver)
-- 
http://www.incertum.net/         OpenPGP: 0x4BAE9B24

[toc] | [next] | [standalone]

#5875

Am 16.11.2017 um 08:53 schrieb Stefan Förster:
> * Jan Novak:
>> ich hoffe, dass meine Frage nicht zu "off Topic" ist:
> 
> Na ja, eigentlich schon. Ich poste das hier mal zusätzlich nach
> de.comm.software.mailserver und setze auch den "Followup-To"-Header
> dahin. Nachdem ich das seit Ewigkeiten nicht mehr getan habe geht das
> garantiert auch schief ;-)
> 
>> Wie kann ich einem in der DMZ stehenden Postfix sagen, dass er bestimmte
>> (Mail-)Domänen zu bestimmten anderen Postfix Server leiten soll - UND
>> dabei prüft, ob die Empfängeradresse auch tatsächlich existiert (unter
>> anderemm, damit er kein offenes relay ist).
> 
> Die Antwort ist steht in
> 
> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
> 
> Im Prinzip definiert man eine Liste von Domains, für die man Relay
> spielen will (Parameter relay_domains), spezifiziert die dort
> vorhandenen Empfänger (Parameter relay_recipient_maps) und sagt dann,
> wie die Mails ausgeliefert werden sollen (Parameter transport_maps).
> 
> Postfix kann die Empfänger(!-Adressen auch verifzieren, sofern man keine
> Liste dafür hat:
> 
> http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
> 
> Hilft Dir das als Ansatz?

Hallo Stefan,

Ich glaube schon. Ich werde es heute im Laufe des Tages versuchen.
Danke vorab.

jan

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

#5877

Am 16.11.2017 um 08:53 schrieb Stefan Förster:

>> Wie kann ich einem in der DMZ stehenden Postfix sagen, dass er bestimmte
>> (Mail-)Domänen zu bestimmten anderen Postfix Server leiten soll - UND
>> dabei prüft, ob die Empfängeradresse auch tatsächlich existiert (unter
>> anderemm, damit er kein offenes relay ist).
> 
> Die Antwort ist steht in
> 
> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
> 
> Im Prinzip definiert man eine Liste von Domains, für die man Relay
> spielen will (Parameter relay_domains), spezifiziert die dort
> vorhandenen Empfänger (Parameter relay_recipient_maps) und sagt dann,
> wie die Mails ausgeliefert werden sollen (Parameter transport_maps).
> Postfix kann die Empfänger(!-Adressen auch verifzieren, sofern man keine
> Liste dafür hat:

Hallo Stefan,

ich habe es jetzt so lösen können, dass die (virtual-)Transport Regel 
greift und die Mails für die eine Domain bei dem dahinter liegenden 
Server landen. Alle anderen Mails werden vom Server selbst bearbeitet.

Als das funktionierte, wollte ich schon "Heureka" rufen ... bis mir einfiel:
Wie kann sich denn ein externer (imap-) Client an dem 2. Server 
authetifizieren und dort die Mails abholen, wenn der smtp/imap/... Port 
auf den 1. Mailserver in der Kette verweisen (auf den, welcher die obige 
Transport Regel bearbeitet).

Dieser müsste das ja dann "durchreichen" anhand einer Domäne ?!

Jan

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

#5878

* Jan Novak:
> Als das funktionierte, wollte ich schon "Heureka" rufen ... bis mir einfiel:
> Wie kann sich denn ein externer (imap-) Client an dem 2. Server
> authetifizieren und dort die Mails abholen, wenn der smtp/imap/... Port
> auf den 1. Mailserver in der Kette verweisen (auf den, welcher die obige
> Transport Regel bearbeitet).
>
> Dieser müsste das ja dann "durchreichen" anhand einer Domäne ?!

Meiner Erfahrung nach schadet es nicht, sich in manchen Fällen nochmal
beschreiben zu lassen, was denn eigentlich das Ziel ist. Was genau hast
Du denn vor? Ich verstehe ja noch, warum ein Mailserver ankommende Mails
an verschiedene Backends (andere Mailserver, z.B. via SMTP, LMTP,
Brieftauben etc.) weiter verteilt - aber warum die Benutzer dann nicht
nur mit besagten Backends, sondern auch mit dem verteilenden Server
selbst sprechen sollen, das erschliesst sich mir gerade nicht.

Magst Du also vielleicht nochmal erzählen, was Du warum vor hast?


Ciao,
Stefan
-- 
http://www.incertum.net/         OpenPGP: 0x4BAE9B24

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

#5879

Am 20.11.2017 um 09:39 schrieb Stefan Förster:
> * Jan Novak:
>> Als das funktionierte, wollte ich schon "Heureka" rufen ... bis mir einfiel:
>> Wie kann sich denn ein externer (imap-) Client an dem 2. Server
>> authetifizieren und dort die Mails abholen, wenn der smtp/imap/... Port
>> auf den 1. Mailserver in der Kette verweisen (auf den, welcher die obige
>> Transport Regel bearbeitet).
>>
>> Dieser müsste das ja dann "durchreichen" anhand einer Domäne ?!
> 
> Meiner Erfahrung nach schadet es nicht, sich in manchen Fällen nochmal
> beschreiben zu lassen, was denn eigentlich das Ziel ist. Was genau hast
> Du denn vor? Ich verstehe ja noch, warum ein Mailserver ankommende Mails
> an verschiedene Backends (andere Mailserver, z.B. via SMTP, LMTP,
> Brieftauben etc.) weiter verteilt - aber warum die Benutzer dann nicht
> nur mit besagten Backends, sondern auch mit dem verteilenden Server
> selbst sprechen sollen, das erschliesst sich mir gerade nicht.
> 
> Magst Du also vielleicht nochmal erzählen, was Du warum vor hast?

Eigentlicher Grund des Problems - nur eine öffentliche IP.

Es gibt einen Server für diverse Domänen, auf welchem neben Postfix auch 
dovecot und webmail usw läuft.

Ein 2. Server soll nur eine Domäne verwalten und nutzt hierfür UCS - 
also alles in einem (Postfix/dovecot/Webmail, Kopano mit Activ Sync, 
LDAP usw).

Dieser UCS Server hat aber nichts mit den anderen Domänen zu tun.

Hinzu kommt, dass der gesamte Web Traffic durch einen web Proxy geht und 
dann erst auf den jeweiligen Servern landet. Das der dort befindliche 
nginx erkennt, welche Domäne aufgerufen wird, gibt er deb Web Traffic 
dann weiter an Server 1 oder 2. Das funktioniert auch soweit problemlos.

Letztendlich würde ich gerne das gleiche mit "mail" traffic machen, wie 
der Web Proxy mit Web traffic.

Jan

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

#5880

On 2017-11-17 14:09, Jan Novak <repcom@gmail.com> wrote:
> ich habe es jetzt so lösen können, dass die (virtual-)Transport Regel 
> greift und die Mails für die eine Domain bei dem dahinter liegenden 
> Server landen. Alle anderen Mails werden vom Server selbst bearbeitet.
>
> Als das funktionierte, wollte ich schon "Heureka" rufen ... bis mir einfiel:
> Wie kann sich denn ein externer (imap-) Client an dem 2. Server 
> authetifizieren und dort die Mails abholen, wenn der smtp/imap/... Port 
> auf den 1. Mailserver in der Kette verweisen (auf den, welcher die obige 
> Transport Regel bearbeitet).

Das Problem für SMTP hast Du ja gelöst. FÜr IMAP und Submission (also
wenn ein Client eine Mail schickt, nicht wenn ein MTA an anderen eine
Mail schickt) bräuchtest Du eine Art Proxy. Für Submission könnte man
das wohl relativ leicht (mit ein bisschen Perl-Kenntnissen) mit
qpsmtpd basteln, aber Imap fällt mir nichts ein. Da es aber nur ein
lokales Problem ist, kann man das auch lokal lösen: einen anderen Port
verwenden (z.B. 10143 statt 143 für IMAP und 10587 statt 587 für
Submission) und die Clients entsprechend konfigurieren. Oder Zugriff
über ein VPN gestatten, dann hast Du auch mehrere IP-Adressen.

        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] | [standalone]

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

csiph-web