Here's a simple filter to fix the issue for at leat the NDR's and
Webmail, and possibly all other messages generated by IMail1.exe and
maybe even the listserv (though I don't use it so I can't test). If
you wanted to limit this to just NDR's, you could add another line with
an END statement testing for a MAILFROM of <>.
----- Global.cfg -----
WHITELIST-GSE filter
C:\IMail\Declude\Filters\Whitelist-GSE.txt x 0 0
----- Whitelist-GSE.txt -----
HEADERS END NOTCONTAINS X-Mailer: <SMTP32 v8.
HEADERS WHITELIST NOTCONTAINS Received:
Matt
Matt wrote:
Scott,
Two things regarding this if you don't mind.
First when you say "next release", does that mean that there will be no
more interims? This is important enough for me that I will code
something up for it in lieu of a fix from Declude. This is also the
type of thing that would be real helpful to know as a user before
having to discover it for myself a week after the fact, so please don't
hold back on sending out announcements of this type to your customer
base.
Secondly, regarding one of the points that I made in my note, Declude
is picking the wrong IP out of the headers in certain circumstances.
Declude is very unforgiving of any IP listed in the headers that is not
surrounded by brackets, but if there are two such entries in one
received header, Declude is picking the first entry for the DNSBL's and
for the REMOTEIP variable, and might also be affecting the HELO. For
instance, with the following header which was created by an RFC
compliant Netscape Mail 7.2, Declude is reading the first bracketed IP
instead of the second:
Received: from [192.168.100.100] [24.195.119.188] by mailpure.com with ESMTP
(SMTPD32-8.13) id A518CF400DA; Thu, 14 Oct 2004 00:48:24 -0400
This is generally a minor issue, but there can definitely be cases
where this can affect filtering or whitelisting and it would be nice to
see this handled differently at some point in the future.
Thanks,
Matt
R. Scott Perry wrote:
Can I recommend that the condition be
looked
at where it grabs the received headers from the body just in case there
are other issues with this code that could appear elsewhere...
This will be fixed for the next release.
Specifically, Declude JunkMail was only checking the headers for an IP
address -- but if an IP address was needed later (such as with the
%REMOTEIP% variable) and no IP was known, a separate function was
called to pick up the first IP in the E-mail. This worked fine with
IMail v7 (as all E-mails would have the IMail Received: header), but a
change in IMail v8 (not adding the Received: header) caused Declude to
see an IP in the body of the E-mail.
... and apart from that, maybe whitelist
all
GSE named files, or give us a way to whitelist all GSE named files
(such as working it into WHITELIST AUTH or another switch).
I'll see if we can do that.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers
since 2000.
Declude Virus: Ultra reliable virus detection and the leader in
mailserver vulnerability detection.
Find out what you've been missing: Ask for a free 30-day evaluation.
---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
--
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================
|
