On Mon, 23 Nov 2015 11:03:07 +0100 Matthias Apitz wrote: > El día Monday, November 23, 2015 a las 10:50:54AM +0100, Reindl > Harald escribió: > > > blame your MTA our your MTA configuration for the way it adds > > received headers without name resolving, look at my recceived > > header and yours for 140.211.11.3 > > Thanks. It is not my MTA, but the one of my ISP running on > ms-10.1blu.de. I will contact them.
Don't do that, there's nothing wrong with their headers or DNS. The rule is triggered by an internal handover from a submission server to an IMAP server being misinterpreted as an MX handover, it's purely a problem caused by your configuration. However, fixing it may not be the best thing to do because once you specify trusted/internal networks you have to maintain them, and a third-party network can change it's IP addresses at any time. Take at look the mail that's delivered though your provider's MX servers (rather than submitted) and look whether it's working correctly. If it's working well with the autoguesser, it may be better not to specify any network setting and just mitigate the occasional spurious RDNS_NONE with a local rule. Note that the public IP address of your provider's IMAP server in the fetchmail header does not have to be in either your trusted or internal networks because it's ignored.
