besides that the setup is now in production Am 27.08.2014 um 03:48 schrieb Karsten Bräckelmann: > Again: Craft your samples to match real-life (production) environment. > Do not configure or try to fake an environment that will not match > production later. It won't work. > > You want to configure SA. So configure SA. Correctly.
finally yes, not at development and testing that is what testing is for: * no access from outside * try to set trust on single IP's lacking different ranges > If you insist on not following that advice, please refrain from further > postings to this list. the simple answer to my question would have been "no, in no case SA does any RBL check if the client is from the same network range and there is no way to change that temporary even for development" instead start debug sessions with CLI tools while i already statet that i found out the RBL's are check if the connection comes from a foreign network that behavior still is a bug, not in production but it is a bug if there is no hop before and hence no received headers before there is still a known IP - the one and only and in that case the currently connection client - there is no reason not fire a DNSBL/DNSWL against that IP >> the intention to berak it was to behave like it is external >> and just check the RBL behavior > > Read my previous post again, carefully. If you define everything to be > external, there is no *last* external SA can trust. if there is only *one* received header it's from the MTA on which SA is running >> well, there will never be internal relays, just a inbound-only MX > > That IS an internal relay. Your MX must be in your internal_networks, > and it is by the very definition of MX an SMTP relay. the machine SA is running on *is the MX itself* > Besides: SA is not an SMTP. It does not add the Received header. And it > absolutely has to inspect headers, whether you like that or not. That is > how SA determines exactly that last, trustworthy, "physical" IP. And for > that, trusted and internal networks need be correct, so by extension > external networks also are correct. and the machine SA is running on receiving the message adds that header which is in case of direct testing the one and only and so trustable > In particular, your MX, your first internal relay, absolutely MUST be > trusted by SA. That is the SMTP relay identifying the sending host, > complete with IP and rDNS. again: the machine running SA *is the MX* > Received headers before that simply CANNOT be trusted. There is no way > to guarantee the host they claim to have received the message from is > legit in case running postfix with SA as milter *there are no* Received headers *before* because there is nobody before
signature.asc
Description: OpenPGP digital signature
