Shayne Lebrun wrote:
Ah, a bit of linguistic mixup. You'd have been better served by phrasing it
'man in black,' mein Herr; to evoke the vision of the black-hatted cowboy,
or the evil guy in black leather, and so on.
Yes, but then people would have thought he was talking about Johnny Cash.
-
Matt Kettler wrote:
1) \b is NOT a substitute for spaces. It's zero-width. For things other
than the
beginning/ending of a rule, use \s unless you REALLY understand the difference.
i.e. you should know why /hello\bWorld/ will never match anything.
In this case /\"\bT/ would match both " T
JamesDR wrote:
If you want to post to aol, your HELO MUST match
your rdns (has been in my case and a few others.)
Not true. I send messages to AOL all the time from a machine whose HELO
does not match its rDNS. Perhaps you mean that the HELO must be a valid
hostname that points to your ser
Robert Menschel wrote:
SARE has been playing around with URI rules lately, and when we need
to test for something in the host/domain area, we use something like:
uri rule_name m'(?:https?://)?[^/]*testgoeshere'
I think you want a ^ at the start of your regex. As it is, that will
match an
Joe Zitnik wrote:
Bayes definitely helps, but auto-learn can cause problems. Perhaps a
better question would be, "Is autolearn really neccessary?"
I think the problems mostly come from accidentally autolearning spam as
ham, which is easy with the default threshold. Autolearning messages as
List Mail User wrote:
Also, just curious, but do you have problems with the forward
and reverse DNS of you mail servers not mapping together (ex. mail.dailykos.com
maps to 69.9.164.210, but the reverse of 69.9.164.210 is faye.voxel.net - in
particular do you have problems with ISPs like AOL?).
Loren Wilton wrote:
FWIW, I've been running that rule [checking for middle initial in
"From"] since before it was mentioned on the list, and it is still
moderately useful. It does hit ham, but at one point or however I
have it scored that isn't significant. On the other hand, that point
has mo
Just to clarify, since Paul seems to have misunderstood, I have nothing
to do with administering slashdot.org or any of the other domains I
listed. Those were just examples. I'm not connected with them, and
they mostly have nothing to do with each other as well. And I don't
think you're goin
jdow wrote:
One must wonder at their motivations for allowing things like
wassyup.metazeek.spindrift.metafilter.com. Is there a good one?
I'm not sure about metafilter.com. It could just be that Matt Haughey
doesn't want to mess with his DNS whenever he wants to set up a new
subdomain, like
List Mail User wrote:
Legitimate domains will use wildcards for 'NS', 'MX' and even
occasionally for some more obscure records, but an 'A' or 'CNAME'
record is nearly always a spammer.
Do you have any statistics for that? I administer plenty of domains
that have wildcard A records, and I'm n
Rocky Olsen wrote:
no, possessive quantifiers/atomic grouping discard saved states to back
tracking will not occur for what was matched.
Sounds like you might be able to use (?>pattern) to do what you want.
See perldoc perlre.
--
Keith C. Ivey <[EMAIL PROTECTED]>
Washington, DC
Matthew Newton wrote:
What would be the benefits of creating rules that fired on bounce
messages only (i.e. came from <>), and hit stuff like this. Are there
any reasons why giving a score of 10 when matching "Spam-Score: "
on a bounce would cause a real bounce to get rejected?
Yes, if the
Neil Watson wrote:
Rejecting spam is not a good idea. Most of the time you end up spamming
some poor sod who has been joe-jobbed. Discard spam. Don't add the to
problem.
The problem with discarding is that in situations like the one
described the sender will have no idea the mail was not receiv
Robert Menschel wrote:
The question is how intelligent do you want to make the rule(s). If
you want something like
body L_PIPE m'\w\w\|\w\w'
body L_ZER0 m'\w\w0\w\w'
body L_VEEE m'\\/\w'
body L_ m'\w/\\\w'
body L_LONE m'\w\w1\w\w'
meta L_OBFU2 L_PIPE + L_ZERO + L_VEEE + L_ +
Chris Santerre wrote:
We often replace it with something like \w{0,15} or whatever. Helps the
code.
Ah, sorry. I understand what you meant about '*' now. I
thought you were talking about '+' versus '*', but your
observation would apply just as well to '+', which should be
replaced by '{1,15}'
Chris Santerre wrote:
m{"]+|"[^"]*")*>(<([^>"]+|"[^"]*")*>)*[a-z]{1,2}(<([^>"]
+|"[^"]*")*>)*"]+|"[^"]*")*>}i
The other problem with the pattern as written (with no *) is
that the subpatterns don't match plain or , since they
require at least one character between the td and the >.
One of the
Jesse Houwing wrote:
BODY TABLEOBFU
m{]+|"[^"]+)>(<([^>]+|"[^"]+)>)*[a-z]{1,2}(<([^>]+|"[^"]+)>)*]+|"[^"]+)>}i
I think you may want a * after the ) inside the <>. As it is,
you're looking for either a bunch of characters that are not >
or a quote followed by a bunch of characters that are not
David Suen wrote:
I just read my spamd log file and I found that the time in the log is
incorrect. I just sent an email to myself and here is the log:
@4000423abce8189d6a1c 2005-03-18 11:34:54 [21095]
whereas right now the time is Fri Mar 18 22:36:42 EST 2005.
Your EST is +1100 (as opposed to
Mike Spamassassin wrote:
I'd take that bet.
While you are almost certainly correct with the likes of those who
subscribe to this group, who often have multiple email addresses,
out there in [EMAIL PROTECTED] land, and hotmail world, most people have a
single
email address strongly related to their
Loren Wilton wrote:
Try the rule with /s on the end of the re. That will tend to turn newlines
into spaces.
People often seem to be confused by the /s modifier for regexes.
All it does is allow '.' to match any character. Without the
/s, '.' matches any character other than newline. So /s doe
20 matches
Mail list logo
