RE: Change error messages returned by Postfix

2011-01-07 Thread Mark Scholten
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 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
 
 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 u...@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.

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



Re: Change error messages returned by Postfix

2011-01-07 Thread Bastian Blank
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

-- 
But Captain -- the engines can't take this much longer!


Re: Change error messages returned by Postfix

2011-01-07 Thread Noel Jones

On 1/7/2011 5:21 AM, Bastian Blank wrote:

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


Re: Change error messages returned by Postfix

2011-01-07 Thread Wietse Venema
Bastian Blank:
 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.


Re: Change error messages returned by Postfix

2011-01-07 Thread Victor Duchovni
On Fri, Jan 07, 2011 at 07:52:39AM -0500, Wietse Venema wrote:

 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.


Re: Change error messages returned by Postfix

2011-01-07 Thread mouss
Le 07/01/2011 12:21, Bastian Blank a écrit :
 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}


Re: Change error messages returned by Postfix

2011-01-07 Thread Victor Duchovni
On Fri, Jan 07, 2011 at 06:54:28PM +0100, mouss wrote:

 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
the contact footer.

-- 
Viktor.


RE: Change error messages returned by Postfix

2011-01-06 Thread 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).
 
Here also most rejections are based on the IP reputation (or rDNS). When we 
know the IP we can automatically check for the rDNS information (and if needed 
check the log file). That is also why I really would like to have the IP in it.

 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



Re: Change error messages returned by Postfix

2011-01-06 Thread Wietse Venema
This is the current implementation of reject footer messages.

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 u...@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.


Re: Change error messages returned by Postfix

2011-01-06 Thread mouss
Le 06/01/2011 16:30, Wietse Venema a écrit :
 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é!).

 
   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 u...@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.



Re: Change error messages returned by Postfix

2011-01-05 Thread mouss
Le 04/01/2011 21:23, Jeroen Geilman a écrit :
 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.
 

 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 ?

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.


 Note that information in SMTP logs and sessions is generally only read
 by, and therefore only useful to, system admins.





Re: Change error messages returned by Postfix

2011-01-05 Thread mouss
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.
 
 
 
   -- Noel Jones



Re: Change error messages returned by Postfix

2011-01-04 Thread J. Roeleveld
On Monday 03 January 2011 17:35:51 Wietse Venema wrote:
 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


RE: Change error messages returned by Postfix

2011-01-04 Thread Mark Scholten


 -Original Message-
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Victor Duchovni
 Sent: Monday, January 03, 2011 8:00 PM
 To: postfix-users@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



Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
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 u...@examplegt: Recipient address rejected: User unknown
   550 5.5.1 For assistance, call 800-555-0101

   This feature is available in Postfix 2.8.


Re: Change error messages returned by Postfix

2011-01-04 Thread John Adams

Am 04.01.2011 12:59, schrieb Wietse Venema:

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.1u...@examplegt: 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?


Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
John Adams:
  Example:
 
  /etc/postfix/main.cf:
  smtpd_reject_contact_information = For assistance, call 
  800-555-0101
 
  Server response:
 
  550-5.5.1u...@examplegt: 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


Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 01:24:51PM +0100, John Adams wrote:

 550-5.5.1u...@examplegt: 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.


Re: Change error messages returned by Postfix

2011-01-04 Thread John Adams

Am 04.01.2011 14:59, schrieb Victor Duchovni:

On Tue, Jan 04, 2011 at 01:24:51PM +0100, John Adams wrote:


 550-5.5.1u...@examplegt: 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?





Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 03:09:01PM +0100, John Adams wrote:

 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.


RE: Change error messages returned by Postfix

2011-01-04 Thread Mark Scholten
Wietse Venema: 
 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 u...@examplegt: 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? 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



Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 03:36:41PM +0100, Mark Scholten wrote:

 Server response:
  
 550-5.5.1 u...@examplegt: 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.


Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
Victor Duchovni:
 On Tue, Jan 04, 2011 at 03:36:41PM +0100, Mark Scholten wrote:
 
  Server response:
   
  550-5.5.1 u...@examplegt: 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?

