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
> ) 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
