> (aside: can *any* preference be in the SQL table? I have some required_hits
> which work, but whitelist_from seems to be ignored. individual users seems
> to work and GLOBAL does seem to be recognized.)
>
Anything that can be found in the users $HOME/.spamassassin.prefs (or
wherever the file
Oh, the HEADER NAME is in block caps. I thought it was just the
domain. Yeah, yer hosed if the header name is capitalized other than
"From". Same problem crops up in a variety of other situations too.
It's bug #19 in bugzilla:
http://bugzilla.spamassassin.org/show_bug.cgi?id=19
C
On Mon, 20
>From reading the code:
* just noticed Mail::SpamAssassin::Conf::add_to_addrlist() where it's
converting the glob-patterns to regexs as it reads them in. Missed that
in previous scans of the code.
* before I changed it yesterday, the comparison was between the
lowercased addr from the email and
LAST UPDATE (I hope!)
The whitelist matching *IS* glob-type. .*@domain.dom is wrong. Lots of
debugging confirms this.
Also, more debugging confirms that the whitelist_from entries *ARE* being
taken from SQL. It appears that it's not matching for some other reason.
(maybe because the passp
> Hmm, it seems that it's trying to match an actual perl regexp, so you'll
> want
> .*@PASSPORT.COM
just an update:
I have changed all my whitelist_from entries in the SQL table to be
.*@domain.dom instead of *@domain.dom.
.*@reply.pm0.com is one of them. However mail from this domain isn't g
On Mon, 2002-02-04 at 02:34, Matt Sergeant wrote:
Not much of a DoS attack to launch it against your own email server, and
leave the trace in your own user file ;-)
Well, I could get user-level access to your mail server through some
other method, then discover you're running SA, edi
> -Original Message-
> From: Craig Hughes [mailto:[EMAIL PROTECTED]]
>
> On Mon, 2002-02-04 at 00:07, Jeremy Zawodny wrote:
> > The docs are right that this is probably a security flaw.
>
> What's the flaw? As long as we're not doing "use re
> 'eval'" in the
> code, of
On Mon, 2002-02-04 at 00:07, Jeremy Zawodny wrote:
> The docs are right that this is probably a security flaw.
What's the flaw? As long as we're not doing "use re 'eval'" in the
code, of course.
The relevant line of code is this:
if ($addr =~ /$regexp/i) { return 1; }
On Sun, Feb 03, 2002 at 11:56:58PM -0800, Craig Hughes wrote:
>
> Hmm, it seems that it's trying to match an actual perl regexp, so
> you'll want
>
> .*@PASSPORT.COM
>
> or such, despite the docs which say it wants a glob-style pattern.
Oops.
> The docs are right that this is probably a securi
Hmm, it seems that it's trying to match an actual perl regexp, so you'll want
.*@PASSPORT.COM
or such, despite the docs which say it wants a glob-style pattern. The docs are right that this is probably a security flaw. Any perl guru have a handy snippet for converting a glob-style patte
> It needs to treat the part after the *final* '@' symbol as case
> insensitive, but the part before it, possibly including more '@'
> characters, as case sensitive.
Unfortunately, I have both *@passport.com and *@PASSPORT.COM in my SQL table
for "whitelist_from". The From line is block caps so
On 03 Feb 2002, Craig Hughes wrote:
> It is the right place to bring this up, and I think someone else
> mentioned something similar a while back. Don't remember what the
> resolution was.
IIRC, the conclusion was that SpamAssassin does not do correct RFC822
matching on the address part.
It nee
12 matches
Mail list logo