On Thu, Feb 23, 2012, at 03:35 PM, Wietse Venema wrote: > You have the spamtrap address configured on 127.0.0.1, but you > telnet to 192.168.1.10, and then you are surprised that the SMTP > server on 192.168.1.10 does not know about the spamtrap address.
Frakly, I'm not suprised by a thing. I'm simply looking at what's in front of me, asking questions about it knowing full well that something's not quite right -- as I've mentioned several times -- and trying to dig through dribbles of sometimes conflicting responses. I'm a new user taking the time to learn this product and explore it's capabilities. I doubt that you're suprised that there's a lot to learn and explore. This is a user list where users come to ask questions, right? Is it a prerequisite that we know answers, or recognize which among the conflicting ones provides are correct, before asking our questions? If it is, please let me know. > If you want to reject the spamtrap address while connected to 192.168.1.10 As I've said repeatedly -- I'm not wedded to a method. Just the outcome. I'm looking to others, here, to advise what the best approach is to achive my clearly stated goals. > then you need to implement the spamtrap check at 192.168.1.10. Happy to. Where and how? *Specifically*, at which stage? To the best of my ability, I've attempted to follow the examples provided on the site and in posts. Attempting to understand what's depicted and properly extend it to my use case, that seems to include only postscreen listening on the 'real' external address(es), and "the rest" listening on localhost:various_ports for handoffs. I was *specifically* advised on this list, in this thread, to add the check to the reinjection listener on localhost:10026. If that's not the correct advice, can you kindly clarify -- for the *specific* configuration I've provided per request at: http://marc.info/?l=postfix-users&m=133002076514425&w=2 What specific changes need be made? Your admonition to "then you need to implement the spamtrap check at 192.168.1.10" still leaves me unclear. Roger
