Hi Scott,
In my mailbox are a lot of messages in german and italian language. This
contains sometimes characters like ä,ö,ü,à,è ...
However not all this messages trigger the base64-test
If i send a test-message containing in the body only those special
characters it will trigger the base64-test.
A spam I received yesterday had these comments in it also.
However one thing I noticed was that the spam had a url that started off
with the standard http then was followed by
PercentHexHexPercentHexHexPercentHexHexPercentHexHexPercentHexHex and so on.
This should be very easy to filter on as no
A word of caution from our research.
Some legitimate messages do encode other URLs as parameters. As a result
this kind of filter requires the following constraints (still not
perfect but close):
Be sure your rule fires on the ROOT of the URL so that you are not
capturing parameters that have
:24.0080 (UTC)
FILETIME=[F8F7FB00:01C290A5]
LOG FILES
Imail Log file
20021120 100318 127.0.0.1 SMTPD (386800B4) [209.94.11.105] connect
12.25.87.100 port 1297
20021120 100318 127.0.0.1 SMTPD (386800B4) [12.25.87.100] EHLO
mail2.gannett-tv.com
20021120 100318 127.0.0.1 SMTPD (386800B4
for this E-mail (without one, IMail won't try
to deliver the E-mail)?
LOG FILES
Imail Log file
20021120 100318 127.0.0.1 SMTPD (386800B4) [12.25.87.100]
e:\imail\spool\Da436386800b47455.SMD 6691
Were there any references to a436386800b47455 in the log file after this
(showing IMail trying
are, you should still see the 'generic' Declude headers (such as
X-Note:,
X-Declude-Sender:, etc.).
File: Da436386800b47455.SMD
Was there also a Q*.SMD file for this E-mail (without one, IMail won't
try
to deliver the E-mail)?
LOG FILES
Imail Log file
20021120 100318 127.0.0.1 SMTPD (386800B4
What I was referring to with IPBYASS is the 12.25.87.100 is a backup
mail server that needed to be skipped. My HOP Settings are as follow's
HOP 0
HOPHIGH 2
Don't worry about that -- the IPBYPASS/HOP/HOPHIGH settings won't cause the
behavior you saw.
I did not find any reference in the
Scott,
The logs still do not reflect that the mail was delivered. Although
there are no traces of it in the spool directory.
I also checked for locked files _* and did not find any.
I do have a declude.gp1 and declude.gp2 but they are dated 10/16/2002.
I understand there is not much to go on,
The logs still do not reflect that the mail was delivered. Although
there are no traces of it in the spool directory.
If the D*.SMD file is gone, that's an IMail issue -- either it's broken (if
it just deleted the D*.SMD file), or it should have delivered it (in which
case it should appear
It's hard to say what happened here. Are you sure that the D*.SMD
file you ooked at originally wasn't just an E-mail that was arriving
on the server (in which case you may have opened it while Declude
JunkMail was processing it, before it added its headers)?
Scott that very well may be the case. I was under the impression
declude processes the mail prior to it being placed in the spool
directory. Is that not the case?
That is not the case.
First, IMail's SMTPD process receives the E-mail, and IMail is required to
save the file to the disk (per
I have in the notifications SKIPIFVIRUSNAMEHAS Vulnerability.
However, the notices are still being sent out.
Any one else experiencing this?
Scott, I have sent the files and the log snippet (I have had the log in
DEBUG mode all day waiting for another one to be caught.) to you directly
for
I have in the notifications SKIPIFVIRUSNAMEHAS Vulnerability.
However, the notices are still being sent out.
The problem here is that there can only be one space/tab between
SKIPIFVIRUSNAMEHAS and Vulnerability. This is something we hope to
change soon.
-Scott
---
The problem here is that there can only be one space/tab between
SKIPIFVIRUSNAMEHAS and Vulnerability. This is something we hope to
change soon
Are you telling me I had multiple spaces instead of a tab?
ARGH!
John Tolmachoff MCSE, CSSA
IT Manager, Network Engineer
RelianceSoft, Inc.
Thank you, Scott John. Unfortunately, I had to perform a complete
re-install of IMail, Declude, KillerWebMail, etc. -- the whole shabang.
As it turns out, things got a whole lot worse, as John suggested, even
though I had promptly restored the registry changes. Within an hour of
Scott's reply,
Thank you, Bonno. Gave it a whirl and, as suspected, the IMail server
passed these tests as well.
Good idea, nonetheless!
Thank you.
Dave
Bonno Bloksma wrote:
Hi,
? ?The DNS servers appear to be working fine. NSLOOKUP from a DOS prompt
? ?on the mail server to either of the DNS
16 matches
Mail list logo
