[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