[Postfixbuch-users] local delivery (Cyrus-IMAPd) / catch-all

[Stefan Kraemer]

Hallo Liste!

Da es sein koennte, dass meine Recherche in div. Suchmaschinen usw. nicht
sorgfaeltig genug ausgefallen ist und das Thema (wie ja so oft) schon x-mal
besprochen wurde, waere ich auch ueber entsprechende Verweise sehr dankbar.

Irgendwie stehe ich bei folgendem Problem auf'm Schlauch (OK, vielleicht
liegt's auch langsam an der Uhrzeit).

---------------------------------------
 Postfix + MySQL-Lookups + Cyrus-IMAPd
---------------------------------------

Auf frueheren Systemen habe ich soetwas immer per "virtual_maps" 

  "abc at domain.tld --> xyc at otherdomain.tld" bzw.
  "abc at domain.tld --> <cyrus-user>"

und "mailbox_transport"

  "lmtp:unix:/var/imap/socket/lmtp"

konfiguriert. Auch ein "@domain.tld" in der "virtual_map", also ein
"catch-all" funktionieren dort einwandfrei. Nun lernt man auch dazu und
entschliesst sich alles neu zu machen, in diesem Fall nach:

  http://www.postfix.org/VIRTUAL_README.html#in_virtual_other

System laeuft, Lookups sind erfolgreich ... alles prima.

[ -- main.cf ----------------------------------------------------------- ]
virtual_mailbox_domains =
  mysql:/usr/local/etc/postfix/maps/mysql/virtual_mailbox_domains

virtual_mailbox_maps =
  mysql:/usr/local/etc/postfix/maps/mysql/virtual_mailbox_maps

virtual_alias_maps =
  mysql:/usr/local/etc/postfix/maps/mysql/virtual_alias_maps

virtual_transport =  
  lmtp:unix:/var/imap/socket/lmtp

# mailbox_transport =
#   lmtp:unix:/var/imap/socket/lmtp
[ ---------------------------------------------------------------------- ]

Der "virtual_mailbox_domains"-Lookup funktioniert auch. Jetzt frage ich
mich nur, wie es sich mit dem Rest verhaelt.

In der "virtual_mailbox_maps"-Tabelle werden (nach oben genanntem Link) ja
alle erreichbaren "Adressen" gelistet. Auch dies funktioniert soweit und
ich erhalte ggf. entsprechende 550-Fehler. Nun lautet meine erste Frage:
Muessen hier auch lokale Mailboxen eingetragen werden, also z.B. lediglich
ein "<user>", also nicht wie ueblich "abc at domain.tld"? Was ist dann mit
Benutzern, welche uber "<user>@<mailhost>.tld" adressiert werden?

Letztlich stellt sich mir, nein stelle ich euch noch die Frage, wie ich
"catch-all's" definiere? In der genannten Dokumentation wird beschrieben,
dass man zunaechst in der "virtual_mailbox_map" einen "@domain.tld"-Eintrag
vornehmen soll, was auch einleuchtet (damit die Anfragen nicht abgewiesen
werden), jedoch wird im gleichen Zug gesagt, dass man keine entsprechenden
Eintraege in der "virtual_alias_map" vornehmen darf ("...  NEVER put a
virtual MAILBOX wild-card in the virtual ALIAS file!! ...") und man
entsprechend den lokalen Mailbox-Dienst (also in diesem Fall Cyrus) so
konfigurieren soll, dass er alle Adressen annimmt, aber das ist wohl eher
Bloedsinn bzw. so gemeint, dass die Adressen vorher (auf den Benutzer)
umgeschrieben werden muessen, nur WIE?!

Alle Versuche enden bei mir damit, dass die E-Mails nicht an den richtigen
Ralay, also den "virtual_transport" (LMTP) uebergeben werden und mit
"status=bounced (unknown user: "xyz")" bouncen.

Noch gemeiner: Mit dem oben auskommentierten "mailbox_transport" gehts dann
wieder, was aber laut der Doku nicht korrekt ist und darueberhinaus auch
nicht das erstgenannte Problem loest.

Hoffe ist irgendwie klar geworden wo's haengt. ;-)

Vielleicht hat ja der ein oder andere auch schon solch eine Konstellation
am laufen (wie die Lookups geschehen ist natuerlich wurscht) und waere
bereit mir seine Konfiguration zur Verfuegung zu stellen. Wenn sogar jemand
SQL-Lookups verwendet waere diesbezueglich auch ein Struktur-Dump
interessant.


Dank euch im voraus!

Gruss, der Stefan

-- 
Stefan Kraemer <mail at skraemer.net>
GPG/PGP-Key: http://www.skraemer.net/
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 187 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20050206/3590e9a7/attachment.sig>