Hi Scott:
The most peculiar indeed... yet again you were right...
Somehow the problem is gone... I have not rebooted and no changes were made
to the rules... The problem surfaced after upgrade to 1.68i and it went away
pretty much after your reply.
Strange... how do you know so much!
Sounds like this test might be a good negative weight test like
IPNOTINMX. Of course if they use a good mailfrom it could reduce the
positive. Any thoughts?
Thanks,
Chuck Frolick
ArgoNet, Inc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of R. Scott
Is this syntax correct to whitelist an entire domain in the whitelist file?
@bounce.topiksolutions.com
It appears to be whitelisting everything when I add this. We're running Declude
v1.68i4
Thanks,
Bill
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
Hi;
Yes but I suggest if you want to whitelist the entire domain then do it as:
.TopikSolutions.com
Or just TopikSolutions.com
That will cover all variations including personal emails from their people.
Regards,
Kami
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
What I am seeing is if I add any entry in my whitelist file in the follwoing format,
it will cause ALL emails sent to the user who's whitelist file contains this entry to
be whitelisted, regardless of the senders address. So it appears to be a bug...
@example.com
-Original Message-
Is this syntax correct to whitelist an entire domain in the whitelist file?
@bounce.topiksolutions.com
It appears to be whitelisting everything when I add this. We're running
Declude v1.68i4
That was changed accidentally in v1.68, but is fixed in the latest interim
release (v1.68i5 at
What follows is the header from an email sent from a valid account to
another valid account, here at UCD. The recipient was concerned that this
message would be tagged as 'consistent with spam' and/or 'bad headers'. My
thoughts were that perhaps its because the user is on an older Macintosh,
What follows is the header from an email sent from a valid account to
another valid account, here at UCD. The recipient was concerned that this
message would be tagged as 'consistent with spam' and/or 'bad
headers'. My thoughts were that perhaps its because the user is on an
older
Hi:
Adds %IP4R%, %RHSBL%, %MAILFROMBL% and %HELO% variables.
Okay, I can guess what IP4R and HELO inserts - but what do strings do the
two ...BLs insert?
Where are those variables valid?
A) in Declude SMTP headers?
B) in alert/bounce messages templates?
C) in ... ?
Best Regards
Andy
Adds %IP4R%, %RHSBL%, %MAILFROMBL% and %HELO% variables.
Okay, I can guess what IP4R and HELO inserts - but what do strings do the
two ...BLs insert?
Good question. :)
%IP4R% inserts the IP address in the format for ip4r-style spam databases
(if the IP is 192.0.2.25, it will return
I am using the copyto function to route a copy of any message that fails
the sniffer test to my email box.
If the message is a false positive I then insert the false positive
message into another email and send it off to the folks at sniffer.
What we found today is that for some reason headers
I have some insight on the date issue.
Macs tell time by counting the amount of time since a date in 1903 (something to do
with the Wright Brothers), used as time zero. It makes them automatically y2k savvy,
but it also means that when a particular machine's been around long enough for the
Not sure where your getting 1903 etc from but that is besides the
point.
The main problem in this mess is among other things this line
Date: 20 Mar 03 18:30:01 -0800
A correct date according to the RFC should read
Date: 20 Mar 2003 18:30:01 -0800
The mac I seen resets back to 1980 when the
13 matches
Mail list logo