[Postfixbuch-users] dovecot wiedermal

[Stefan Förster]

* Peer Heinlein <p.heinlein at heinlein-support.de>:
> Am Samstag, 24. April 2010 00:36:08 schrieb Stefan Förster:
> > > (privat): Wo ist er Unterschied zwischen Exchange und Dovecot?
> > 
> > Exchange kann ich via SMTP ansprechen 
> 
> Ja, aber was interessiert das Postfix?
> 
> (Dovecot 2.0 kann man über LMTP ansprechen.)

Ich habe zu Dovecot's LMTP-Unterstützung mal ein paar
Performance-Tests durchgeführt und auf der dovecot-ML veröffentlicht -
das sieht wirklich vielversprechend aus.

> > und damit
> > reject_unverified_recipient verwenden?
> 
> Ja, aber was hat das mit dem Unterschied zwischen virtual- und 
> relay_domains zu tun?

Nichts? Du wolltest Unterschiede hören.

> > Ich verstehe wirklich nicht, wieso Du das immer so predigst. Ich
> > tausche virtual(8) durch deliver(8), und plötzlich soll ich unbedingt
> > eine andere Adressenklasse (was ein Wort!) verwenden?
> 
> *) Weil dann alle Systeme überall gleich aufgebaut sind, egal ob Cyrus, 
> Dovecot, Exchange oder sonstwas

Kann man so stehen lassen, ja.

> *) Weil es dann noch immer lokale Systemnutzer gibt und Cron-Mails oder 
> mails an root at localhost bouncen, da man /etc/passwd defacto schachmatt 
> gesetzt hat

Das verstehe ich überhaupt nicht. Es ist doch egal, ob ich die Domains
als relay_domains oder virtual_mailbox_domains abfrühstücke, mit
lokalen Adressen haben beide nichts zu tun.

> *) Weil es zukunftssicher ist und man dann bei Dovecot 2.0 zukünftig mit 
> einem Handstreich nur noch deliver durch LMTP ersetzen muß ohne daß 
> einem dann das ganze gewachsene Setup um die Ohren fliegt

Von virtual_mailbox_(domains|maps) mit geeigneten Lookups auf
relay_domains zu migrieren ist ja wohl keine große Sache:

1. virtual_mailbox_domains und relay_domains können exakt die gleiche
Map benutzen.
2. Wenn man deliver(8) verwendet, sind die Lookup-Ergebnisse aus
virtual_mailbox_maps sowieso egal, also kann man auch hier die gleiche
Map für relay_recipient_maps verwenden.
3. Die restlichen Settings wie z.B. virtual_[ug]id_maps oder
virtual_mailbox_maps kann man weglassen.
4. Statt virtual_transport=dovecot könnte man einfach
relay_transport=dovecot setzen. Hat man sowieso schon transport_maps
verwendet, ist gar keine Umstellung notwendig.

Den Punkt lasse ich glaub' nicht gelten ;-)

> *) Weil man dann ganz einfach und transparent auch Setups konfiguriert, 
> wo es viele (=beliebig viele) Domains gibt und man sich dann nicht mit 
> dem dirty hack virtual einen abkrepelt

Ich habe keine Ahnung, wovon Du redest.

> *) Weil man bei der Verwendung relay_domains im Prinzip auf allen Nodes 
> überall die gleichen Informationen und Dateien hat, ganz gleich ob MX-
> Relay oder IMAP-Server. Wenn man's richtig macht sind alle Nodes in 
> Postfix *absolut* identisch konfiguriert (ja, das geht, ldap_filter 
> macht's möglich!). Ich sehe nicht ein, wieso man eine Domain auf einem 
> MX-Relay komplett unterschiedlich behandeln soll (relay_domains) als auf 
> dem IMAP-Server (plötzlich komplett anderer Aufbau über virtual). Ich 
> brauch doch keine ABM-Maßnahme und will alles doppelt, aber 
> unterschiedlich pflegen!

Siehe den Punkt oben, das ist doch großteils eh austauschbar. Und
irgendwo _wirst_ Du etwas unterschiedliches hinterlegen müssen ;-)

> *) Weil ich Setups habe, wo ich mehrere unterschiedlich konfigurierte 
> Deliver-Prozesse brauche und das mit virtual-Krams nicht geht

Das stimmt doch gar nicht. transport_maps überschreiben immer das
transport:nexthop-Routing, auch für virtual_mailbox_domains.

> und und und und und. Ich brech jetzt mal an der Stelle ab.

Ich könnt' jetzt ja was sagen ;-)

> > Das einzig glücklich machende ist sie jedoch nicht.
> 
> Nö, aber wenn mich jemand fragt, wie er es aufbauen soll, dann ist das 
> eben mein Rat. Das ist aber hier definitiv der Weg, der am 
> "zukunftssichersten" ist und wo nicht alles WIRKLICH kompliziert wird, 
> wenn mal die Anforderungen steigen. Und eben auch der Weg, wo man sich 
> im Einklang mit allen anderen Varianten wie Exchange- und Cyrus befindet 
> und man eben möglichst transparent Unterstützung an anderer Stelle 
> kriegen kann.

Und das ist jetzt der von Deinen Punkten, die mich am meisten
überzeugen.


"No offense intended"
Stefan