Le 03/01/2011 15:19, /dev/rob0 a écrit : > On Mon, Jan 03, 2011 at 08:48:02AM +0100, J. Roeleveld wrote: >> On Monday 03 January 2011 04:12:46 Wietse Venema wrote: >>> Mark Scholten: >>>> Should I look in the source or is there a better location to >>>> change the texts returned by Postfix after the error code for >>>> a connecting MTA? I'd like to give custom messages back for >>>> (example) a failed rDNS check or helo check. I don't want to >>>> change the returned number (421 or 550 if I'm correct), just >>>> the message to point them to a page we own to get information >>>> about how to fix the error or request whitelisting for the >>>> check. >>>> >>>> Changing the messages in the source isn't something I'd like >>>> to do, but if that is the location to change it I'll change it >>>> there. I didn't find it in the documentation (but I might have >>>> overlooked something). >>> >>> This is not configurable. >> >> Just out of curiosity, why is this not configurable? > > But it is,
No, it is not. > at least via access(5) workarounds. Simply (haha :) ) > replace all your built-in checks with their check_mumble_access > equivalents. For example, reject_unknown_reverse_client_hostname: a > check_reverse_client_hostname_access lookup of "unknown": > > unknown 450 4.7.1 Reverse DNS for your IP address was not > found. Please see http://postmaster.example.org/?code > for our super-friendly explanation of the problem, > and for alternate contact instructions. > With this, you have no way of detecting "temporary" failure. anyway, I challenge you to tell me how I could put custom error text for all postfix checks;-p This is a postfix limitation. no point trying to argue around. > (N.B. I did not look up the proper DSN for this restriction. If > you're planning to do this for real, you should.) > > For more complex messages possibly including the rejected tokens, a > policy service is the way to go. > > http://www.postfix.org/SMTPD_POLICY_README.html sure. milters are a little more portable. proxy_filter is better. an smtp proxy before any MTA is probably the way to go. > >> And would a feature request for this be appreciated? >> >> Having the return-message link to a maintained webpage providing >> information/help on how to resolve the issue might actually be >> useful.
