Thanks to all of you for your tips and advices! This turned out to be far more complicated than I thought...
I am staying with spamass-milter and bash scripting for the moment (but implemented all of your programming advices), it's a testing environment only. I'll have a look at amavis as well as going on with python or so. What makes it even more complex is that I need to take into account not only virtual_mailbox_maps and virtual_alias_maps (which could _and_do_ include regex and mailman aliases), but also relay_recipient_maps if the system is a backup mx... However, I created a script that does what I need it to do. It's not a perfect solution, but at least quite okay. For now, it needs to know whether an address was found in virtual_mailbox_maps, is a static or regex alias in virtual_alias_maps or a mailing list alias. So I can't use postconf, but have to configure the script to my needs. And it's able to cope with multiple recipients, and aliases expanding to multiple addresses/aliases. For the moment, I am happy with that ;) Best regards, Robert Am Donnerstag, dem 29.06.2023 um 17:21 +0200 schrieb Robert Senger via Postfix-users: > Hi all! > > I am running Postfix 3.4.23 on Debian 10.13 Buster, with SpamAssassin > 4.0.0 and spamass-milter 0.4.0-2 for spam detection. > > Until now, SpamAssassin was configured to use system wide bayes > database for the bayesian classifier, which is trained by both sa's > autolearn feature and by sa-learn called every time when users move > mails into or out of their Spam folders in dovecot. > > Now I'd like to switch to user specific bayes databases stored in > mysql. Basically, this works. But I am facing problems when static > virtual_aliases or even virtual_aliases defined as regular > expressions > (to enable throw-away wildcard addresses like > <user.name-*@mydomain.com>) come into play. > > The point is that spamassassin needs to know the username when > processing an email, to update the correct bayes database. The > username > given to spamassassin by spamass-milter is the email address of the > recipient. This is fine, as long as an email is sent to the (real) > virtual user. But for any email sent to an alias, spamassassin gets > the > alias address rather than the (real) username, and creates bayes > databases for every alias or evan wildcard address, which is not > desired. > > Now, I've figured out that spamass-milter has an option to run > "sendmail -bv" command, to expands aliases to the real username, and > extract the expanded username from the output of that command. Cool > ;) > > But postfix' "sendmail -bv" command behaves different from the > original. It does not write its results to stdout, but sends an email > to the calling user. This breaks the expansion of virtual_aliases... > > Of course, I could write my own "sendmail" script which takes the > virtual_alias, calls mysql, returns sendmail compatible output to > spamass-milter, and give this script as "path to sendmail" to > spamass- > milter... This is what I did now (see below), and it works. But this > is, to be honest, a really dirty hack, and I must say that I don't > really know what I am doing here... at least I do not know if I open > any bad security holes by passing arguments into mysql without any > checks... > > So, my question is, is there another possibility to expand virtual > aliases to real virtual user names prior to running milters? > > Thanks for help, and sorry if the text above is a bit confuse... > > Regards, > > Robert > > This is my "sendmail -bv" substitute: > > #!/bin/bash > user=`echo "$2" | sed 's/[<>]//g'` > ret=`echo "select destination from virtual_aliases where > source=\"$user\";" | /usr/bin/mysql -upostfix -psecretpassword > mailserver | tail -n 1` > if [ -z "$ret" ]; then > echo "nobody... deliverable: mailer local, user $user" > else > echo "nobody... deliverable: mailer local, user $ret" > fi > -- Robert Senger _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