[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.

Wietse


Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 11:33:25AM -0500, Wietse Venema wrote:

   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.


Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
Victor Duchovni:
  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 u...@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


Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
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 u...@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.


Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
Victor Duchovni:
 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 u...@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


Re: Change error messages returned by Postfix

2011-01-04 Thread pf at alt-ctrl-del.org


Wietse Venema

 Example:

 /etc/postfix/main.cf:
 smtpd_reject_contact_information = For assistance, call 
800-555-0101

 Server response:

 550-5.5.1u...@examplegt: 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. 





Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 02:09:07PM -0500, Wietse Venema wrote:

  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.


Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 02:32:45PM -0500, pf at alt-ctrl-del.org wrote:

 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.


Re: Change error messages returned by Postfix

2011-01-04 Thread 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.



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.



Re: Change error messages returned by Postfix

2011-01-04 Thread 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. 





Re: Change error messages returned by Postfix

2011-01-04 Thread Wietse Venema
Wietse Venema:
   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 u...@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 u...@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=u...@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 u...@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:

u...@example: host mail.example[192.168.1.58] said:  554-5.5.1
u...@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; u...@example
Original-Recipient: rfc822; u...@example
Action: failed
Status: 5.1.1
Remote-MTA: dns; mail.example
Diagnostic-Code: smtp; 554-5.5.1 u...@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 u...@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=u...@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 u...@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:

u...@example: host mail.example[192.168.1.58] said:  554-5.5.1
u...@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; u...@example
Original-Recipient: rfc822; u...@example
Action: failed
Status: 5.1.1
Remote-MTA: dns; mail.example
Diagnostic-Code: smtp; 554-5.5.1 u...@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


Re: Change error messages returned by Postfix

2011-01-04 Thread Noel Jones

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.


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


Re: Change error messages returned by Postfix

2011-01-04 Thread Jeroen Geilman

On 1/4/11 10: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.



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.



Re: Change error messages returned by Postfix

2011-01-04 Thread Victor Duchovni
On Tue, Jan 04, 2011 at 04:09:04PM -0500, Wietse Venema wrote:

 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 u...@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=u...@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 u...@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.

 
 u...@example: host mail.example[192.168.1.58] said:  554-5.5.1
 u...@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.


Re: Change error messages returned by Postfix

2011-01-03 Thread /dev/rob0
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, 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:

unknown450 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


Re: Change error messages returned by Postfix

2011-01-03 Thread Wietse Venema
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
 
 



Re: Change error messages returned by Postfix

2011-01-03 Thread Ralf Hildebrandt
* 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.

-- 
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.hildebra...@charite.de | http://www.charite.de



Re: Change error messages returned by Postfix

2011-01-03 Thread Ralf Hildebrandt
* John Adams mailingli...@belfin.ch:

 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
  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.hildebra...@charite.de | http://www.charite.de



Re: Change error messages returned by Postfix

2011-01-03 Thread 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.

-- 
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.hildebra...@charite.de | http://www.charite.de



Re: Change error messages returned by Postfix

2011-01-03 Thread John Adams

Am 03.01.2011 20:00, schrieb Victor Duchovni:

On Mon, Jan 03, 2011 at 07:44:51PM +0100, Ralf Hildebrandt wrote:


* Wietse Venemawie...@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.


Re: Change error messages returned by Postfix

2011-01-03 Thread mouss
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:
 
 unknown450 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.



Re: Change error messages returned by Postfix

2011-01-03 Thread mouss
Le 03/01/2011 17:35, Wietse Venema a écrit :
 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.
 

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.




Re: Change error messages returned by Postfix

2011-01-02 Thread Wietse Venema
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


Re: Change error messages returned by Postfix

2011-01-02 Thread Jerrale G

On 1/2/2011 10:12 PM, 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

Yeah, so the answer he was looking for is look in the source.

:)




Jerrale G.
SC Senior Admin


Re: Change error messages returned by Postfix

2011-01-02 Thread Jerrale G

On 1/2/2011 10:36 PM, Jerrale G wrote:

On 1/2/2011 10:12 PM, 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

Yeah, so the answer he was looking for is look in the source.

:)




Jerrale G.
SC Senior Admin
On another note, I found the most common ones are in: 
./src/smtpd/smtpd_check.c




Jerrale G.
SC Senior Admin


Re: Change error messages returned by Postfix

2011-01-02 Thread 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?
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