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

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

postfix, sasl outgoing mail einrichten?

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

Contents

  postfix, sasl outgoing mail einrichten? Kay Martinen <kay@martinen.de> - 2015-08-22 23:37 +0200
    Re: postfix, sasl outgoing mail einrichten? Siegfried Schmidt <usenet-59@shivasoft.de> - 2015-08-23 00:09 +0000
      Re: postfix, sasl outgoing mail einrichten? Kay Martinen <kay@martinen.de> - 2015-08-23 02:40 +0200
        Re: postfix, sasl outgoing mail einrichten? Burkhard Ott <news2009@derith.de> - 2015-08-23 03:43 +0000
      Re: postfix, sasl outgoing mail einrichten? Marcus Jodorf <trap@killfile.de> - 2015-08-23 23:51 +0200
    Re: postfix, sasl outgoing mail einrichten? Marcus Jodorf <trap@killfile.de> - 2015-08-23 23:48 +0200
      Re: postfix, sasl outgoing mail einrichten? Juergen Ilse <juergen@usenet-verwaltung.de> - 2015-08-24 08:51 +0000
        Re: postfix, sasl outgoing mail einrichten? Marcus Jodorf <trap@killfile.de> - 2015-08-24 21:24 +0200
          Re: postfix, sasl outgoing mail einrichten? Juergen Ilse <juergen@usenet-verwaltung.de> - 2015-08-24 20:49 +0000
            Re: postfix, sasl outgoing mail einrichten? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-08-25 02:45 +0000

#5003 — postfix, sasl outgoing mail einrichten?

Hallo

ich habe mich länger nicht damit befasst und ich blicke wohl noch nicht
richtig durch. Inzwischen kann man ja offenbar mails an einen/mehrere
smarthosts nur noch verschlüsselt oder signiert o.ä. verschicken und
auch dann scheint es fraglich ob das so bleibt... Dank an NSA u. Co. für
ihren Weltmacht-wahn!!!

Ich habe vielleicht immer noch ein Verständniss-problem wo und wie ich
postfix und saslauth einrichte damit mails vom system aus (z.b.
popularity-contest, linux-counter u.a.) über einen smarthost raus gehen.
Meine bisherigen Versuche lt. web-suchen scheiterten mit mir nicht
erklärlichen fehlermeldungen.

Dabei habe ich mehrere Mail-provider und brauche für die dazu gehörigen
mail-adressen wohl auch jew. eigene Smarthost-einträge.

Mir ist es wichtiger erst einmal dieses hin zu bekommen, und sicher zu
stellen das nicht "irgendwelche" mails vom system in alle winde gestreut
werden - bevor ich mich daran mache den anderen Teil mit fetchmail und
lokalem IMAP genauer ein zu richten.

Oder sollte es umgekeht besser sein? Wenn ja, warum?

Das system ist ein debian 64bit und es geht um eine eigene domain und je
eine mail-adr bei T-Online und web.de.

Kay

-- 
https://www.linuxcounter.net/cert/224140.png

[toc] | [next] | [standalone]

#5004

Kay Martinen schrieb:
`
> Oder sollte es umgekeht besser sein? 

Ist unter deinen Mailprovider einer, der für deine Domain zuständig ist? 
em?

Wenn nein, ist das ganze Smarthost-Gedöns ein nachrangiges Problem 
welches dich nicht davor bewahrt, für deine Domain einen eingenen 
Mailversand und Empfang einzurichten.

> Wenn ja, warum?

Weil deine lokal mit deiner Domain erzeugten und für dein lokales 
Postfach bestimmten Mails nichts bei irgendwelchen Smarthosts oder 
Postfächern zu suchen haben, die für deine Domain gar nicht zuständig 
sind. Und ohne externen Transport brauchts dafür auch keine 
Transportverschlüsselung.


Siegfried


-- 
Diese Nachricht kann zukunftsgerichtete Aussagen beinhalten, diese sind 
mit Risiken und Ungewissheiten verbunden und basieren auf gegenwärtigen 
Erwartungen. Die tatsächlichen Ereignisse können daher wesentlich von den 
Darstellungen abweichen.

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

#5005

Am 23.08.2015 um 02:09 schrieb Siegfried Schmidt:
> Kay Martinen schrieb:
> `
> welches dich nicht davor bewahrt, für deine Domain einen eingenen 
> Mailversand und Empfang einzurichten.

Darum geht es ja, die mails von den externen pop3 fächern auf einen
server in meinem internen und privaten lan zu holen. Denn da will ich
sie eigentlich haben, und nur dort.

>> Wenn ja, warum?
> 
> Weil deine lokal mit deiner Domain erzeugten und für dein lokales 
> Postfach bestimmten Mails nichts bei irgendwelchen Smarthosts oder 
> Postfächern zu suchen haben, 

