Re: [Declude.JunkMail] HELOBOGUS for Email from Postfix Gateway

2005-01-09 Thread R. Scott Perry

However, I'm having a problem with Declude triggering on reporting emails 
that are generated directly ON the gateway itself:
That's because the gateway is running an MTA that adds very poor Received: 
headers.

- Declude parses IP Address 0.0.0.0
- Declude parses HELO string of userid
Here is the headers that Postfix generates for email that originates from 
that machine:

 Received: from mail.dollardays.com [67.132.45.18] by
 mail.webhost.hm-software.com with ESMTP
   (SMTPD32-8.14) id A4F0800114; Sat, 08 Jan 2005 04:16:32 -0500
That one is fine.  Since you are IPBYPASSing 67.132.45.18, Declude JunkMail 
skips over that line.

 Received: by mail.dollardays.com (Postfix)
  id BD39835A9D2; Sat,  8 Jan 2005 04:16:24 -0500 (EST)
This one is a very poor Received: header.  It contains almost no useful 
information (since it is your server, you already know its name, and the 
time *could* be useful, but only if the server uses NTP).

 Received: by mail.dollardays.com (Postfix, from userid 0)
  id A8FC335A9CE; Sat,  8 Jan 2005 04:16:24 -0500 (EST)
This, too, is a very poor Received: header.  It, too, contains almost no 
useful information.

As you can see, it
a) has no FROM field in the received header - that's what's causing the 
0.0.0.0 being reported as the IP address
Correct.
b) it picking up userid form inside an SMTP header comment - the string 
is included inside paranthesis, thus should NOT be interpreted by Declude.
Correct.
However, given how many poor (one step above very poor) mailservers 
there are out there, we have to check inside SMTP comments.  There are 
mailservers out there that include the IP (and probably 'from') in SMTP 
comments.

   -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 outgoing message is guaranteed to be authentic by Message Level users.
Guarantee the authenticity of your email @ http://www.messagelevel.com.
---
[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.


[Declude.JunkMail] HELOBOGUS for Email from Postfix Gateway

2005-01-08 Thread Andy Schmidt
Title: Message



Hi 
Scott,

I'm colocating a 
Postfix gateway for a client - and "external" mail is being routed 
fine.
However, I'm having a problem with Declude 
triggering on reporting emails that are generated directly ON the gateway 
itself:

-I have 
IPBYPASS set for 67.132.45.18 (which is how it should be).
-Declude 
parses IP Address 0.0.0.0 
-Declude parses HELO string of 
"userid"

Here is what Declude 
parsed from the RECEIVED header (2nd and even 3rd hop)

 Mail 
Server: %REMOTEIP% for %RHSBL% [%SENDERHOST%] DNS 
Pointer: %REVDNS% Host Name: 
%HELO%

 Mail Server: 
0.0.0.0 for mail.dollardays.com [mail.dollardays.com] 
DNS Pointer: (Private IP) Host 
Name: userid

Here is the headers 
that Postfix generates for email that originates from that 
machine:

 Received: from mail.dollardays.com 
[67.132.45.18] by  mail.webhost.hm-software.com with 
ESMTP (SMTPD32-8.14) id A4F0800114; Sat, 08 Jan 2005 
04:16:32 -0500
 Received: by mail.dollardays.com (Postfix) 
id BD39835A9D2; Sat, 8 Jan 2005 04:16:24 -0500 (EST)
 Received: by mail.dollardays.com (Postfix, from userid 
0) id A8FC335A9CE; Sat, 8 Jan 2005 04:16:24 -0500 
(EST)
As you can see, 
it

a) has no FROM field 
in the received header - that's what's causing the "0.0.0.0" being reported 
as the IP address

b) it picking up 
"userid" form inside an SMTP header comment - the string is included inside 
paranthesis, thus should NOT be interpreted by Declude.

I think item 
b)is truly a malfunction by Declude. At "worst" it should 
detect the HELO string as null.

However, ideally, I 
wonder whether Declude should only "hop" to the next Receive line, if the 
receive line actuallyDOES havea "FROM" field. If there is no 
other Received/From line, then it should use the information from the 
LASTVALID Receivedtimestamp (which in this case would be the header 
inserted by Imail) - which would then yield correct 
results.
Best 
RegardsAndy SchmidtPhone: +1 201 934-3414 x20 
(Business)Fax: +1 201 934-9206