Change error messages returned by Postfix
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).
With kind regards,
Mark Scholten
Wietse Venema
This is not configurable.
Wietse
Jerrale G
:)
Jerrale G.
SC Senior Admin
Jerrale G
./src/smtpd/smtpd_check.c
J. Roeleveld
> 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?
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.
Thanks,
Joost Roeleveld
/dev/rob0
> On Monday 03 January 2011 04:12:46 Wietse Venema wrote:
> > Mark Scholten:
> > > 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.
>
But it is, 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.
(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
> 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.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
Wietse Venema
> 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?
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
>
>
Ralf Hildebrandt
> 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.
Almost none, because users cannot read.
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
ralf.hil...@charite.de | http://www.charite.de
John Adams
> * Wietse Venema<wie...@porcupine.org>:
>
>> 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.
>
> Almost none, because users cannot read.
>
well, actually they can. They just don't read the automated gibberish
that comes from us admins.
Ralf Hildebrandt
> >Almost none, because users cannot read.
>
> well, actually they can. They just don't read the automated gibberish
> that comes from us admins.
:)
Victor Duchovni
> * Wietse Venema <wie...@porcupine.org>:
>
> > 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.
>
> Almost none, because users cannot read [bounce messages].
They understand that the message did not arrive:
http://funstoo.blogspot.com/2010/12/what-we-say-to-dogs-what-they-hear.html
This said, in a B2B context, a less experienced postmaster of a
remote domain may in some cases benefit from a link to a more detailed
explanation of an SMTP reject message. A fixed suffix for SMTP error
responses is probably the right cost/benefit trade-off.
--
Viktor.
Ralf Hildebrandt
> This said, in a B2B context, a less experienced postmaster of a
> remote domain may in some cases benefit from a link to a more detailed
> explanation of an SMTP reject message. A fixed suffix for SMTP error
> responses is probably the right cost/benefit trade-off.
Recently a postmaster of a remote domain was complaining they couldn't
send mail to us, because ONE of our THREE MX hosts was not accepting
connections. The other two were.
John Adams
> On Mon, Jan 03, 2011 at 07:44:51PM +0100, Ralf Hildebrandt wrote:
>
>> * Wietse Venema<wie...@porcupine.org>:
>>
>>> 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.
>>
>> Almost none, because users cannot read [bounce messages].
hmmm.
> They understand that the message did not arrive:
>
> http://funstoo.blogspot.com/2010/12/what-we-say-to-dogs-what-they-hear.html
>
:)
> This said, in a B2B context, a less experienced postmaster of a
> remote domain may in some cases benefit from a link to a more detailed
> explanation of an SMTP reject message. A fixed suffix for SMTP error
> responses is probably the right cost/benefit trade-off.
That's when you get calls from the remote site admin where he wants you
to remove him from your postgrey greylist because his users cannot send
mails to site x of customer x where postgrey runs. Real reason for
failure: site x runs an ancient version of postgrey and the calling
admin's mail server does not handle 451 correctly. Sometimes it really
takes time to make them understand that postgrey IS NOT a dns based
(black|grey)list or whatever.
mouss
> On Mon, Jan 03, 2011 at 08:48:02AM +0100, J. Roeleveld wrote:
>>> Mark Scholten:
>>>> 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.
>>
>
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?
>>
mouss
> J. Roeleveld:
>> 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?
>
> real human effort by maintainers, and making all the reject response
> texts configurable would be a major project.
>
>
> 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 For assistance, contact the helpdesk at 800-555-0101
>
> I wonder how many calls you would actually get for that.
>
> to the gibberish from SMTP server responses is small. It sounds
> like something that keeps lawyers happy.
>
I bet to disagree here. there is a case for something like
XXX .... check http://postmaster.example.com/rejected.html
or even better,
... http://..../why?transactionid=4577123
and so on.
I don't care if end users don't get the message because their exchange
"translate" it. but I do care if admins see the reason before they fire
their phone.
J. Roeleveld
> 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.
I'm not familiar with the source code of postfix, which is why I asked.
I think if someone really wants this, he/she would need to do most of the work
and convince you and your colleagues to add the patches to the code.
> > 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.
I'd put a webpage there instead of a number, but not many people actually get
to see those codes.
I'm not even sure this full text would appear in the result of "mailq" which
is the first place I look when I find my emails are not arriving.
> 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.
Which is not necessarily a good thing :)
--
Joost
PS. All the best wishes for 2011 to everyone
Mark Scholten
> -----Original Message-----
> From: owner-pos...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Victor Duchovni
> Sent: Monday, January 03, 2011 8:00 PM
> To: postfi...@postfix.org
> Subject: Re: Change error messages returned by Postfix
>
> On Mon, Jan 03, 2011 at 07:44:51PM +0100, Ralf Hildebrandt wrote:
>
> > * Wietse Venema <wie...@porcupine.org>:
> >
> > > 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.
After updating our anti-spam rules/rDNS checks: probably more than expected
Would it be an option to get something like the thing below for all error
messages?
421 4.4.2 host.example.com Error: timeout exceeded - for more information
see http://postmaster.domain.tld/[ip]-[code].html
Where [ip] has to be replaced with the client IP and [code] has to be
replaced with the error code (421 in this example). Using a certain error
code for certain types of blocks would make it possible to display the
correct page directly (or at least limit the input required from the person
following the link).
> > Almost none, because users cannot read [bounce messages].
>
> They understand that the message did not arrive:
>
> http://funstoo.blogspot.com/2010/12/what-we-say-to-dogs-what-they-
> hear.html
>
> This said, in a B2B context, a less experienced postmaster of a
> remote domain may in some cases benefit from a link to a more detailed
> explanation of an SMTP reject message. A fixed suffix for SMTP error
> responses is probably the right cost/benefit trade-off.
Informing other postmasters of a remote domain/server is the main reason we
are looking for this option (or have to manually change things). If they
could find why it was blocked and the reason it was blocked would probably
reduce the support calls about the mailservers.
Regards, Mark
Wietse Venema
> 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.
I have added this yesterday to Postfix 2.8. This provides a fixed
text that is added as an extra line to server responses.
Wietse
smtpd_reject_contact_information (default: empty)
Optional contact information that is appended after each SMTP server
4XX or 5XX response.
Example:
/etc/postfix/main.cf:
smtpd_reject_contact_information = For assistance, call 800-555-0101
Server response:
550-5.5.1 <user@example>: Recipient address rejected: User unknown
550 5.5.1 For assistance, call 800-555-0101
This feature is available in Postfix 2.8.
John Adams
Cool. Thanks.
Can this be configured in a multi-domain environment e.g. via
restriction classes in a way where every domain admin can supply his
own contact details?
Wietse Venema
> > Example:
> >
> > /etc/postfix/main.cf:
> > smtpd_reject_contact_information = For assistance, call 800-555-0101
> >
> > Server response:
> >
> > 550-5.5.1<user@example>: Recipient address rejected: User unknown
> > 550 5.5.1 For assistance, call 800-555-0101
> >
> > This feature is available in Postfix 2.8.
>
> Cool. Thanks.
> Can this be configured in a multi-domain environment e.g. via
> restriction classes in a way where every domain admin can supply his
> own contact details?
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
Victor Duchovni
>> 550-5.5.1<user@example>: Recipient address rejected: User unknown
>> 550 5.5.1 For assistance, call 800-555-0101
>>
>> This feature is available in Postfix 2.8.
>
> Cool. Thanks.
> Can this be configured in a multi-domain environment e.g. via restriction
> classes in a way where every domain admin can supply his own contact
> details?
If you want multiple Postfix personalities, use multiple Postfix instances:
http://www.postfix.org/MULTI_INSTANCE_README.html
If you have light-weight instances via master.cf smtpd/inet services
bound to secondary IPs, you can configure each instance with a different
response via "-o" overrides.
Otherwise, the feature is correctly designed to append optional contact
information for the *system administrator* or a troubleshooting help URL
for senders having trouble delivering email via the *system* in question.
--
Viktor.
John Adams
> On Tue, Jan 04, 2011 at 01:24:51PM +0100, John Adams wrote:
>
>>> 550-5.5.1<user@example>: Recipient address rejected: User unknown
>>> 550 5.5.1 For assistance, call 800-555-0101
>>>
>>> This feature is available in Postfix 2.8.
>>
>> Cool. Thanks.
>> Can this be configured in a multi-domain environment e.g. via restriction
>> classes in a way where every domain admin can supply his own contact
>> details?
>
> If you want multiple Postfix personalities, use multiple Postfix instances:
>
> http://www.postfix.org/MULTI_INSTANCE_README.html
That is very interesting. Thanks for the link.
>
> If you have light-weight instances via master.cf smtpd/inet services
> bound to secondary IPs, you can configure each instance with a different
> response via "-o" overrides.
>
> Otherwise, the feature is correctly designed to append optional contact
> information for the *system administrator* or a troubleshooting help URL
> for senders having trouble delivering email via the *system* in question.
>
Yes, I understand that. But that is not how I experienced the world.
Usually, if person X from domain X could not mail to person Z from
domain Z for a reject reason given by mail provider M, then X would call
Z (I cannot send you mails) and Z would call M (X cannot send us mails).
Does this sound reasonable to you?
Victor Duchovni
> Yes, I understand that. But that is not how I experienced the world.
> Usually, if person X from domain X could not mail to person Z from domain Z
> for a reject reason given by mail provider M, then X would call Z (I cannot
> send you mails) and Z would call M (X cannot send us mails). Does this
> sound reasonable to you?
The mail provider implements all technologies associated with the mail
system, including any troubleshooting HTML for legitimate servers who
encounter difficulties.
Sure, if the sender knows the recipient domain's (M's client's) contact
information he/she can start there, but M's SMTP servers should in most
cases refer the sender to M's help page and M's contact information.
The new 2.8 feature is a reasonable cost/benefit trade-off.
--
Viktor.
Mark Scholten
> Wietse Venema:
> > 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.
>
> I have added this yesterday to Postfix 2.8. This provides a fixed
> text that is added as an extra line to server responses.
>
> Wietse
>
> smtpd_reject_contact_information (default: empty)
> Optional contact information that is appended after each SMTP
> server
> 4XX or 5XX response.
>
>
> /etc/postfix/main.cf:
> smtpd_reject_contact_information = For assistance, call 800-
> 555-0101
>
> Server response:
>
> unknown
> 550 5.5.1 For assistance, call 800-555-0101
>
> This feature is available in Postfix 2.8.
Thank you. Is it possible to let this new setting contain something that
contains the client IP and/or something so we could identify it with a
script? That way we could make it contain more information directly, however
that is more a "nice to have" than show stopper for us.
Regards, Mark
Victor Duchovni
> > Server response:
> >
> > 550-5.5.1 <user@example>: Recipient address rejected: User
> > unknown
> > 550 5.5.1 For assistance, call 800-555-0101
> >
> > This feature is available in Postfix 2.8.
>
> Thank you. Is it possible to let this new setting contain something that
> contains the client IP and/or something so we could identify it with a
> script?
Identify what with a script?
- The SMTP reject message appears in the receiving Postfix system's logs,
where the client's IP is always part of the logged context.
- The SMTP reject message appears in the client system's logs.
The client knows its own IP.
- The SMTP reject message appears in the non-delivery DSN generated
by the client system and returned to the envelope sender. This will
in most cases (qmail's non-MIME bounces aside) contain the standard
DSN fields, including the reporting MTA name.
The static appended response is for *contact* information or a reference
web-site.
--
Viktor.
Wietse Venema
> On Tue, Jan 04, 2011 at 03:36:41PM +0100, Mark Scholten wrote:
>
> > > Server response:
> > >
> > > 550-5.5.1 <user@example>: Recipient address rejected: User
> > > unknown
> > > 550 5.5.1 For assistance, call 800-555-0101
> > >
> > > This feature is available in Postfix 2.8.
> >
> > Thank you. Is it possible to let this new setting contain something that
> > contains the client IP and/or something so we could identify it with a
> > script?
>
> Identify what with a script?
>
I'm just guessing, but I suspect that this is about making trouble
shooting easier, like putting some unique "trouble ticket" like
string in the 4XX or 5XX response that is easily located in the
logfile, so they can quickly locate the entire session in the log.
smtpd_reject_contact_information =
For assistance, call 800-555-0101 with ticket $instance
(where instance is the SMTP server PID and a sequence number, it's
the same attribute used in the SMTP policy server protocol).
This is not as simple as it sounds (apart from the need to provide
the $name expansion module).
Postfix currently does NOT log the contact footer to the maillog
file. There are tons of places in Postfix that reject a command
(e.g., bad syntax, or some requested feature not available) without
logging that the command was rejected. That would just make it too
easy for the bad guys to flood the maillog file with garbage.
I could change postfix to ALWAYS log the contact footer to the
maillog fil3, but then you'd get lots of contact footers in the
maillog without any indication of why they were logged.
Wietse
Victor Duchovni
> > > Thank you. Is it possible to let this new setting contain something that
> > > contains the client IP and/or something so we could identify it with a
> > > script?
> >
> > Identify what with a script?
> >
> >[talk about stuff in logfiles]
>
> I'm just guessing, but I suspect that this is about making trouble
> shooting easier, like putting some unique "trouble ticket" like
> string in the 4XX or 5XX response that is easily located in the
> logfile, so they can quickly locate the entire session in the log.
>
> smtpd_reject_contact_information =
> For assistance, call 800-555-0101 with ticket $instance
>
> (where instance is the SMTP server PID and a sequence number, it's
> the same attribute used in the SMTP policy server protocol).
>
> This is not as simple as it sounds (apart from the need to provide
> the $name expansion module).
>
> Postfix currently does NOT log the contact footer to the maillog
> file. There are tons of places in Postfix that reject a command
> (e.g., bad syntax, or some requested feature not available) without
> logging that the command was rejected. That would just make it too
> easy for the bad guys to flood the maillog file with garbage.
>
> I could change postfix to ALWAYS log the contact footer to the
> maillog fil3, but then you'd get lots of contact footers in the
> maillog without any indication of why they were logged.
I don't think that the 50X or other unlogged error responses should
start logging "disembodied" contact footers. If the contact footer is
to log some unique identifier, then just that identifier could perhaps
be added as a standard element of the log_whatsup() message...
May have to initialize the instance id on entry to mail_cmd() rather
than when it is (about to be) accepted.
The smtpd_chat_reply() routine would then append the same instance
id to the contact footer.
--
Viktor.
Wietse Venema
> > I'm just guessing, but I suspect that this is about making trouble
> > shooting easier, like putting some unique "trouble ticket" like
> > string in the 4XX or 5XX response that is easily located in the
> > logfile, so they can quickly locate the entire session in the log.
> >
> > smtpd_reject_contact_information =
> > For assistance, call 800-555-0101 with ticket $instance
> >
> > (where instance is the SMTP server PID and a sequence number, it's
> > the same attribute used in the SMTP policy server protocol).
> >
> > This is not as simple as it sounds (apart from the need to provide
> > the $name expansion module).
> >
> > Postfix currently does NOT log the contact footer to the maillog
> > file. There are tons of places in Postfix that reject a command
> > (e.g., bad syntax, or some requested feature not available) without
> > logging that the command was rejected. That would just make it too
> > easy for the bad guys to flood the maillog file with garbage.
> >
> > I could change postfix to ALWAYS log the contact footer to the
> > maillog fil3, but then you'd get lots of contact footers in the
> > maillog without any indication of why they were logged.
>
> I don't think that the 50X or other unlogged error responses should
> start logging "disembodied" contact footers. If the contact footer is
> to log some unique identifier, then just that identifier could perhaps
> be added as a standard element of the log_whatsup() message...
Some people might disagree and say that Postfix should log ALL
rejects (including bad syntax/unsupported command). Currently, it
leaves helpdesk people scratching their head what to look for in
the maillog file when someone asks for help with a mail delivery
problem.
This requires more than simply logging all 4XX and 5XX responses,
because you also need to know log the command itself that is being
rejected. That is too much change before the Postfix 2.8 release.
What I could do for now is a contact footer with dynamic context
such as the SMTP server PID and client IP address. That information
is already in the maillog file.
So this would change the feature to:
smtpd_reject_contact_information =
For assistance, call 800-555-0101 (pid=$pid, client=$client_addr)
The result would look like:
554-5.5.1 <user@example>: Recipient address reject: User unknown
554 5.5.1 For assistance, call 800-555-0101 (pid=7283, client=192.168.1.248)
The helpdesk person then looks for "[7283]" and "192.168.1.248" in
the maillog file. This would lift some, but not all, of the mystery
with commands that Postfix rejects (syntax, etc.) without logging
them.
Wietse
Victor Duchovni
> What I could do for now is a contact footer with dynamic context
> such as the SMTP server PID and client IP address. That information
> is already in the maillog file.
>
> So this would change the feature to:
>
> smtpd_reject_contact_information =
> For assistance, call 800-555-0101 (pid=$pid, client=$client_addr)
>
> The result would look like:
>
> 554-5.5.1 <user@example>: Recipient address reject: User unknown
> 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, client=192.168.1.248)
>
> The helpdesk person then looks for "[7283]" and "192.168.1.248" in
> the maillog file. This would lift some, but not all, of the mystery
> with commands that Postfix rejects (syntax, etc.) without logging
> them.
This would likely need to also be implemented in postscreen. :-( If
keyword-substitution is supported, apart from $pid, and $client_addr
also $rfc822_date would perhaps be useful to help search logs for the
right day.
With this, there is no need to separately log the helpful footer, the
information is already present in the receiving server logs, the footer
makes it more readily available to sender sites to aid in event correlation.
--
Viktor.
Wietse Venema
> On Tue, Jan 04, 2011 at 12:54:24PM -0500, Wietse Venema wrote:
>
> > What I could do for now is a contact footer with dynamic context
> > such as the SMTP server PID and client IP address. That information
> > is already in the maillog file.
> >
> > So this would change the feature to:
> >
> > smtpd_reject_contact_information =
> > For assistance, call 800-555-0101 (pid=$pid, client=$client_addr)
> >
> > The result would look like:
> >
> > 554-5.5.1 <user@example>: Recipient address reject: User unknown
> > 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, client=192.168.1.248)
> >
> > The helpdesk person then looks for "[7283]" and "192.168.1.248" in
> > the maillog file. This would lift some, but not all, of the mystery
> > with commands that Postfix rejects (syntax, etc.) without logging
> > them.
>
> This would likely need to also be implemented in postscreen. :-( If
> keyword-substitution is supported, apart from $pid, and $client_addr
> also $rfc822_date would perhaps be useful to help search logs for the
> right day.
PID logging isn't useful with postscreen(8) because there is only
one process, so I'll add a localtime attribute. The rfc822_date
string seems too long to be useful; we need something that people
can use in a phone call.
> With this, there is no need to separately log the helpful footer, the
> information is already present in the receiving server logs, the footer
> makes it more readily available to sender sites to aid in event correlation.
Yes, that was the idea, giving the client some of the session
attributes that are already in the logs.
Wietse
pf at alt-ctrl-del.org
"Wietse Venema"
>> > Example:
>> >
>> > /etc/postfix/main.cf:
>> >
>> > 550-5.5.1<user@example>: Recipient address rejected: User unknown
>> > 550 5.5.1 For assistance, call 800-555-0101
>> >
>> > This feature is available in Postfix 2.8.
>>
> 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.
Victor Duchovni
> > This would likely need to also be implemented in postscreen. :-( If
> > keyword-substitution is supported, apart from $pid, and $client_addr
> > also $rfc822_date would perhaps be useful to help search logs for the
> > right day.
>
> PID logging isn't useful with postscreen(8) because there is only
> one process, so I'll add a localtime attribute. The rfc822_date
> string seems too long to be useful; we need something that people
> can use in a phone call.
So long as localtime is date + time: often help queries get to the
right people days after the original event, and it is important to
know when the reported issue is purported to have happened.
--
Viktor.
Victor Duchovni
> But I don't see the point of adding more generic information in the
> response.
Providing a URL of a website which explains (for the reject messages
that you choose to document) what a sender needs to do to avoid being
reject will do no harm when appended to reject messages that are
already "self-documenting" or which you would choose to no explain
further. The URL can explain that too.
> 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.
There are surely more, and making the text context-specific is likely
not a good cost/benefit trade-off.
--
Viktor.
Jeroen Geilman
>
> The only rejects that I get calls or emails about are:
> reject_non_fqdn_helo_hostname,
> reject_unknown_helo_hostname,
> reject_unknown_client_hostname,
Don't blindly use that. It causes a LOT of false positives.
> reject_unknown_reverse_client_hostname
That's safer to use.
>
> 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
What would that tell the sender *admin* that he didn't already know ?
Note that information in SMTP logs and sessions is generally only read
by, and therefore only useful to, system admins.
--
J.
pf at alt-ctrl-del.org
"Jeroen Geilman":
> On 1/4/11 8:32 PM, pf at alt-ctrl-del.org wrote:
>>
>> The only rejects that I get calls or emails about are:
>> reject_non_fqdn_helo_hostname,
>> reject_unknown_helo_hostname,
>> reject_unknown_client_hostname,
>
> Don't blindly use that. It causes a LOT of false positives.
>
>> reject_unknown_reverse_client_hostname
>
> That's safer to use.
>
I only use the tougher ones against null senders and specific tlds, countries or IP ranges.
>>
>> 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
>
> What would that tell the sender *admin* that he didn't already know ?
> Note that information in SMTP logs and sessions is generally only read by, and therefore only useful to, system
> admins.
>
I'm guessing that if the remote admin knew, we wouldn't have a problem...
The reject text is often also included in the delivery status notification that gets returned to the sender.
I'm trying to stop the chain of:
Sender calls recipient, recipient calls their tech, recipient's tech calls me... Then I tell them to contact the
sender's admin... Then the sender's admin claims that "everyone" else accepts their email, even though they don't have
any reverse dns, and suggests that I add an exception for their servers.
I would hope that occasionally someone in that chain would notice the url and read it, saving everyone else's time.
I rarely get "why are you blocking me?" for rbl listed domains, so I'm guessing that those client specific self service
urls do provide some benefit.
Wietse Venema
> > > So this would change the feature to:
> > >
> > >
> > > The result would look like:
> > >
> > > 554-5.5.1 <user@example>: Recipient address reject: User unknown
> > > 554 5.5.1 For assistance, call 800-555-0101 (pid=7283, client=192.168.1.248)
> > >
> > > The helpdesk person then looks for "[7283]" and "192.168.1.248" in
> > > the maillog file. This would lift some, but not all, of the mystery
> > > with commands that Postfix rejects (syntax, etc.) without logging
> > > them.
> PID logging isn't useful with postscreen(8) because there is only
> one process, so I'll add a localtime attribute. The rfc822_date
> string seems too long to be useful; we need something that people
> can use in a phone call.
Having implemented $name expansion, I find that it is easy produce
long contact footer text, so I have added multi-line support.
Unfortunately, multi-line footers can be harder to read. For example,
Postfix will word-wrap multi-line replies when it reports delivery
errors in a bounce message.
Suppose we have this nice multi-line contact footer:
554-5.5.1 <user@example>: Recipient address rejected: User unknown
554-5.5.1 For assistance, call 800-555-0101. Please mention the
554-5.5.1 following information in your problem report:
554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248
The logging would look something horrible like:
Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782:
to=<user@example>, relay=mail.example[192.168.1.58]:25,
delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced
(host mail.example[192.168.1.58] said: 550 554-5.5.1 <user@example>:
Recipient address rejected: User unknown 554-5.5.1 For assistance,
call 800-555-0101. Please mention the 554-5.5.1 following
information in your problem report: 554 5.5.1 localtime=Jan 4
15:42:00, client=192.168.1.248
The bounce message would look like:
<user@example>: host mail.example[192.168.1.58] said: 554-5.5.1
<user@example>: Recipient address rejected: User unknown 554-5.5.1 For
assistance, call 800-555-0101. Please mention the 554-5.5.1 following
information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00,
client=192.168.1.248
Final-Recipient: rfc822; user@example
Original-Recipient: rfc822; user@example
Action: failed
Status: 5.1.1
Remote-MTA: dns; mail.example
Diagnostic-Code: smtp; 554-5.5.1 <user@example>: Recipient address rejected:
User unknown 554-5.5.1 For assistance, call 800-555-0101. Please mention
the 554-5.5.1 following information in your problem report: 554 5.5.1
localtime=Jan 4 15:42:00, client=192.168.1.248
On the other hand with a single-line contact footer, there would
be no ugly "554-5.5.1" strings messing up the contact footer text:
Server response:
554-5.5.1 <user@example>: Recipient address rejected: User unknown
554 5.5.1 For assistance, call 800-555-0101. Please mention the following information in your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248
The logging remains more readable:
Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782:
to=<user@example>, relay=mail.example[192.168.1.58]:25,
delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced
(host mail.example[192.168.1.58] said: 550 554-5.5.1 <user@example>:
Recipient address rejected: User unknown 554-5.5.1 For assistance,
call 800-555-0101. Please mention the following information in
your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248
As does the bounce message text:
<user@example>: host mail.example[192.168.1.58] said: 554-5.5.1
<user@example>: Recipient address rejected: User unknown 554 5.1.1 For
assistance, call 800-555-0101. Please mention the following information in
your problem report: localtime=Jan 4 15:42:00, client=192.168.1.248
Final-Recipient: rfc822; user@example
Original-Recipient: rfc822; user@example
Action: failed
Status: 5.1.1
Remote-MTA: dns; mail.example
Diagnostic-Code: smtp; 554-5.5.1 <user@example>: Recipient address rejected:
User unknown 554 5.1.1 For assistance, call 800-555-0101. Please mention
the following information in your problem report: localtime=Jan 4 15:42:00,
client=192.168.1.248
Wietse
Noel Jones
>
> I'm trying to stop the chain of:
> Sender calls recipient, recipient calls their tech,
> recipient's tech calls me... Then I tell them to contact the
> sender's admin... Then the sender's admin claims that
> "everyone" else accepts their email, even though they don't
> have any reverse dns, and suggests that I add an exception for
> their servers.
>
> I would hope that occasionally someone in that chain would
> notice the url and read it, saving everyone else's time.
> I rarely get "why are you blocking me?" for rbl listed
> domains, so I'm guessing that those client specific self
> service urls do provide some benefit.
There won't be reject-specific text anytime soon; the effort
is just too high. Implementing custom text for just a few
reject_* restrictions would raise false expectations, and is
unlikely to be implemented judging from past half-solution
proposals.
A "generic" self-help web link that refers them to match the
first part of the reject message with a list of possibilities
should be sufficient. I believe this to be a fairly common
practice already.
-- Noel Jones
Jeroen Geilman
> I'm trying to stop the chain of:
> Sender calls recipient, recipient calls their tech, recipient's tech
> calls me... Then I tell them to contact the sender's admin... Then the
> sender's admin claims that "everyone" else accepts their email, even
> though they don't have any reverse dns, and suggests that I add an
> exception for their servers.
While I certainly see and agree with your point, I hope you realize that
that chain should have stopped with the sender admin reading his logs
and admitting he knows why it is being rejected.
HE's the one not doing a proper job as far as I am concerned.
Also, both sender AND recipient admin not being you only occurs if you
relay for $strangers. Not many people relay for $strangers anymore :)
--
J.
Victor Duchovni
> Having implemented $name expansion, I find that it is easy produce
> long contact footer text, so I have added multi-line support.
>
> Unfortunately, multi-line footers can be harder to read. For example,
> Postfix will word-wrap multi-line replies when it reports delivery
> errors in a bounce message.
>
> Suppose we have this nice multi-line contact footer:
>
> 554-5.5.1 <user@example>: Recipient address rejected: User unknown
> 554-5.5.1 For assistance, call 800-555-0101. Please mention the
> 554-5.5.1 following information in your problem report:
> 554 5.5.1 localtime=Jan 4 15:42:00, client=192.168.1.248
When the Postfix SMTP client consumes the multiple-lines of a multi-line
response, it should I think drop all but the first occurence of the
XYZ-A.B.C codes, making the two forms indistiguishable.
> The logging would look something horrible like:
>
> Jan 4 15:42:00 client postfix/smtp[25100]: B32E0924782:
> to=<user@example>, relay=mail.example[192.168.1.58]:25,
> delay=0.04, delays=0.01/0/0.01/0.01, dsn=5.1.1, status=bounced
> (host mail.example[192.168.1.58] said: 550 554-5.5.1 <user@example>:
> Recipient address rejected: User unknown 554-5.5.1 For assistance,
> call 800-555-0101. Please mention the 554-5.5.1 following
> information in your problem report: 554 5.5.1 localtime=Jan 4
> 15:42:00, client=192.168.1.248
Per the above this issue already applies when the remote server is not
Postfix, and the fix is IMHO to prune the codes from the interior of
the response.
>
> <user@example>: host mail.example[192.168.1.58] said: 554-5.5.1
> <user@example>: Recipient address rejected: User unknown 554-5.5.1 For
> assistance, call 800-555-0101. Please mention the 554-5.5.1 following
> information in your problem report: 554 5.5.1 localtime=Jan 4 15:42:00,
> client=192.168.1.248
Which solves the issue for bounces.
> On the other hand with a single-line contact footer, there would
> be no ugly "554-5.5.1" strings messing up the contact footer text:
>
Agreed, and since, we don't control all potential SMTP servers that may
generate a multi-line reply, we should perhaps deal with it on the client
side...
Here is a bounce in my queue trying to return to a Gmail-hosted spammer:
8A12750421C 1678 Sun Jan 2 10:55:26 MAILER-DAEMON
(host ALT1.ASPMX.L.GOOGLE.com[74.125.77.27] said: 450-4.2.1 The user you are trying to contact is receiving mail at a rate that 450-4.2.1 prevents additional messages from being delivered. Please resend your 450-4.2.1 message at a later time. If the user is able to receive mail at that 450-4.2.1 time, your message will be delivered. For more information, please 450 4.2.1 visit http://mail.google.com/support/bin/answer.py?answer=6592 v45si53059220eeh.66 (in reply to RCPT TO command))
--
Viktor.
mouss
> On 1/4/11 8:32 PM, pf at alt-ctrl-del.org wrote:
>>
>> The only rejects that I get calls or emails about are:
>> reject_non_fqdn_helo_hostname,
>> reject_unknown_helo_hostname,
>> reject_unknown_client_hostname,
>
> Don't blindly use that. It causes a LOT of false positives.
>
>> reject_unknown_reverse_client_hostname
>
> That's safer to use.
>
>>
>> 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
>
> What would that tell the sender *admin* that he didn't already know ?
a lot! (but I guess you meant "that he couldn't find if he really
tries", which is a different question).
one time a "partner" (in another life/job) got rejected because of a
composite rule the last of which was a reject_unknown_hostname (the goal
was to reject if this and that and that, but I wanted to benefit from
temp handling of reject_unknown_*. that was an error!). said partner
didn't understand the meaning of "unknown". so they tried to fake our
hostnameS, and they managed to knock our server every minute (ask me not
why I love exchange), and they tried many of our hostnames! as I had no
idea who these guys were. Actually, I had participated to their
selection as a partner, but I couldn't link the excessive probes from a
"random" indian network to them (which once again shows that people
should really use their "names" instead of generic or ISP domains), they
were blocked at firewall level. later on, they tried the phone and I
didn't know whether I had to laugh or cry when I understood what they
tried to do (they thought "unknown" was the opposite of "our domains"!!!
they didn't think a second that faking our domain was to make their
situation worst).
so yes, there is a case for "luser compatible" information. not that I
think it would solve any problem. but it would help to say "we did our
best: we provided a link. ask marketers/PR/lawyers/whomever to make it
clear. just don't ask tech guys about it again".
mouss
> On 1/4/2011 3:04 PM, pf at alt-ctrl-del.org wrote:
>>
>> I'm trying to stop the chain of:
>> Sender calls recipient, recipient calls their tech,
>> recipient's tech calls me... Then I tell them to contact the
>> sender's admin... Then the sender's admin claims that
>> "everyone" else accepts their email, even though they don't
>> have any reverse dns, and suggests that I add an exception for
>> their servers.
>>
>> notice the url and read it, saving everyone else's time.
>> I rarely get "why are you blocking me?" for rbl listed
>> domains, so I'm guessing that those client specific self
>> service urls do provide some benefit.
>
>
> There won't be reject-specific text anytime soon; the effort is just too
> high. Implementing custom text for just a few reject_* restrictions
> would raise false expectations, and is unlikely to be implemented
> judging from past half-solution proposals.
I would love it if the client IP could be included in the message. This
is useful because the guy at the other end doesn't necessarily knows
which IP contacted us; and the IP syntax doesn't cause problems with
URLs. (well, I am also saying this because almost all of my rejections
are based on the IP reputation).
but a static text is ok for me.
Mark Scholten
> Le 04/01/2011 22:24, Noel Jones a écrit :
> > On 1/4/2011 3:04 PM, pf at alt-ctrl-del.org wrote:
> >>
> >> I'm trying to stop the chain of:
> >> Sender calls recipient, recipient calls their tech,
> >> recipient's tech calls me... Then I tell them to contact the
> >> sender's admin... Then the sender's admin claims that
> >> "everyone" else accepts their email, even though they don't
> >> have any reverse dns, and suggests that I add an exception for
> >> their servers.
> >>
> >> I would hope that occasionally someone in that chain would
> >> notice the url and read it, saving everyone else's time.
> >> I rarely get "why are you blocking me?" for rbl listed
> >> domains, so I'm guessing that those client specific self
> >> service urls do provide some benefit.
> >
> >
> > There won't be reject-specific text anytime soon; the effort is just
> too
> > high. Implementing custom text for just a few reject_* restrictions
> > would raise false expectations, and is unlikely to be implemented
> > judging from past half-solution proposals.
>
> I would love it if the client IP could be included in the message. This
> is useful because the guy at the other end doesn't necessarily knows
> which IP contacted us; and the IP syntax doesn't cause problems with
> URLs. (well, I am also saying this because almost all of my rejections
> are based on the IP reputation).
>
> but a static text is ok for me.
>
> >
> > A "generic" self-help web link that refers them to match the first
> part
> > of the reject message with a list of possibilities should be
> > sufficient. I believe this to be a fairly common practice already.
The only missing thing is that someone has to read the not delivered messages and that is something we probably can't fix with Postfix (or other software).
Regards, Mark
Wietse Venema
Wietse
smtpd_reject_contact_information (default: empty)
Optional contact information that is appended after each SMTP server
4XX or 5XX response.
Example:
/etc/postfix/main.cf:
smtpd_reject_contact_information = For assistance, call 800-555-0101.
Please provide the following information in your problem report:
time ($localtime) and client address ($client_address).
Server response:
550-5.5.1 <user@example> Recipient address rejected: User unknown
550 5.5.1 For assistance, call 800-555-0101. Please provide the
following information in your problem report: time (Jan 4 15:42:00)
and client address (192.168.1.248).
Note: this text is meant to make it easier to find the Postfix logfile
records for a failed SMTP session. The text itself is not logged to the
Postfix server's maillog file.
Be sure to keep the text as short as possible. Long text may be trun-
cated before it is logged in the senders maillog file, or before it is
returned to the sender in a delivery status notification.
This feature supports a limited number of $name attributes in the con-
tact text. These are replaced by their current value for the SMTP ses-
sion:
client_address
Client IP address
client_port
Client TCP port
localtime
Server local time (Mmm dd hh:mm:ss)
recipient
The address in the RCPT TO command
sender The address in the MAIL FROM command
This feature supports \n as a request for a line break in the contact
text. Postfix automatically inserts after each line break the three-
digit SMTP reply code (and optional enhanced status code) from the
original Postfix reject message.
This feature is available in Postfix 2.8 and later.
mouss
> This is the current implementation of "reject" footer messages.
Wietse, thanks infinitely (and I forgot to say it before: happy new
year, best wishes and "bonne santé"!).
Mark Scholten
> us...@postfix.org] On Behalf Of Wietse Venema
> Subject: Re: Change error messages returned by Postfix
>
> This is the current implementation of "reject" footer messages.
>
Wietse: Thank you! We'll start testing with this feature within 2 weeks
probably (after we setup a new Postfix server for testing).
Regards, Mark
Bastian Blank
> localtime
> Server local time (Mmm dd hh:mm:ss)
Hmm. This is not that useful without the information about the used
timezone.
Bastian
--
But Captain -- the engines can't take this much longer!
Noel Jones
> On Thu, Jan 06, 2011 at 10:30:15AM -0500, Wietse Venema wrote:
>> localtime
>> Server local time (Mmm dd hh:mm:ss)
>
> Hmm. This is not that useful without the information about the used
> timezone.
>
> Bastian
>
The timezone doesn't matter here; this is your local server's
time. The information is provided to help find the entries in
your server log.
-- Noel Jones
Wietse Venema
> On Thu, Jan 06, 2011 at 10:30:15AM -0500, Wietse Venema wrote:
> > localtime
> > Server local time (Mmm dd hh:mm:ss)
>
> Hmm. This is not that useful without the information about the used
> timezone.
It is useful, as it is the SAME TIME as in the maillog file.
Victor Duchovni
> It is useful, as it is the SAME TIME as in the maillog file.
Indeed. It is only ambiguous once a year, when clocks move back an hour
after DST. If you need to troubleshoot mail delivery between 1AM and
2AM localtime late in Autumn, you may need to search a two-hour chunk
of mail log file.
I use syslog-ng with ISODATE timestamps, so the log entries themselves
are not ambiguous:
2011-01-07T13:51:07-05:00 ...
destination mail { file("/path/to/logs/$YEAR/$MONTH/$DAY/$HOUR"
template("$ISODATE $HOST $MSG\n") template_escape(no)
owner("root") group("log") perm(0640)
dir_owner("root") dir_group("log")
dir_perm(02750) create_dirs(yes)); };
--
Viktor.
mouss
> On Thu, Jan 06, 2011 at 10:30:15AM -0500, Wietse Venema wrote:
>> localtime
>> Server local time (Mmm dd hh:mm:ss)
>
> Hmm. This is not that useful without the information about the used
> timezone.
<humour>
more generally, time is not useful because it keeps changing :)
</humour>
Case 1) your timezone changes too often
then it's not a timezone.
Case 2) your timezone is relatively stable. then put it in main.cf:
my_time_zone = ....
smtpd_reject_contact_information =
blah blah time ($localtime).
oh, and our timezone is ${my_time_zone}
Victor Duchovni
> Case 2) your timezone is relatively stable. then put it in main.cf:
>
> my_time_zone = ....
> smtpd_reject_contact_information =
> blah blah time ($localtime).
> oh, and our timezone is ${my_time_zone}
This won't work. Generic main.cf parameters are NOT expanded into