> > +<pre> > > +/etc/postfix/main.cf: > > + smtpd_reject_footer_maps = > > regexp:/etc/postfix/override_smtpd_replies.regexp > > + > > +/etc/postfix/override_smtpd_replies.regexp: > > + /^550 5.1.1 (<[^>]*>):/ \r$1: Adresse destinataire invalide > > +</pre> > > + > > +<p> Server response: </p> > > + > > +<pre> > > + 550 5.1.1 <f...@example.com>: Adresse destinataire invalide > > +</pre> > > + > > <p> Note: the above text is meant to make it easier to find the > > Postfix logfile records for a failed SMTP session. The text itself > > A basic requirement is that the name of a feature must match its > behavior. > > The purpose of smtpd_reject_footer is to APPEND TEXT, not to REPLACE > it. Therefore, smtpd_reject_footer should not replace text. > > The purpose your feature is to REPLACE TEXT, not to APPEND it. > Therefore, your feature should be called smtpd_reject_filter > (or smtpd_reply_filter if you want to go all the way).
Fully agree, it is what I mean when I wrote : >> smtpd_reject_footer and smtpd_reject_footer_maps don't fully make the job >> because >> these parameters add a footer and don't replace the original text (yes, like >> the name >> of the parameters can suggest !). Indeed I took the easiest way to implement the feature, Postfix as so many parameters that I was not sure that adding a new one was a good idea. Glad that you propose to implement this way. However things will be more complicated : should new smtpd_reply_filter_maps and smtpd_reject_footer_maps be executed in sequence ? or be exclusive ? Another option is to have smtpd_reply_filter_maps be an alias of smtpd_reply_footer_maps and smtpd_reply_footer_maps marked as deprecated. I'm going to implement smtpd_reply_filter_maps and make a proposal soon. Sébastien
