[Postfixbuch-users] amavisd-new-Intergation: forward_method aus Lookup?

[Stefan Förster]

Am 29.05.2008 um 21:32 schrieb Peer Heinlein:

> Am Donnerstag, 29. Mai 2008 schrieb Stefan Förster:
>> Wir sind noch in einem sehr frühen Evaluierungs-Stadium, evtl. ist  
>> die
>> dspam-Integration in amavisd-new ja sehr viel leistungsfähiger, so
>> daß wir da normal mit bypass_spam_checks-Maps arbeiten können, bisher
>> scheint für uns aber der einzige Weg zu sein, nach dem amavisd-new
>> eine Reinjection an eine Postfix-Instanz vorzunehmen und dort mit
>> FILTER das Forwarding an dspam zu machen. Geht das einfacher?
>
> Was ist denn jetzt erstmal genau das Ziel...? Einfach nur Nutzer zu
> definieren, deren Mails nicht nach Spam gefiltert werden?
>
> Dann geht das sehr einfach über bypass_spam_check_maps:
>
>
> @bypass_spam_checks_maps = ( [qw( domain1.de domain2.de
> user at domain3.de  )])
>
> Ansonsten sagdoch bitte nochmal genau, was Ihr *genau* wollt. Es ist
> manchmal immer sehr schwierig aus einer angefragten Lösung das  
> eigentlich
> erwünschte Setup herauszulesen :-)

Es geht ganz konkret um das, was Du gesagt hast. Allerdings filtern  
wir nicht mit Spamassassin, sondern eben mit dspam. Aufgerufen wird  
der, wie bereits beschrieben, indem ihm die Nachrichten via LTMP von  
amavis aus übergeben werden - und da greifen die von Dir gennannten  
Einstellungen halt mal gar nicht :-) Ganz abgesehen davon, daß die  
Spam-Checks sowieso deaktivert sind.

Wir wollen also genau das, was ich beschrieben hatte: Eine Methode, ob  
man amavisd-new via Lookup mitteilen kann, welche $forward_method er  
benutzen soll. In einer beliebigen Datenbank wird dabei an zentraler  
Stelle vermerkt, welche Mailboxen auf Spam gefiltert werden sollen.  
Abhängig von diesem Setup soll die Reinjection von amavisd-new aus  
entweder direkt via (E)SMTP zu einem Postfix-smtpd oder aber via LMTP  
zu dspam erfolgen. Ich weiß jetzt nicht, was ich da noch genauer  
beschreiben soll, wir haben in das Setup einiges an Hirnschmalz  
investiert und haben gute Gründe, dspam auf diese Art einzubinden  
(n.b., dspam, nicht spamd).

Und ja, man kann jetzt argumentieren daß man das ganze auch in dspam  
abhandeln kann. Dagegen spricht im konkreten Fall die von uns  
angestrebte Struktur der Datenbank (oder LDAP, das wissen wir auch  
noch nicht so genau) - bzw. die Scheu davor, diese unnötig aufzublähen.


Ciao
Stefan
-- 
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
Mac OS X ate my ~/.signature.