Paweł Leśniak a écrit : > mouss pisze: >> >> reject_unknown_helo_hostname would indeed be too aggressive. but you >> could use restriction classes and only call it if the sender is null >> (<>). >> >> or you could run aggressive checks if the client has a "generic" reverse >> dns. or in this particular case, simply reject *.rev.dynxnet.com with a >> check_client_access: >> rev.dynxnet.com REJECT blah blah >> .rev.dynxnet.com REJECT blah blah >> > > If I'll have any trouble with reject_unknown_helo_hostname sitewide I'll > change it according to information above.
using reject_unknown_helo_hostname site wide is risky. problems will happen when you will stop watching! (at least, this was my experience although it was a few years ago). if you still want to use it, you can: - use DNSWL so that whitelisted clients are never blocked/deferred - you can also have a local whitelist - have a log parser that looks for 4xx because of unresolved helo, do some checks, and possibly whitelist the client so that it is accepted at the next retry. of course, this assumes a 4xx code (this is the default). > For now I'll have some time to think over BATV (full-blown or "poorman" > versions) - each simplified solution has some disadvantages which on > first sight are not good at my site (ex. changing submission port means > to me reconfiguration of over 100 standalone PCs...). > yes. that said, enable the submission service and start "migrating". This is the recommended way. note that if users access the server from mynetworks, you can use a NAT redirection to divert traffic to the submission port. This can help during the "migration". it is possible to implement the message-id rewrite while using a single port (25), by passing traffic to another smtpd using the FILTER statement, but this may be too much for the job...
