On Sun, 18 Nov 2012 17:07:39 -0500 dar...@chaosreigns.com wrote: > On 11/18, RW wrote: > > Whilst that wont hurt, it's not the real cause of the problem here > > which rests entirely with UnifiedeMail.net. > > > > Whilst it would have prevented this FP, authentication is intended > > to solve a different problem. It shouldn't be necessary to have a > > workaround for the internal network being needlessly allowed to > > bleed into a remote private network. > > > > I wouldn't worry too much about this, it's not a general problem. > > I disagree. I think indicating the authentication is a better option > than chopping off the early received header(s).
Who said anything about chopping-off headers? I think you've probably misunderstood what's going on here. SA is running on a third-party server that isn't under the control of the OP or the OP's ISP. The OP has access to the SA tests because it's a server that's set-up to autoreply with a report on spaminess. If the UnifiedeMail MX server doesn't provide a received header then trying to run most DNS blocklist tests or any test that involves the edge of the internal network is pointless and error prone. The lack of authentication doesn't affect the OP's deliverability through the ISP in general. mrelayeu.kundenserver.de is on a different /16 from kundenserver.de's mx servers so authentication isn't even needed for SA installations run by the ISP's other customers.