J. Roeleveld:
> On Monday 03 January 2011 04:12:46 Wietse Venema wrote:
> > Mark Scholten:
> > > Hello,
> > >
> > > 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.
> >
> > Wietse
>
> Just out of curiosity, why is this not configurable?
Postfix source code is "free" for you, but it actually requires
real human effort by maintainers, and making all the reject response
texts configurable would be a major project.
> And would a feature request for this be appreciated?
Instead of making every response configurable, a more practical
solution is to configure ONE response that gets appended to ALL
the SMTP server's reject messages. Effectively, this turns the
one-line reject into a two-line response, one chosen by Postfix
and one chosen by the system adminstrator.
This can be done in the SMTP output routine. It also means that
421 4.4.2 host.example.com Error: timeout exceeded
becomes:
421-4.4.2 host.example.com Error: timeout exceeded
421 4.4.2 For assistance, contact the helpdesk at 800-555-0101
I wonder how many calls you would actually get for that.
That said, the likelihood that someone will actually pay attention
to the gibberish from SMTP server responses is small. It sounds
like something that keeps lawyers happy.
Wietse
> Having the return-message link to a maintained webpage providing
> information/help on how to resolve the issue might actually be useful.
>
> Thanks,
>
> Joost Roeleveld
>
>
