On 21-02-13 19:17, DTNX Postmaster wrote:
You keep blaming the documentation and the software, when the problem is most likely in your understanding of it.
Yes I blame the documentation, but not the software. I've been using postfix for, well, something like ten years or more, I think it's the best thing since sliced bread, especially compared to sendmail, qmail and exchange.
The way I've configured it now, really suits the demands. I cannot remember any phrases in the documentation recommending not to do it this way (i.e. start multiple smtp listeners on different addresses with different options, in one master process). If it actually appears to be disrecommended, then that's clear to me, no problem.
Simplify your configuration. Don't assume that what goes for 'smtpd' goes for 'postscreen' as well.
I'd like to, but where do I find what I CAN assume? The factual documentation of postscreen is so sparse, it's mostly HOWTO, monkey-see-monkey-do.
Pick sensible defaults for 'main.cf', and override only the options that are absolutely necessary.
That's already done.
If you have a legitimate reason (as in, contractual obligations or whatnot) to require seperate hostnames, greetings, TLS settings and such, use the multi-instance features and seperate them. Otherwise the KISS principle applies.
Actually this way is much more KISS to me than running multiple instances of "master".
I'm starting to think that the reason this operation is not documented, is because it's not possible. It looks like the postscreen layer literaly sits between the remote client and the smtp process, and the information where the connection took place (interface/address) is not available at the point where the smtpd is invoked.
If that's the case, postscreen is not the way to go for me. I assumed postscreen was implemented a bit like proxy-filter, where you can run any number of filters on any number of addresses.
smime.p7s
Description: S/MIME Cryptographic Signature
