Re: CommuniGate Pro Received header (was: whitelist_from_rcvd not working)
SM wrote: This is the standard CommuniGate Pro Received: header. When HELO matches the hostname, this header always looks this way, with the word verified added to it. SpamAssassin is not parsing that Received: header as one with a hostname which has been verified. [dd] Yes. See attached patch. There is a minor problem with your patch. The helo= appears empty. I think you can safely put that $rdns = $1; $helo = $1 Post a bug report about the CommuniGate Pro Received header not being parsed correctly. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED]
Re: CommuniGate Pro Received header (was: whitelist_from_rcvd not working)
SM wrote: Hi Victor, At 21:40 09-04-2008, Victor Sudakov wrote: This is the standard CommuniGate Pro Received: header. When HELO matches the hostname, this header always looks this way, with the word verified added to it. SpamAssassin is not parsing that Received: header as one with a hostname which has been verified. When HELO does not match the hostname, the header looks different: Received: from [213.183.100.11] (HELO blablabla.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTP id 9853037 for [EMAIL PROTECTED]; Thu, 10 Apr 2008 11:26:20 +0700 That's the only CommuniGate Pro Received header format parsed currently. Neither. It's a feature. Perhaps we need a patch for Received.pm? Yes. See attached patch. Your patch has applied cleanly. whitelist_from_rcvd now works, but not quite in the manner I have expected. In fact, it works only if the relay is NOT in the trusted_networks list. I wonder if this is by design. In my opinion, whitelisting should always work. Post a bug report about the CommuniGate Pro Received header not being parsed correctly. I will as soon as the trusted_networks issue is cleared. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED]
Re: CommuniGate Pro Received header (was: whitelist_from_rcvd not working)
At 23:03 09-04-2008, Victor Sudakov wrote: whitelist_from_rcvd now works, but not quite in the manner I have expected. In fact, it works only if the relay is NOT in the trusted_networks list. Can you post the debug output? I wonder if this is by design. In my opinion, whitelisting should always work. You can only trust the Received: headers inserted by your mail servers. Regards, -sm
Re: CommuniGate Pro Received header (was: whitelist_from_rcvd not working)
SM wrote: whitelist_from_rcvd now works, but not quite in the manner I have expected. In fact, it works only if the relay is NOT in the trusted_networks list. Can you post the debug output? In this case 212.73.124.135 is trusted so the sender was not whitelisted!!! http://vas.tomsk.ru/sa2.txt And here is what happens when I remove 212.73.124.135 from the trusted list, the sender got whitelisted: http://vas.tomsk.ru/sa3.txt I wonder if this is by design. In my opinion, whitelisting should always work. You can only trust the Received: headers inserted by your mail servers. The topmost Received: header is always inserted by my mail server. But if the relay mentioned in this topmost header is in the list of trusted_networks, whitelist_from_rcvd does not work. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[EMAIL PROTECTED]
CommuniGate Pro Received header (was: whitelist_from_rcvd not working)
Hi Victor, At 21:40 09-04-2008, Victor Sudakov wrote: This is the standard CommuniGate Pro Received: header. When HELO matches the hostname, this header always looks this way, with the word verified added to it. SpamAssassin is not parsing that Received: header as one with a hostname which has been verified. When HELO does not match the hostname, the header looks different: Received: from [213.183.100.11] (HELO blablabla.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTP id 9853037 for [EMAIL PROTECTED]; Thu, 10 Apr 2008 11:26:20 +0700 That's the only CommuniGate Pro Received header format parsed currently. Neither. It's a feature. Perhaps we need a patch for Received.pm? Yes. See attached patch. Post a bug report about the CommuniGate Pro Received header not being parsed correctly. Regards, -sm communigatercv.diff Description: Binary data
