On 17.05.14 14:11, Jeff Mincy wrote:
>It would have been easier to figure out why it was matching if the
>matching spf entry was printed out, for example something like this:
>
>May 8 18:21:27.859 [22058] dbg: spf: whitelist_from_spf:
amandarodriq...@odysseyshop.ribsbuy.com matches ^.*\@.*buy\.com$ entry
>May 8 18:21:27.859 [22058] dbg: spf: whitelist_from_spf:
amandarodriq...@odysseyshop.ribsbuy.com is in user's WHITELIST_FROM_SPF and passed
SPF check
From: Matus UHLAR - fantomas <uh...@fantomas.sk>
Date: Sun, 18 May 2014 18:22:49 +0200
According to the documentation, they are not regexp's (as one could/should
expect):
Whitelist and blacklist addresses are now file-glob-style patterns,
On 18.05.14 13:44, Jeff Mincy wrote:
The matching whitelist_from_spf entry *@*buy.com is a file glob pattern
which matched. I'm not sure why you are quoting the manual here. The
whitelist entry *@*buy.com is turned into a regexp by add_to_addrlist
in SpamAssassin/Conf/Parser.pm which among other things does s/\*+/\.\*/g
I wanted to point out that you (and many other people) could be surprised
what you see in the regexp, because the glob-style pattern you enter into
blacklist/whitelist directive.
Maybe if not the RE, but the directive content was shown in the debug
output...
I assume the contents of *_networks is modified before RE matching, so you'd
wonder what is the content...
Ok, you lost me. What does the contents of *_networks have to do with
the suggestion to print the matching whitelist regexp entry? Nothing
matching *buy.com has been added to *_networks if that is what you are
wondering.
sorry, that had to be (black|white)list_*, not *_networks.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Remember half the people you know are below average.
