[Postfixbuch-users] virtual_alias und catch-all
Thomas Walter
list+postfixbuch-users at b-a-l-u.de
Mi Mai 19 16:11:12 CEST 2010
Hiho,
Am 19.05.10 10:02, schrieb Peer Heinlein:
> Weil es auch Möglichkeiten gibt, wo er das dann trotzdem noch ablehnen
> kann. Wenn später per reject_unverified_recipients die Validierung
> gemacht wird, so würde der das (wenn ich nicht irre) ja nach der
> Umschreibung anstoßen und dann (glaube ich) auch noch bei Catch-Alls
> sauber ablehnen können.
Ich habe hier gerade dasselbe Problem. Um "Aliasdomains" (example.com,
example.de, usw.) abzudecken, gibt es eine extra Tabelle in der
Datenbank, über die eine Aliasdomain mit der Hauptdomain verknüpft
werden kann.
Die Abfrage ist dann ungefähr so:
SELECT CONCAT('%u', '@', domains.name)
FROM domainaliases, domains
WHERE domain_id=domains.id
AND domainaliases.name="%d"
Das liefert dann bekannt at aliasdomain auch an bekannt at hauptdomain aus.
Das Problem ist, dass auch unbekannt at aliasdomain an
unbekannt at hauptdomain gemappt wird. Postfix nimmt die Mail dann an und
erkennt erst später, dass die Zustellung eher schwierig wird und
versucht einen Bounce zu senden.
Und damit bin ich in der Backscatter-Falle.
> Das Problem wird etwas minimiert wenn man sowas eh nur für Domains
> macht, die wirklich nie benutzt werden: Also Schreibweisenvarianten der
> Haupt-Domain. Wenn es also wirklich nur um Absender geht, die sich mal
> vertippt haben. Dann tritt da in der Praxis eimnfach kein Problem auf.
Es reicht leider, wenn die Domain irgendwo im Web auftaucht oder mal
verlinkt wurde. Sobald der erste Spamcrawler die erkannt hat, geht es
gleich los mit den ülichen verdächtigen wie office@, root@, info@, usw.
> Würde ich mir auch wünschen und ich muß gestehen, daß ich bis heute
> nicht verstanden habe, warum das nicht anders umgesetzt werden kann.
Gut, dann bin ich nicht der einzige. Vielleicht kann Wietse uns das auf
der nächsten Mailserverkonferenz mal bei einem Bier erklären ;).
Ich überlege jetzt, ob ich die Abfrage oben erweitere, so dass noch
geprüft wird, ob die gefundene Adresse in der Postfach-Tabelle oder in
der Alias-Tabelle vorkommt.
Das würde dann aber zu einer solchen Monsterabfrage führen:
SELECT email FROM mailusers WHERE email=
(SELECT CONCAT('%u', '@', domains.name)
FROM domainaliases, domains
WHERE domain_id=domains.id
AND domainaliases.name="%d")
UNION SELECT destination FROM mailaliases WHERE email=
(SELECT CONCAT('%u', '@', domains.name)
FROM domainaliases, domains
WHERE domain_id=domains.id
AND domainaliases.name="%d")
Kennt hier einer MySQL gut genug, um mir sagen zu können, wie ich die
beiden - identischen - Unterabfragen zusammenfassen kann - oder ob ich
das überhaupt muss?
Würde die Änderung der Abfrage überhaupt etwas an dem Problem ändern
oder letztendlich zu anderen Problemen führen?
Oder ist es besser, auf reject_unverified_recipients zu setzen (und
hinter reject_unknown_recipient_domain zu ergänzen)?
Vielleicht ist es auch sinnvoll, beides zu machen, um unnötige
Verification-Tests zu vermeiden?
Balu
Mehr Informationen über die Mailingliste Postfixbuch-users