question about smtpd_reject_contact_information

2011-01-07 Thread Noel Jones

Unexpected behavior when testing smtpd_reject_contact_information.

When sending to an unknown recipient, the $recipient macro 
isn't expanded.  Is this expected behavior?  I haven't tested 
with other reject reasons.



postconf snippit:

mail_version = 2.8-20110105
smtpd_reject_contact_information =
  Data: servertime=($localtime)
  client=($client_address|$client_port)
  from=($sender) to=($recipient)



Telnet snippet (slightly redacted).  This client is listed in 
postscreen_whitelist_networks and mynetworks if that matters, 
although I got similar results when testing from gmail.


mail from:u...@example.org
250 2.1.0 Ok
rcpt to:unkn...@example.org
550-5.1.1 unkn...@example.org: Recipient address rejected: 
User unknown in local recipient table
550 5.1.1 Data: servertime=(Jan 07 16:04:25) 
client=(10.1.0.157|4174) from=(u...@example.org) to=()





  -- Noel Jones


Re: question about smtpd_reject_contact_information

2011-01-07 Thread Wietse Venema
Noel Jones:
 Unexpected behavior when testing smtpd_reject_contact_information.
 
 When sending to an unknown recipient, the $recipient macro 
 isn't expanded.  Is this expected behavior?  I haven't tested 
 with other reject reasons.

You know what? I wil have to remove sender/recipient from the manual
page (i.e. it is NOT SUPPORTED) and postpone that for a later
Postfix version. It may not seem obvious, but the code that prints
the error to the client actually runs long after all the checking
is done.  In fact, if you have multiple recipients, and some later
recipient rejected, it would probably expand $recipient to the
first accepted recipient.

Adding back the currently rejected sender/recipient just for printing
the error message is going to require more changes than I am willing
to make right before the stable release.

Wietse


Re: question about smtpd_reject_contact_information

2011-01-07 Thread Victor Duchovni
On Fri, Jan 07, 2011 at 04:22:52PM -0600, Noel Jones wrote:

 Unexpected behavior when testing smtpd_reject_contact_information.

 When sending to an unknown recipient, the $recipient macro isn't expanded.  
 Is this expected behavior?  I haven't tested with other reject reasons.

Yes, the sender macros is not always available. You should use conditional
macros:

${sender? ... ${sender} ...} to 

to interpolate information that may not always be present.

I don't think that state-recipient is ever set to what you want when
a reply to a failed RCPT TO is being sent.

-- 
Viktor.


Re: question about smtpd_reject_contact_information

2011-01-07 Thread Noel Jones

On 1/7/2011 4:33 PM, Wietse Venema wrote:

Noel Jones:

Unexpected behavior when testing smtpd_reject_contact_information.

When sending to an unknown recipient, the $recipient macro
isn't expanded.  Is this expected behavior?  I haven't tested
with other reject reasons.


You know what? I wil have to remove sender/recipient from the manual
page (i.e. it is NOT SUPPORTED) and postpone that for a later
Postfix version. It may not seem obvious, but the code that prints
the error to the client actually runs long after all the checking
is done.  In fact, if you have multiple recipients, and some later
recipient rejected, it would probably expand $recipient to the
first accepted recipient.

Adding back the currently rejected sender/recipient just for printing
the error message is going to require more changes than I am willing
to make right before the stable release.

Wietse



That's fine.  Repeating the sender/recipient adds a little 
value to the contact info, but is not critical.


Thanks.


  -- Noel Jones


Re: question about smtpd_reject_contact_information

2011-01-07 Thread Wietse Venema
Wietse Venema:
 Noel Jones:
  Unexpected behavior when testing smtpd_reject_contact_information.
  
  When sending to an unknown recipient, the $recipient macro 
  isn't expanded.  Is this expected behavior?  I haven't tested 
  with other reject reasons.
 
 You know what? I wil have to remove sender/recipient from the manual
 page (i.e. it is NOT SUPPORTED) and postpone that for a later
 Postfix version. It may not seem obvious, but the code that prints
 the error to the client actually runs long after all the checking
 is done.  In fact, if you have multiple recipients, and some later
 recipient rejected, it would probably expand $recipient to the
 first accepted recipient.

Updated manpage follows

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), client ($client_address) and server
($server_name).

   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),
   client (192.168.1.248) and server (mail1.example.com).

   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 SMTP 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 Postfix SMTP server's 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
  The Client IP address that is logged in the maillog file.

   client_port
  The client TCP port that is logged in the maillog file.

   localtime
  The server local time (Mmm dd hh:mm:ss) that is  logged  in  the
  maillog file.

   server_name
  The server's myhostname value.  This attribute is made available
  for sites with multiple MTAs (perhaps behind  a  load-balancer),
  where  the  server  name  can  help  the  server support team to
  quickly find the right log files.

   Notes:

   o  NOT SUPPORTED are other attributes such as sender, recipient, or
  main.cf parameters.

   o  For  safety  reasons,  text  that  does  not match $smtpd_expan-
  sion_filter is censored.

   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: question about smtpd_reject_contact_information

2011-01-07 Thread Noel Jones

On 1/7/2011 4:36 PM, Victor Duchovni wrote:

On Fri, Jan 07, 2011 at 04:22:52PM -0600, Noel Jones wrote:


Unexpected behavior when testing smtpd_reject_contact_information.

When sending to an unknown recipient, the $recipient macro isn't expanded.
Is this expected behavior?  I haven't tested with other reject reasons.


Yes, the sender macros is not always available. You should use conditional
macros:

${sender? ... ${sender} ...} to

to interpolate information that may not always be present.



I see. Something like
  = Data: servertime=($localtime)
   client=($client_address|$client_port)
   ${sender?from=($sender)}

Am I correct assuming the time and client should always be 
available?



I don't think that state-recipient is ever set to what you want when
a reply to a failed RCPT TO is being sent.



Well, looks as if the sender/recipient macros are unsupported 
for now regardless of our clever expansion.



  -- Noel Jones


Re: question about smtpd_reject_contact_information

2011-01-07 Thread Victor Duchovni
On Fri, Jan 07, 2011 at 05:01:22PM -0600, Noel Jones wrote:

 I see. Something like
   = Data: servertime=($localtime)
client=($client_address|$client_port)
${sender?from=($sender)}

 Am I correct assuming the time and client should always be available?

Yes.

 I don't think that state-recipient is ever set to what you want when
 a reply to a failed RCPT TO is being sent.

 Well, looks as if the sender/recipient macros are unsupported for now 
 regardless of our clever expansion.

Yes.

-- 
Viktor.