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: > >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]
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: > 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]
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