Genau, mails an meine adressen gehören auf meinen eigenen mailserver.
Dazu muss ich sie nur einsammeln. Das ist nicht das problem.


> die für deine Domain gar nicht zuständig sind. 

Ich habe für meine domain ja servernamen beim provider, sowohl für
ankommende, als auch für abgehende mails. Mir geht es um mails die ich
ich von meinem MUA an meinen internen server sende und wie ich die von
dort an den Smarthost beim provider sende - und nur diese.

> Und ohne externen Transport brauchts dafür auch keine 
> Transportverschlüsselung.

Du verstehst jetzt das es mir um den Transport nach Extern geht?

Kay

-- 
https://www.linuxcounter.net/cert/224140.png

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

#5006

On Sun, 23 Aug 2015 02:40:17 +0200, Kay Martinen wrote:

>> die für deine Domain gar nicht zuständig sind.
> 
> Ich habe für meine domain ja servernamen beim provider, sowohl für
> ankommende, als auch für abgehende mails. Mir geht es um mails die ich
> ich von meinem MUA an meinen internen server sende und wie ich die von
> dort an den Smarthost beim provider sende - und nur diese.
> 
>> Und ohne externen Transport brauchts dafür auch keine
>> Transportverschlüsselung.
> 
> Du verstehst jetzt das es mir um den Transport nach Extern geht?

Du brauchst dann eine Transport map wuerde ich sagen, alle email welche 
eine externe domain ansprechen sollen via smarthost gehen, correct?

Falls ja, dann brauchst Du nur eine transport map (http://www.postfix.org/
transport.5.html), dann kannst Du das ueber meherere verteilen.
Also externa.tld geht uber 1.1.1.1, externb.tld geht ueber 2.2.2.2 usw.

cheers

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

#5009

Siegfried Schmidt <usenet-59@shivasoft.de> schrieb:


> Ist unter deinen Mailprovider einer, der für deine Domain zuständig
> ist?  em?
> 
> Wenn nein, ist das ganze Smarthost-Gedöns ein nachrangiges Problem 
> welches dich nicht davor bewahrt, für deine Domain einen eingenen 
> Mailversand und Empfang einzurichten.

Blödsinn.
 
>> Wenn ja, warum?
> 
> Weil deine lokal mit deiner Domain erzeugten und für dein lokales 
> Postfach bestimmten Mails nichts bei irgendwelchen Smarthosts oder 
> Postfächern zu suchen haben, die für deine Domain gar nicht zuständig 
> sind.

Das ist alleine eine Vertrauensfrage. Wenn man dem Smarthost vertraut,
spricht absolut nichts dagegen, den zu verwenden.
Relayhosts sind kein wirklich neues Konzept.


Gruß,

Marcus
⚂⚃

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

#5008

Kay Martinen <kay@martinen.de> schrieb:

> ich habe mich länger nicht damit befasst und ich blicke wohl noch nicht
> richtig durch. Inzwischen kann man ja offenbar mails an einen/mehrere
> smarthosts nur noch verschlüsselt oder signiert o.ä. verschicken

Das ist schon Jahrzehnte so üblich. Offene Relays (absichtlich) gibt es
schon lange nicht mehr.

> Ich habe vielleicht immer noch ein Verständniss-problem wo und wie
> ich postfix und saslauth einrichte damit mails vom system aus (z.b.
> popularity-contest, linux-counter u.a.) über einen smarthost raus
> gehen.  Meine bisherigen Versuche lt. web-suchen scheiterten mit mir
> nicht erklärlichen fehlermeldungen.

Währe vielleicht nicht die schlechteste Idee, die Fehlermeldungen auch
mal zu nennen.

Anyways, mal auf die Schnelle hier für cyrus-sasl (dovecot-sasl wäre
eine weitere Alternative):
apt-get install libsasl2-modules
libsasl2-2 muß dagegen nicht extra installiert werden, da postfix
dependency


/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

Obiges kann auch variieren (z.B. security_options noch mit noplaintext,
was aber auch default ist) - je nachdem, was man erreichen will und wie
relaxed man konfiguriert.

/etc/postfix/transport:
externedomain1.tld          smtp:[smarthost.externedomain1.tld]
externedomein2.tld          smtp:[smarthost.externedomain2.tld]

*                            smtp:[smarthost, der alles annimmt, optional                             als catchall]

/etc/postfix/sasl_passwd:
smarthost.externedomain1.tld    login:password
smarthost.externedomain2.tld    login:password
...

Die eckigen Klammern in transport unterdrücken jeweils MX-Lookups.

postmap für die beiden Dateien dann nicht vergessen!



> Dabei habe ich mehrere Mail-provider und brauche für die dazu gehörigen
> mail-adressen wohl auch jew. eigene Smarthost-einträge.

