Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Avi Shatz wrote on Sun, 19 Sep 2004 18:13:43 +0300: The only thing I wanted to prove with this is that line, that is created by my local mail server (the last hop, and the most important one for SPF), does indeed contains the EHLO string that isn't detected correctly by SA 3.0rc5. But you didn't prove that. You showed an SMTP handshake with your server, you didn't show how your server helos when it connects (you showed how it replies when you connect TO it - see the difference?). Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de http://msie.winware.org
Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Avi Shatz wrote: The only thing I wanted to prove with this is that line, that is created by my local mail server (the last hop, and the most important one for SPF), does indeed contains the EHLO string that isn't detected correctly by SA 3.0rc5. OK... And since nothing is special about my own MS SMTPSVC (Win2k3 SMTP Server), I believe the behavior of received.pm should be changed to allow SA running on those machines to properly detect the EHLO string, and thus allow SPF Detection to properly execute. So what *do* your mail headers look like when your HELO or EHLO argument is not the FQDN of the connecting host? Most MTAs will VERY carefully include these two pieces of information separately: sendmail for instance, will show something like: Received: from HELO (rDNS [IP]) by MYHOST. If there's no rDNS, or if rDNS is mismatched to (something, don't remember what offhand), there will be a different arrangment which is quite clear. It sounds like your MTA is being a bit rude by assuming that the HELO/EHLO and the rDNS will match, and essentially dropping the rDNS in favour of the (highly unreliable) HELO. -kgd -- Get your mouse off of there! You don't know where that email has been!
Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
From some reason, SPF is always claiming the lack of HELO in the received headers, while they are clearly there. Nope, they're not. I'm attaching an example message file which I try to pass via spamassassin, and get something like: debug: SPF: checking HELO (helo=, ip=66.111.4.30) debug: SPF: trimmed HELO down to '' debug: SPF: cannot get HELO, cannot use SPF Received: from frontend1.messagingengine.com ([66.111.4.30]) by localmta.org with Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300 Received: from web4.messagingengine.com (web4.internal [10.202.2.213]) by frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE for [EMAIL PROTECTED]; Sat, 18 Sep 2004 12:53:00 -0400 (EDT) Those debug lines are pointing to the first received line above. The HELO name would normally appear between the ( and the [ of the dotquad address. Nothing there. The second received line does appear to have a HELO name on it. However, the address is in private space, so is not usable. Loren
RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Well, the way that Microsoft SMTP works here, is if the line is: Received: from frontend1.messagingengine.com ([66.111.4.30]) by localmta.org with Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300 The EHLO is: frontend1.messagingengine.com The IP is: 66.111.4.30 The accepting Server is: localmta.org I've double checked this, that first string is not the rDNS, its clearly the EHLO, and can be used.. Any ideas on how to solve this? -Original Message- From: Avi Shatz Sent: Sunday, September 19, 2004 2:18 AM To: 'Loren Wilton' Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ? Well, the way that Microsoft SMTP works here, is if the line is: Received: from frontend1.messagingengine.com ([66.111.4.30]) by localmta.org with Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300 The EHLO is: frontend1.messagingengine.com The IP is: 66.111.4.30 The accepting Server is: localmta.org I've double checked this, that first string is not the rDNS, its clearly the EHLO, and can be used.. Any ideas on how to solve this? -Original Message- From: Loren Wilton [mailto:[EMAIL PROTECTED] Sent: Sunday, September 19, 2004 2:01 AM To: users@spamassassin.apache.org Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ? From some reason, SPF is always claiming the lack of HELO in the received headers, while they are clearly there. Nope, they're not. I'm attaching an example message file which I try to pass via spamassassin, and get something like: debug: SPF: checking HELO (helo=, ip=66.111.4.30) debug: SPF: trimmed HELO down to '' debug: SPF: cannot get HELO, cannot use SPF Received: from frontend1.messagingengine.com ([66.111.4.30]) by localmta.org with Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300 Received: from web4.messagingengine.com (web4.internal [10.202.2.213]) by frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE for [EMAIL PROTECTED]; Sat, 18 Sep 2004 12:53:00 -0400 (EDT) Those debug lines are pointing to the first received line above. The HELO name would normally appear between the ( and the [ of the dotquad address. Nothing there. The second received line does appear to have a HELO name on it. However, the address is in private space, so is not usable. Loren
Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
% host 66.111.4.30
30.4.111.66.in-addr.arpa domain name pointer frontend1.messagingengine.com.
You coul dnot prove it by me that the name there is the HELO rather than
the rDNS lookup.
{^_^}
- Original Message -
From: Avi Shatz [EMAIL PROTECTED]
Well, the way that Microsoft SMTP works here, is if the line is:
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
The EHLO is: frontend1.messagingengine.com
The IP is: 66.111.4.30
The accepting Server is: localmta.org
I've double checked this, that first string is not the rDNS, its clearly
the EHLO, and can be used..
Any ideas on how to solve this?
-Original Message-
From: Avi Shatz
Sent: Sunday, September 19, 2004 2:18 AM
To: 'Loren Wilton'
Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Well, the way that Microsoft SMTP works here, is if the line is:
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
The EHLO is: frontend1.messagingengine.com
The IP is: 66.111.4.30
The accepting Server is: localmta.org
I've double checked this, that first string is not the rDNS, its clearly
the EHLO, and can be used..
Any ideas on how to solve this?
-Original Message-
From: Loren Wilton [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 19, 2004 2:01 AM
To: users@spamassassin.apache.org
Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
From some reason, SPF is always claiming the lack of HELO in the
received
headers, while they are clearly there.
Nope, they're not.
I'm attaching an example message file which I try to pass via
spamassassin,
and get something like:
debug: SPF: checking HELO (helo=, ip=66.111.4.30)
debug: SPF: trimmed HELO down to ''
debug: SPF: cannot get HELO, cannot use SPF
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
Received: from web4.messagingengine.com (web4.internal [10.202.2.213])
by
frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE
for
[EMAIL PROTECTED]; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)
Those debug lines are pointing to the first received line above. The
HELO
name would normally appear between the ( and the [ of the dotquad
address.
Nothing there.
The second received line does appear to have a HELO name on it.
However,
the address is in private space, so is not usable.
Loren
RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Well, in that case it might just be also the rDNS, but I've tested more
then once:
telnet mailserver.localmta.org 25
ehlo blabla
[...]
Quit
Resulting header will show blabla other then workstation.localmta.org
-Original Message-
From: jdow [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 19, 2004 2:42 AM
To: users@spamassassin.apache.org
Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
% host 66.111.4.30
30.4.111.66.in-addr.arpa domain name pointer
frontend1.messagingengine.com.
You coul dnot prove it by me that the name there is the HELO rather than
the rDNS lookup.
{^_^}
- Original Message -
From: Avi Shatz [EMAIL PROTECTED]
Well, the way that Microsoft SMTP works here, is if the line is:
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
The EHLO is: frontend1.messagingengine.com
The IP is: 66.111.4.30
The accepting Server is: localmta.org
I've double checked this, that first string is not the rDNS, its
clearly
the EHLO, and can be used..
Any ideas on how to solve this?
-Original Message-
From: Avi Shatz
Sent: Sunday, September 19, 2004 2:18 AM
To: 'Loren Wilton'
Subject: RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
Well, the way that Microsoft SMTP works here, is if the line is:
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
The EHLO is: frontend1.messagingengine.com
The IP is: 66.111.4.30
The accepting Server is: localmta.org
I've double checked this, that first string is not the rDNS, its
clearly
the EHLO, and can be used..
Any ideas on how to solve this?
-Original Message-
From: Loren Wilton [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 19, 2004 2:01 AM
To: users@spamassassin.apache.org
Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ?
From some reason, SPF is always claiming the lack of HELO in the
received
headers, while they are clearly there.
Nope, they're not.
I'm attaching an example message file which I try to pass via
spamassassin,
and get something like:
debug: SPF: checking HELO (helo=, ip=66.111.4.30)
debug: SPF: trimmed HELO down to ''
debug: SPF: cannot get HELO, cannot use SPF
Received: from frontend1.messagingengine.com ([66.111.4.30]) by
localmta.org
with
Microsoft SMTPSVC(6.0.3790.80); Sat, 18 Sep 2004 19:53:03 +0300
Received: from web4.messagingengine.com (web4.internal [10.202.2.213])
by
frontend1.messagingengine.com (Postfix) with ESMTP id 19E5CC154AE
for
[EMAIL PROTECTED]; Sat, 18 Sep 2004 12:53:00 -0400 (EDT)
Those debug lines are pointing to the first received line above. The
HELO
name would normally appear between the ( and the [ of the dotquad
address.
Nothing there.
The second received line does appear to have a HELO name on it.
However,
the address is in private space, so is not usable.
Loren
RE: SPF Fails on SA 3.0rc5 because of lack of HELO ?
The only thing I wanted to prove with this is that line, that is created by my local mail server (the last hop, and the most important one for SPF), does indeed contains the EHLO string that isn't detected correctly by SA 3.0rc5. And since nothing is special about my own MS SMTPSVC (Win2k3 SMTP Server), I believe the behavior of received.pm should be changed to allow SA running on those machines to properly detect the EHLO string, and thus allow SPF Detection to properly execute. -Original Message- From: Kai Schaetzl [mailto:[EMAIL PROTECTED] Sent: Sunday, September 19, 2004 4:27 PM To: users@spamassassin.apache.org Subject: Re: SPF Fails on SA 3.0rc5 because of lack of HELO ? Avi Shatz wrote on Sun, 19 Sep 2004 02:52:49 +0300: telnet mailserver.localmta.org 25 ehlo blabla What do you want to prove with this? What needs to happen is that [66.111.4.30] sends a HELO with an FQDN when it connects to another SMTP. Your example above doesn't prove this, it just proves that you know how to do an SMTP handshake. At least if the SMTPSVC received lines usually show the HELO then, indeed, it seems to be missing. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com IE-Center: http://ie5.de http://msie.winware.org
