On Friday 25 March 2005 04:44 pm, Jeffrey L. Taylor wrote:
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>: [snip]
warn_if_reject reject_unknown_recipient_domain,
Why would you ever have to warn about rejecting unknown recipient domains? Did you expect to receive mail to domains that your mail server couldn't resolve, or send mail to similarly unresolvable domains? :)
Note smilie. It's frequently used to denote something intended to be interpreted as kidding, ribbing, a joke, in good humor, etc. There was some truth to it, though, so I'll share the reasoning.
I would like to know what I am about to reject before I actually start throwing mail in the trash sight unseen. Note: pogo.bearhouse.lan is a host name that is legitimate in MY system. If the wrong DNS server is being used to resolve addresses, it will be unknown. Any messages from it are likely to be critical.
Unknown hostname messages are rejected with a 4xx error, which means "temporarily failure, try again later" (unless you've foolishly changed that setting). You'd probably notice if your DNS didn't work for more than 5 days, and the deferred message will be accepted once DNS is fixed. Either way, a message won't be discarded for a DNS error until the remote mail host has decided to stop trying, which is generally after 5 days, minimum, and even then, it's bounced by the remote host, not yours. More specifically, you should not be using DNS to determine 1) the local recipients (those are defined in postfix config files) or 2) relay domains (also defined in a config file). So, locally-destined messages are unaffected by DNS problems. Messages *from* local machines are explicitly allowed by permit_mynetworks, which is a short-circuit that skips the remaining rules. Therefore, the restriction won't ever apply to locally-originating mail or locally-destined mail. Knowing how it works gives you 100% assurance of that. Before reading that, you were just "pretty sure" that everything was alright, since random testing hadn't shown up a problem yet. Hooray for knowledge!
The bottom line is that I do not know the effect of all my restrictions before I try them out. The results of some have been surprising. I would rather look at a few extra e-mails in the possible spam folder than lose a message. There are messages that have been flagged as possible spam that were critical to my business and/or the health of my systems. Having them silently discarded would have cost me significant money.
Then it might be worth the time to learn about them, rather than blindly experimenting. If you don't know what they're doing, then how do you know that you've tested long enough? What if that million-dollar email comes through a few days after you've arbitrarily decided that testing is "good enough"? Testing on random messages - which may or may not be representative of all possibilities - for an arbitrary amount of time does not replace learning exactly what it is that you're doing. It may be that, in some cases, the testing is probably "good enough", but it doesn't sound like "probably good enough" is the goal. The only way to get the absolute reliability that you're after is to 1) learn exactly what's happening and 2) test with a defined set of messages that should pass and should fail. That's what the X-client capability is intended for - *structured* testing to be sure that your understanding is correct. --Danny, not limiting this point of view to SMTP, or even computers