Nö. Nur wenn der Provider einen Exchange laufen hat oder die Kiste
absichtlich brain-dead restriktiv konfiguriert hat und matching Absender
header erzwingt.
Sonst ist das nicht zwingend und Du kannst auch alles über einen
smarthost, zu dem Du Vertrauen hast, rauskippen.
Dann wird die Config auch simpler, weil man dann fast einfach nur relayhost
konfiguriert.
 
> Mir ist es wichtiger erst einmal dieses hin zu bekommen, und sicher
> zu stellen das nicht "irgendwelche" mails vom system in alle winde
> gestreut werden - bevor ich mich daran mache den anderen Teil mit
> fetchmail und lokalem IMAP genauer ein zu richten.
> 
> Oder sollte es umgekeht besser sein? Wenn ja, warum?

Ich würde ja erst mal den Mailempfang einrichten. Aber spielt nicht
wirklich eine Rolle.

> Das system ist ein debian 64bit und es geht um eine eigene domain und
> je eine mail-adr bei T-Online und web.de.

Könnte sein, daß sie passende Absender erzwingen. Machen Provider in der
Größenordnung ganz gerne. Die Schüssel von t-online hieß zumindest
früher mal securesmtp... und man mußte sich da vorher für freischalten lassen,
wenn ich recht erinnere. Da der Laden mittlerweile aufgelöst und
umgebaut wurde, bin ich da aber nicht auf aktuellem Stand.



Gruß,

Marcus
⚂⚃

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

#5010

Hallo,

Marcus Jodorf <trap@killfile.de> wrote:
> Anyways, mal auf die Schnelle hier für cyrus-sasl (dovecot-sasl wäre
> eine weitere Alternative):
> apt-get install libsasl2-modules
> libsasl2-2 muß dagegen nicht extra installiert werden, da postfix
> dependency
> 
> /etc/postfix/main.cf:
> transport_maps = hash:/etc/postfix/transport
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
> 
> Obiges kann auch variieren (z.B. security_options noch mit noplaintext,
> was aber auch default ist) - je nachdem, was man erreichen will und wie
> relaxed man konfiguriert.
> 
> /etc/postfix/transport:
> externedomain1.tld          smtp:[smarthost.externedomain1.tld]
> externedomein2.tld          smtp:[smarthost.externedomain2.tld]
> 
> *                            smtp:[smarthost, der alles annimmt, optional                             als catchall]
> 
> /etc/postfix/sasl_passwd:
> smarthost.externedomain1.tld    login:password
> smarthost.externedomain2.tld    login:password
> ...
> 
> Die eckigen Klammern in transport unterdrücken jeweils MX-Lookups.
> 
> postmap für die beiden Dateien dann nicht vergessen!
 
Huebsche Anleitung, nur loest sie IMHO ein Problem des OP *nicht*:
Er hat wohl mehrere Mailadressen bei verschiedenen Providern, und
moechte nun ein Mail-Routing abhaengig von der *Absender*-Adresse
(Mail von "*@provider1.tld" sollen ueber mail.provider1.tld laufen,
unabhaengig von der Empfaenger-Adresse, entsprechend Mail von
*.provider2.tld ueber mail.provider2.tld, ebenfalls wieder unab-
haengig von der Empfaenger-Adresse usw.). Das leistet die transport-map
*nicht* (die macht Mail-Routing nach der *Empfaenger-Adresse* der Mails,
also z.B. alle Mails an Empfaenger in der Domain provider1.tld ueber
mail.provider1.tld, und das *unabhaengig* vom Absender ...

Fuer das was er (vermutlich) wuenscht, waere die Verwendung von
"sender_dependent_relayhost_maps" statt von transport vermutlich
zielfuehrender. Ansonsten nette Anleitung, danke.

>> Dabei habe ich mehrere Mail-provider und brauche für die dazu gehörigen
>> mail-adressen wohl auch jew. eigene Smarthost-einträge.
> Nö. Nur wenn der Provider einen Exchange laufen hat oder die Kiste
> absichtlich brain-dead restriktiv konfiguriert hat und matching Absender
> header erzwingt.

Das tun manche Provider wohl *leider*, auch voellig ohne Exchange als
Mailserver. Abgesehen davon kann es ohne "sender_dependent_relayhost_maps"
oder etwas vergleichbares dazu kommen, dass die Mail in einem spam-filter
haengenbleibt, weil die SPF-Eintraege fuer die Absender-Domain nicht zum
verwendeten Relayhost passen ...

> Sonst ist das nicht zwingend und Du kannst auch alles über einen
> smarthost, zu dem Du Vertrauen hast, rauskippen.

.. mit den erwaehnten moeglichen Spamfilter-Problemen aufgrund restriktiv 
gesetzter SPF-Eintraege ...

>> ... bevor ich mich daran mache den anderen Teil mit
>> fetchmail und lokalem IMAP genauer ein zu richten.

Ich habe mich mittlerweile dazu entschlossen, fetchmail zu entsorgen ...
Ich habe es bei mir durch "fdm" ersetzt. Es schien mir ein mindestens 
vollwertiger Ersatz zu sein ...

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)
-- 
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

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

