On Fri, Jul 21, 2023 at 05:06:07PM -0700, Grant Keller wrote: > > > > select username, value from userpref > > where username = _USERNAME_ or username = '@GLOBAL' > > order by username asc; > I don't think the query result order masters here, from what I could > gather in the spamassassin source, the welcome list is built in 2 > steps: > 1. Create the list using the whitelist_from values. > 2. Remove from that list everything in unwhitelist_from
Clearly you didn't read the code well enough. There is no such buffering done. The order matters as configuration commands are evaluated line by line. It is no different from reading a physical file. Command order 1: unwhitelist_from grant.kel...@sonic.com - there is no existing grant.kel...@sonic.com in the list, so nothing can be removed, this command is ready never looked at again whitelist_from grant.kel...@sonic.com - address is added and kept in the list, which is why you see USER_IN_WELCOMELIST Command order 2: whitelist_from grant.kel...@sonic.com - address added to the list unwhitelist_from grant.kel...@sonic.com - address is removed from the list You are seeing the first case happening here. > > As you see the only sort is done with username and otherwise MySQL makes > > _no_ guarantees about returned order. If whitelist_from is returned last, > > it works exactly the same as a physical .cf file would have it last. Why do > > you have an obviously redundant whitelist_from in the table messing up > > things? > It isn't redundant, it is just the simplest case I could use for > troubleshooting. The original case I was having issues with was more > like this: > | gvk | unwhitelist_from | grant.kel...@sonic.com | 7421538 | > | gvk | whitelist_from | *@sonic.com | 7526210 | > Which had the same problem as the values for both being identical, I was > just trying to narrow down the issue. You would have been better off looking at the documentation than code. As it clearly states: "The specified email address has to match exactly (although case-insensitively) the address previously used in a welcomelist_from line, which implies that a wildcard only matches literally the same wildcard (not 'any' address)." Above example will always have whitelist_from *@sonic.com active, thus resulting in USER_IN_WELCOMELIST. To unwhitelist it you need unwhitelist_from *@sonic.com.
