On Thu, 18 Oct 2012 09:22:41 -0400 Joseph Acquisto wrote: > >>>> RW <rwmailli...@googlemail.com> 10/17/12 8:25 PM >>> > >On Wed, 17 Oct 2012 06:32:27 -0400 > >Joseph Acquisto wrote: > > > >> > Frustrating, as I could swear I did this with them, just some > >> > months ago. > >> > > >> > joe a. > >> > >> Just wondering, should not being a "trusted_networks" negate that > >> check or modify that weight? > >> > >> But then, I just checked and I have that IP as an > >> "internal_networks" as well, and the docs appear to specifically > >> warn > > > >The problem you've described is rarely anything to do with local > >rdns, and removing your own ip addresses from internal_networks is > >probably wrong. > > > >Have you done what I suggested and checked that that the last > >internal server is recording rdns information in the received > >headers? Check it on a normal delivery from outside your network > >from a proper mail server. > > Not following. > > I don't have mail delivered directly. All mail is fetched from a off > site POP server, where I consolidate several accounts. So all have > the same domain as the last stop before "local stuff".
That's where you are going wrong. Wherever possible the internal network should extend to the MX servers, even if they aren't literally internal. This sort of thing is often easier to handle if you configure getmail/fetchmail not to add a received header because that header can break a chain of private addresses. A similar problem happens when one account fetches from others by pop or imap. It can be more straightforward to handle the accounts locally rather than consolidating in a remote pop server. I notice from the rule score that you are using Spamassassin without net rules (which would need a proper internal network) or Bayes. That's likely to produce poor results. > Meantime, I will just change the SPAM score level to 7.5 and see how > that goes. At least some of the local whining may be reduced. It's better to just score RDNS_NONE at 0.