#5011

Juergen Ilse <juergen@usenet-verwaltung.de> schrieb:

> Fuer das was er (vermutlich) wuenscht, waere die Verwendung von
> "sender_dependent_relayhost_maps" statt von transport vermutlich
> zielfuehrender.

Das stimmt natürlich. Ich war wohl gestern nicht mehr ganz wach.
Danke für die Korrektur.


> Abgesehen davon kann es ohne "sender_dependent_relayhost_maps"
> oder etwas vergleichbares dazu kommen, dass die Mail in einem spam-filter
> haengenbleibt, weil die SPF-Eintraege fuer die Absender-Domain nicht zum
> verwendeten Relayhost passen ...

Ja. Das ist dann allerdings eine andere Baustelle unabhängig davon.

Mit passenden Nameservereinträgen kann man erschlagen, wobei das natürlich
nur geht, wenn er eigene Domains für die er die Nameserver kontrolliert
über Relays ausliefert.


> .. mit den erwaehnten moeglichen Spamfilter-Problemen aufgrund
> restriktiv gesetzter SPF-Eintraege ...

Ich war nebenbei gesagt noch nie ein besonders großer Freund von SPF.
Aber stimmt, wenn man es nicht die eigenen Domains sind, kann man da in
Probleme laufen.

> Ich habe mich mittlerweile dazu entschlossen, fetchmail zu entsorgen
> ...  Ich habe es bei mir durch "fdm" ersetzt. Es schien mir ein
> mindestens vollwertiger Ersatz zu sein ...

Hmm. Noch nicht probiert. Hat es denn besondere Vorteile gegenüber
fetchmail?


Gruß,

Marcus
⚂⚃

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

#5012

Hallo,

Marcus Jodorf <trap@killfile.de> wrote:
> Juergen Ilse <juergen@usenet-verwaltung.de> schrieb:
>> Ich habe mich mittlerweile dazu entschlossen, fetchmail zu entsorgen
>> ...  Ich habe es bei mir durch "fdm" ersetzt. Es schien mir ein
>> mindestens vollwertiger Ersatz zu sein ...
> Hmm. Noch nicht probiert. Hat es denn besondere Vorteile gegenüber
> fetchmail?

Nunja, der Entschluss beruhte vor allem darauf, dass zu dem Zeitpunkt als
ich fetchmail aus dem ubuntu12.04 repositorcy fuer meinen Matrix Mini PC 
installieren wollte, die Installation aus irgendeinem Grund nicht funktio-
nierte. Das Programm fdm liess sich jedoch installieren (aus dem selben
repository, war allerdings schon laenger her). Ich hatte daraufhin fdm
eingerichtet und gegenueber fetchmail nichts vermisst (was fetchmail
moeglicherweise mehr kann, benoetige ich nicht). Es gibt aber moeglicher-
weise noch ein Argument fuer fdm:

$ find fetchmail-6.3.26/ -name '*.[ch]' -exec cat {} \; | wc -l
49268

$ find fdm-master/ -name '*.[ch]' -exec cat {} \; | wc -l
21178

(das sind jeweils die aktuellen Sourcen von sourceforge und github)
Bei weniger als halb soviel Source-Zeilen ist moeglicherweise die Chance
grober Fehler auch nicht ganz so gross (OK, ist eher eine fromme Hoffnung).
Bei der Programmgroesse fuer ARM ist der groessenunterschied der binaries
aber deutlich geringer als der der Sourcen:

$ ls -l /usr/bin/fetchmail /usr/bin/fdm
-rwxr-sr-x 1 root root 158464 Aug 24 22:23 /usr/bin/fdm
-rwxr-xr-x 1 root root 186732 Aug 24 22:23 /usr/bin/fetchmail

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)
-- 
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

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

#5013

Juergen Ilse <juergen@usenet-verwaltung.de>:
> moeglicherweise mehr kann, benoetige ich nicht). Es gibt aber moeglicher-
> weise noch ein Argument fuer fdm:

Soweit ich sehe ist fdm ein Ersatz fuer fetchmail und procmail
zusammen (fetchmail ohne procmail ist ja praktisch nutzlos).

Der config-Syntax gefaellt (weniger kryptisch als bei procmail).

[toc] | [prev] | [standalone]

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

csiph-web