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...
With Postfix, the only way to really find out what recipient address(es) it will deliver to, is to a the recipient through Postfix end-to-end. This is because some address mapping happens before a message is queued (smtpd_command_maps, virtual_alias_maps, canonical_maps), and some address mapping happens in delivery agents (alias_maps, .forward, smtp_generic_maps), and all that stuff happens in daemon processes. For this specific problem with virtual alias mapping, a workaround could be to run spamassassin as a post-queue filter, do the virtual alias mapping before a message is queued, and disable address mapping for filtered messages (use receive_override_options as described in https://www.postfix.org/FILTER_README.html). Or perhaps you could run spamassassin before-queue like you do now, and make spamassassin somehow aware of the virtual alias mapping. > This is my "sendmail -bv" substitute: Another possibility might be to look at the comman d exit status from ``postmap -q address mysql:/path/to/file''. This requires permission to read the postfix-mysql configuration file with the password. Either way, if at all possible I would not allow network content near a shell. Don't use bash, use Perl or Python, and invoke command lines as arrays instead of strings. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
