"Wietse Venema"
> Example:
>
> /etc/postfix/main.cf:
> smtpd_reject_contact_information = For assistance, call
800-555-0101
>
> Server response:
>
> 550-5.5.1<u...@example>: Recipient address rejected: User unknown
> 550 5.5.1 For assistance, call 800-555-0101
>
> This feature is available in Postfix 2.8.
This is a static main.cf parameter like myhostname, not a dynamic
table lookup result like DNSBL response maps. I don't understand
how one would make this configurable depending on client input.
FYI the time window for Postfix 2.8 changes is closing really soon.
If there remains controversy on how this feature should work then
it should not be included with the Postfix 2.8 stable release.
Wietse
How am I supposed to figure out and dynamically insert the remote sys admin's phone number, for every domain that sends
us mail?
So shouldn't the default text be?
smtpd_reject_contact_information = Sender, for assistance call YOUR system admin (not us) and tell them to fix the
problem
Just kidding! (sort of)
But I don't see the point of adding more generic information in the response.
We reject plenty of mail via RBLs, but we rarely get an email asking us why an RBL blocked email was rejected. The
client specific url included in the RBL reject seems to work very well. If the remote admin calls or emails, I can just
point them to the url and tell them to fix their servers.
The only rejects that I get calls or emails about are:
reject_non_fqdn_helo_hostname,
reject_unknown_helo_hostname,
reject_unknown_client_hostname,
reject_unknown_reverse_client_hostname
If these four rejects had individually configurable error text, it would help a
lot.
Instead of Helo command rejected: Host not found, I could choose to return:
Helo command rejected: Host not found; see example.tld?helo=somedomain.local
Then I can provide detailed info on why the email was rejected, and provide links to best practices and resources on
fixing their problem.
For each of these rejects, the client IP or host name that triggered the reject is already included in the response. So
it seems like all we need is a way to set or add to the response text, and a variable that holds the client IP or
hostname.
