Re: File-format for Included Files for main.cf Options

[JL (Postfix Readers A/c)]

Hi,

Thank you Viktor, that is absolutely perfect!

In particular, your explanation -- "The file content is interpolated
into the value of the parameter, as though each line were an indented
continuation of the parameter..." -- clarifies exactly what I needed
to know.

I am sure it's not in the documentation anywhere. It's not clear where
would be a good place to write it up, without repeating the
explanation in-line everywhere a file argument is mentioned.

The additional clarification about comments needing to start in the
first column was helpful, and good to know about the additional points
regarding !negation and files including files etc.

Thanks again!

James.



On Tue, 12 Jan 2021 at 01:22, Viktor Dukhovni  
wrote:
>
> On Tue, Jan 12, 2021 at 01:00:26AM +, JL (Postfix Readers A/c) wrote:
>
> > Can someone point me at the right place in the docs, or offer advice
> > which maybe could also be added to the docs (!) to help others?
>
> Each main.cf parameter documents its syntax.  Various parameters, that
> take literal lists of values in-line, also take a file name whose
> content contains similar values.  The syntax typically also supports
> "!/some/path", which is a set of exceptions.
>
> > Can such a file contain comments, for example? Or blank lines?
> > Can it have several "items" space/comma separated on one line?
> > Can it have each "item" on a line of its own? A mixture of both?
>
>     http://www.postfix.org/postconf.5.html#relay_domains
>
>     Specify a list of host or domain names, "/file/name" patterns or
>     "type:table" lookup tables, separated by commas and/or whitespace.
>     Continue long lines by starting the next line with whitespace. A
>     "/file/name" pattern is replaced by its contents; a "type:table"
>     lookup table is matched when a (parent) domain appears as lookup
>     key. Specify "!pattern" to exclude a domain from the list. The form
>     "!/file/name" is supported only in Postfix version 2.4 and later.
>
> The file content is interpolated into the value of the parameter,
> as though each line were an indented continuation of the parameter
> value:
>
>         relay_domains = /some/file
>
> is the same as:
>
>         relay_domains =
>             line1
>             line2
>             ...
>             lineN
>
> where line1, line2, ... lineN are the lines of the file.  Comments must
> start in the first column of the file.  Blank lines are ignored, just
> as they are in the in-line form.  Files can even list more files, and
> each '!' reverses the meaning of any previous '!'.
>
> These are called "match lists" internally, and it would perhaps be good
> to have a general description of match lists somewhere...
>
> --
>     Viktor.

File-format for Included Files for main.cf Options

[JL (Postfix Readers A/c)]

Hi,

I can't find it in the docs or from a search of this mailing-list...

When a main.cf entry specifies a filename, I know the contents are
inserted in place. But the exact format of said file is unclear.

I don't think it is literally "included" in-line, because a file that
contains a list of domains, one on each line, with no indentation,
seems to work fine for relay_domains, and suchlike.

Can someone point me at the right place in the docs, or offer advice
which maybe could also be added to the docs (!) to help others?

Can such a file contain comments, for example? Or blank lines?
Can it have several "items" space/comma separated on one line?
Can it have each "item" on a line of its own? A mixture of both?

I have tried doing some experiments and I think I have what I need
working as required, but guesswork is not great in a production
environment :)

Thanks,
James.

Re: MySQL stored-procedure support for Postfix 3.2

[jl]

On 2016-12-27 09:45, John Fawcett wrote:

On 12/26/2016 10:35 PM, Wietse Venema wrote:

John Fawcett:

so long as the loop continues in the presence of a zero return
code from mysql_next_result() and mysql_store_result is called for
each one we will stay in sync. With the break above we will be ok,
since the loop stops only when there are no more results -1 normal
condition from mysql_next_result or >0 error condition from
mysql_next_result via the break.

I further reduced the number of state variables, moved the "no
result" check out of the loop, included the database name in warning
messages, and added support for "require_result_set = no" to avoid
the need for dummy SELECT statements in stored procedures.

Please check out postfix-3.2-20161226-nonprod. As you will see,
code diffs not useful at this point.

Wietse


Thanks. I ran it through my tests and it produces expected results for
queries and stored procedures. I'll run it for a while (using queries)
and report back any issues.

John


I wan't to thank you guys for integrating stored procedure support into 
postfix. The amount of thought put into this relatively minor task was 
impressive to me, but I suppose that is the reason why postfix is 
considered such a safe and stable system. I guess this mentality is what 
enabled postfix to compete and grow alongside other MTAs over the last 
two decades.


I use the latest evolution of the mysql code in my production system, 
including the "require_result_set=no" flag and it performs flawlessly. 
My primarily email volume consists of my private mail but I forward 
emails for an association, hence the complex setup


Thanks again,

Joel

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[jl]

On 2016-11-23 21:57, John Fawcett wrote:

On 11/22/2016 01:35 AM, Joel Linn wrote:

Hey Guys,

this issue has decayed a bit but I now finally found the time (and the
nerves) to integrate the fix in my system.
I'm running Ubuntu 16.04 and trying not change to many things and be
able to have clean comparison I applied the patch to the apt sources
and only replaced the postfix-mysql package (ubuntu is using 3.1.0 it
seems) with my own.
I introduced some stored procedures and from my tests I conclude it
works. I will see in the next couple of days if there are issues I
overlooked.
I ran into an issue where I was returning no result set using
"smtpd_recipient_restrictions = check_recipient_access mysql:/[...]".
I'm not sure if that's an dict_mysql issue or caused by design
upstream. I overcame that by doing "select 1 from dual where false"
when I don't have anything else to return, which basically is an empty
result set.

Thanks very much for your work,
Joel

Joel

can you provide some more information to reproduce the issue you 
mentioned?


John

Sure I can. Have a look at my log:

Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: connect from 
divmail1.helmholtz-berlin.de[134.30.104.21]
Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: warning: 
mysql:/etc/postfix/sql/recipient-access.cf: table lookup problem
Nov 23 22:42:49 leuchtkanone postfix/smtpd[5863]: NOQUEUE: reject: RCPT 
from divmail1.helmholtz-berlin.de[134.30.104.21]: 451 4.3.5 
: Recipient address rejected: Server configuration 
error; from= to= 
proto=ESMTP helo=


I used this empty test procedure (query = CALL ret_empty;):

CREATE DEFINER=`vmail`@`localhost` PROCEDURE `ret_empty`()
BEGIN
END

In my procedure I had some code paths return a result and some not. Like 
I said i'm now using "SELECT 1 FROM dual WHERE false;" for those dead 
paths, this simulates the behavior of the previous solution (one line 
query) which always returns a result set, even if it's empty.

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[jl]

Quoting John Fawcett :

I can propose a code submission to add stored procedure support (based
on the proof of concept code from 2008), but the biggest part will be
doing the testing and non regression testing not the actual coding.

I believe the best approach to adding stored procedure support is to
iterate over multiple result sets and if there are exactly two and the
last one is the status result of the stored procedure and it is
successful then allow the lookup against the first result set. In all
other cases there should be an error for multiple result sets. In the
context of Postfix don't think it is useful to have more than one result
set generated by multiple queries or more than two result sets
(including the status one) from a stored procedure.

John


That is exactly what I had on my mind.

The specific error message would enable admins to exactly see where  
the trouble originates.
Also consuming all results still allows subsequent lookups to succeed  
normally.


I would of course volunteer to "test" the change per se but I'm afraid  
my knowledge of postfix's inner workings converges to zero, rendering  
my testing unrepresentative at last :/

Although the subset of postfix interfacing with mysql is quite small.

Joel

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[jl]

Quoting wie...@porcupine.org:


j...@conductive.de:


Quoting wie...@porcupine.org:

> Wietse Venema:
>> Joel Linn:
>> > Why is it chosen to "not support stored procedures" instead of  
adding two

>> > lines of code?
>>
>> The original mysql client may well have been written at a time that
>> stored procedures did not exist, or no API documentation existed
>> for how to do this correctly.
>>
>> If you feel strongly about stored procedures, then you are welcome
>> to contribute code. If you can demonstrate that the code uses the
>> MySQL API correctly (instead of "there are no error messages") then
>> that would help getting the code accepted.
>
> This is a pointer to MySQL documentation for multi-statement support,
> which seems to be needed to implement stored-procedure support in the
> Postfix MySQL client.
>
> http://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html
>
>Wietse

Thanks for the link.
An interesting fact is that the doc says CLIENT_MULTI_RESULTS is
default since MySQL 5.7.
And comparing my error message "Commands out of sync" to the one
in the discussion of 2008 John Fawcett dug out "can't return a
result set in the given context", we are in fact not using the api
as designed at the moment.  Sure its "just" an error message for
both cases but the api thinks we can handle multiple results but
in fact we can not.  Talking about multi statement support is
planning one step ahead already, but a smart thought whatsoever,
eliminating the need for stored procedures to some extend.

I think we could at least support multi results by enumerating
over all but the first result (return that) and maybe throw them
away, at least issue a warning if they are additional result sets
(not for statuses of course, they are OK if they indicate success).
This way we can indicate to the administrator a poorly designed
query that leaks data.  Maybe even issue an error for security
reasons if the results contain more than one result set.  Because
that could lead to undefined behavior if some SELECT prior to the
correct SELECT accidentally gives wrong data (e.g. sending mail
to mars).

Multiple statements is another discussion, however subordinate and
dependent on the implementation of multi results.  As far is I can
see no prepared statements are used in the code so allowing for
multiple statements is easy and shouldn't tension the security
discussion (?), however sql injection is easier to do if you can
end a statement with ";".  But I presume the % placeholders are
filtered anyway (either explicit or implicit) so that shouldn't
be a concern.

Do you agree or do you see any drawbacks or problems?


Unfortunately, I am not familiar with MySQL APIs, and I don't have
cycles to spare.

My first priority is to ensure that existing Postfix code keeps
working as promised (i.e. Postfix does not break due to MySQL API
library changes).

If the MySQL library will send multiple results even if Postfix
does not specify CLIENT_MULTI_RESULTS, it is sufficient to report
an error when the library returns more replies than expected?

I'm not opposed to stored-procedure support, but I think it should
be implemented+documented by someone who understands the APIs, so
that would not be me.

Wietse


At the moment no flags (0) are passed to mysql_real_connect.
But if using the mysql api version 5.7 or newer the api "forces"  
CLIENT_MULTI_RESULTS.

I see no way in the api doc to disable it, e.g. using mysql_set_server_option.
So the code should no matter what cycle over the results anyway,
because if not cleared they cause later queries to fail and
we have no way to prohibit multiple results using the api afaIk.

So yes, looping results and generating an error for more than one
result is sufficient to prevent hiccups in following queries.

That bugfix however would be very close to my suggested change.
Is there someone maintaining the mysql portion of postfix,
I mean except you keeping everything running?

Joel

Re: AW: Possible Bug ? postfix 3.1.0-3 fails on mysql table lookup

[jl]

Quoting wie...@porcupine.org:


Wietse Venema:

Joel Linn:
> Why is it chosen to "not support stored procedures" instead of adding two
> lines of code?

The original mysql client may well have been written at a time that
stored procedures did not exist, or no API documentation existed
for how to do this correctly.

If you feel strongly about stored procedures, then you are welcome
to contribute code. If you can demonstrate that the code uses the
MySQL API correctly (instead of "there are no error messages") then
that would help getting the code accepted.


This is a pointer to MySQL documentation for multi-statement support,
which seems to be needed to implement stored-procedure support in the
Postfix MySQL client.

http://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html

Wietse


Thanks for the link.
An interesting fact is that the doc says CLIENT_MULTI_RESULTS is  
default since MySQL 5.7.
And comparing my error message "Commands out of sync" to the one in  
the discussion of 2008 John Fawcett dug out
"can't return a result set in the given context", we are in fact not  
using the api as designed at the moment.
Sure its "just" an error message for both cases but the api thinks we  
can handle multiple results but in fact we can not.
Talking about multi statement support is planning one step ahead  
already, but a smart thought whatsoever, eliminating the need for  
stored procedures to some extend.


I think we could at least support multi results by enumerating over  
all but the first result (return that) and maybe throw them away,
at least issue a warning if they are additional result sets (not for  
statuses of course, they are OK if they indicate success).
This way we can indicate to the administrator a poorly designed query  
that leaks data.
Maybe even issue an error for security reasons if the results contain  
more than one result set.
Because that could lead to undefined behavior if some SELECT prior to  
the correct SELECT accidentally gives wrong data (e.g. sending mail to  
mars).


Multiple statements is another discussion, however subordinate and  
dependent on the implementation of multi results.
As far is I can see no prepared statements are used in the code so  
allowing for multiple statements is easy and shouldn't tension the  
security discussion (?),

however sql injection is easier to do if you can end a statement with ";".
But I presume the % placeholders are filtered anyway (either explicit  
or implicit) so that shouldn't be a concern.


Do you agree or do you see any drawbacks or problems?

Joel

Re: smtp_tls_security_level = may combined wit smtp_tls_policy_maps

[JL Hill]

I have a very similar issue, although my goal is not to negotiate TLS with
specific domains. I have:

main.cf

smtp_tls_security_level = may
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/tls_policy

example.com  none
.example.com  none

From the documentation I read, I thought postfix would not try negotiating
TLS with the example.com mail server, but it does.

(I posted this question Mar. 5, but received no response).

Best regards,

J.L. Hill


Am 15.03.2013 13:11, schrieb Wietse Venema:
 Robert Schetterer:
 Hi,

 if i use

 smtp_tls_security_level = may

 is

 smtp_tls_policy_maps honored ?

 As a general rule, per-destination SMTP/TLS policy lookup results
 override main.cf (and master.cf) settings.

 You enable smtp_tls_policy_maps lookups by specifying a non-empty
 value (there appears to be no other way to turn this off).

 Wietse


Hi Wietse, i set

smtp_tls_security_level = may

and

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

with

/etc/postfix/tls_policy

example.com encrypt

so it should goal

encrypt ,if possible ,with fallback to plain, for all destination

but for example.com encrypt only ( no plain fallback )



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstra

Re: smtp_tls_security_level = may combined wit smtp_tls_policy_maps

[JL Hill]

Thank you for your response. I assume I have something wrong, or I
misunderstood the documentation.

I have tested sending mail to example.com. A dig example.com MX gives:

example.com. 2546 IN MX 10 smtp1.example.com.
example.com. 2546 IN MX 20 smtp2.example.com.
example.com. 2546 IN MX 30 smtp3.example.com.

I had assumed that having

   .example.com none

in my tls_policy would keep postfix from negotiating TLS with these servers.

I will try with smtp_discard_ehlo_keyword_address_maps.

Thank you again,

JL Hill

p.s. in case it is of value, my tls config:

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtpd_tls_auth_only = no
smtpd_tls_security_level = may
smtp_tls_security_level = may
tls_random_source = dev:/dev/urandom
smtpd_tls_received_header = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/ssl/host.mydom.com.key
smtpd_tls_cert_file = /etc/postfix/ssl/host.mydom.com.crt
smtpd_tls_CAfile = /etc/postfix/ssl/gd_bundle.crt
smtp_tls_CAfile = /etc/postfix/ssl/gd_bundle.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_loglevel = 2
smtpd_tls_loglevel = 2

On Fri, Mar 15, 2013 at 11:28 AM, Viktor Dukhovni 
postfix-us...@dukhovni.org wrote:

 On Fri, Mar 15, 2013 at 10:09:17AM -0400, JL Hill wrote:

  /etc/postfix/tls_policy
 
  example.com  none
  .example.com  none
 
  From the documentation I read, I thought postfix would not try
 negotiating
  TLS with the example.com mail server, but it does.
 
  (I posted this question Mar. 5, but received no response).
 
  Best regards,

 The policy table applies policy to destination domains, not MX
 hosts.  So what do you mean when you say with the example.com
 mailserver?  If it has a stable IP address, you can use

 smtp_discard_ehlo_keyword_address_maps

 suppress a given host's STARTTLS announcement.

 --
 Viktor.

Re: smtp_tls_security_level = may combined wit smtp_tls_policy_maps

[JL Hill]

I feel more confused. I had originally tested

example.com   none

and it failed. I searched the documentation, and found .example.com to use
for subdomains, so I thought that would fit my case as the negotiation is
with smtp2.example.com, even though I am emailing john@example.com

When I tested without the dot, sending to john@example.com my log shows
Host offered STARTTLS: [smtp2.example.com]

I will test carefully again using just example.com none -- I guess I
could have made a typo or other error; I thought not.

Thank you again,

JL Hill

On Fri, Mar 15, 2013 at 4:42 PM, Viktor Dukhovni postfix-us...@dukhovni.org
 wrote:

 On Fri, Mar 15, 2013 at 04:09:47PM -0400, JL Hill wrote:

  Thank you for your response. I assume I have something wrong, or I
  misunderstood the documentation.
 
  I have tested sending mail to example.com. A dig example.com MX gives:
 
  example.com. 2546 IN MX 10 smtp1.example.com.
  example.com. 2546 IN MX 20 smtp2.example.com.
  example.com. 2546 IN MX 30 smtp3.example.com.
 
  I had assumed that having
 
 .example.com none
 
  in my tls_policy would keep postfix from negotiating TLS with these
 servers.

 No, when sending mail example.com you set TLS policy for example.com

 example.com none.

 TLS policy is by destination (domain), not by MX host. The setting you
 have disables TLS for email addressed to mumble.example.com, assuming
 there is a valid mumble.example.com email domain.

 --
 Viktor.

Re: smtp_tls_security_level = may combined wit smtp_tls_policy_maps

[JL Hill]

My apologies, I grabbed the wrong snippet of log file (same host, different
server). Here is the entire connection log (I changed only the domain name
and xxx'd the ip address):

Mar  3 06:36:10 host postfix/smtp[4]: initializing the client-side TLS
engine
Mar  3 06:36:11 host postfix/smtp[4]: setting up TLS connection to
smtp1.example.com[70.186.xxx.xxx]:25
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
TLS cipher list aNULL:-aNULL:ALL:+RC4:@STRENGTH
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:before/connect
initialization
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:unknown state
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 read server
hello A
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
certificate verification depth=2 verify=0 subject=/C=US/O=The Go Daddy
Group, Inc./OU=Go Daddy Class 2 Certification Authority
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
certificate verification depth=2 verify=0 subject=/C=US/O=The Go Daddy
Group, Inc./OU=Go Daddy Class 2 Certification Authority
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
certificate verification depth=1 verify=1
subject=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=
http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification
Authority/serialNumber=07969287
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
certificate verification depth=0 verify=1 subject=/O=
smtp1.example.com/OU=Domain Control Validated/CN=smtp1.example.com
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 read server
certificate A
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 read server
done A
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 write client
key exchange A
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 write change
cipher spec A
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 write finished A
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 flush data
Mar  3 06:36:11 host postfix/smtp[4]: SSL_connect:SSLv3 read finished A
Mar  3 06:36:11 host postfix/smtp[4]: smtp1.example.com[70.186.xxx.xxx]:25:
subject_CN=smtp1.example.com, issuer_CN=Go Daddy Secure Certification
Authority, fingerprint 93:28:E6:D5:F1:6F:FD:34:09:8B:BF:52:35:BB:94:6C,
pkey_fingerprint=E4:A4:55:48:AF:85:C5:A0:51:25:94:B8:57:54:D5:50
Mar  3 06:36:11 host postfix/smtp[4]: Untrusted TLS connection
established to smtp1.example.com[70.186.xxx.xxx]:25: TLSv1 with cipher
DES-CBC3-SHA (168/168 bits)
Mar  3 06:36:11 host postfix/smtp[4]: SSL3 alert write:fatal:protocol
version
Mar  3 06:36:11 host postfix/smtp[4]: warning: TLS library problem:
4:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:340:
Mar  3 06:36:11 host postfix/smtp[4]: ACFBAD746C: to=br...@example.com,
relay=smtp1.example.com[70.186.xxx.xxx]:25, delay=222575,
delays=222574/0.01/1/0, dsn=4.4.2, status=deferred (lost connection with
smtp1.example.com[70.186.xxx.xxx] while sending MAIL FROM)

As I said, I was trying to understand what was supposed to work in turning
off TLS for a specific domain. I understand that I should be able to do it
by specifying example.com none in tls_policy. I will test using
 smtp_tls_policy_maps, as well as testing using
smtpd_discard_ehlo_keyword_address_maps

Thank you again, and again my apologies for grabbing the wrong snippet of
log file.

JL Hill

On Fri, Mar 15, 2013 at 6:33 PM, Viktor Dukhovni postfix-us...@dukhovni.org
 wrote:

 On Fri, Mar 15, 2013 at 05:19:30PM -0400, JL Hill wrote:

  I feel more confused. I had originally tested
 
  example.com   none
 
  and it failed. I searched the documentation, and found .example.com to
 use
  for subdomains, so I thought that would fit my case as the negotiation is
  with smtp2.example.com, even though I am emailing john@example.com
 
  When I tested without the dot, sending to john@example.com my log
 shows
  Host offered STARTTLS: [smtp2.example.com]

 This means that TLS was NOT used. This is a helpful log message that
 tells you could use TLS, but you're not.  Your configuration turns
 on this non-default helpful log message.

 # default:
 smtp_tls_note_starttls_offer = no

 --
 Viktor.

Cannot make smtpd_sender_restrictions = check_sender_access work properly‏

[JL Picard]

I am trying to setup some simple username-based restrictions on what
local users can send on a local Solaris 10 server. In this case, I want
to allow emails by all other users, but reject any attempt for user
local_usr to send any email from this server. But so far, I can't
make the below configurations/commands work. This postfix server relays
to another close-by relayserver which forwards the msg to an external
server. If possible, I would prefer to reject on the local email server
before it hits the relay. If at all possible, I would also like an
error condition/status in the smtp client, but thats not a huge problem.

I
have provided as much diagnostic config and log data that I can
imagine, but I am more than happy to provide more, can anyone see what I
am missing?

Thanks-in-advance



###Here are some of the relevant main.cf settings that I think would apply:
root@myTestServer(/etc/opt/csw/postfix)% postconf | egrep 
mynetworks|smtpd_sender_restrictions|relayhost =
address_verify_relayhost = $relayhost
debug_peer_list = 127.0.0.1,myTestServer
mynetworks = 172.20.158.0/26, 172.20.204.0/24, 172.19.5.0/25, 172.19.21.0/24, 
127.0.0.0/8
mynetworks_style = subnet
parent_domain_matches_subdomains
=
debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps
postscreen_access_list = permit_mynetworks
proxy_read_maps
= $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps
$sender_canonical_maps $recipient_canonical_maps $relocated_maps
$transport_maps $mynetworks $sender_bcc_maps $recipient_bcc_maps
$smtp_generic_maps $lmtp_generic_maps
relayhost = [mail.myDomain.com]
smtpd_client_event_limit_exceptions = 
${smtpd_client_connection_limit_exceptions:$mynetworks}
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
smtpd_sender_restrictions = check_sender_access 
hash:/etc/opt/csw/postfix/sender_access
root@myTestServer(/etc/opt/csw/postfix)%


##Here is what my sender_access file has in it
root@myTestServer(/etc/opt/csw/postfix)% more /etc/opt/csw/postfix/sender_access
local_usr@ REJECT
local_...@mydomain.com REJECT


#Here is the command I ran to get the HASHED sender_access file created:
postmap hash:sender_access

#Timestamps of files proves the postmap command did something:
-rw-r--r-- 1 root root 43 May 24 11:12 sender_access
-rw-r--r-- 1 root root 49152 May 24 11:12 sender_access.db


#Here is the local IP address of my server:
172.19.5.25


#Here are some modifications (in diff format) to master.cf to get more logging:
11c11
 smtp inet n - n - - smtpd
---
 smtp inet n - n - - smtpd -v
40c40
 smtp unix - - n - - smtp
---
 smtp unix - - n - - smtp -v

#Here is the local SMTP Client command I ran to generate an email as the 
local_usr user:
local_usr@myTestServer(~)% echo test | mutt -s reject test 17 -- 
externalu...@example.com



#SYSLOG file:
May 24 11:41:51 myTestServer postfix/postfix-script[10277]: [ID 197553 
mail.info] starting the Postfix mail system
May
24 11:41:51 myTestServer postfix/master[10278]: [ID 197553 mail.info]
daemon started -- version 2.8.6, configuration /etc/opt/csw/postfix
May 24 11:41:59 myTestServer postfix/pickup[10279]: [ID 197553 mail.info] 
C41391CD00: uid=34001 from=
May
24 11:41:59 myTestServer postfix/cleanup[10410]: [ID 197553 mail.info]
C41391CD00:
message-id=20120524154159.ga10...@mytestserver.mydomain.com
May
24 11:41:59 myTestServer postfix/qmgr[10280]: [ID 197553 mail.info]
C41391CD00: from=, size=490, nrcpt=1
(queue active)
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
name_mask: ipv4
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
inet_addr_local: configured 2 IPv4 addresses
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] process 
generation: 5 (5)
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
match_string: debug_peer_list ~? debug_peer_list
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
match_string: fast_flush_domains ~? debug_peer_list
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
match_string: fast_flush_domains ~? fast_flush_domains
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
name_mask: canonical
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
name_mask: virtual
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
name_mask: dns
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] 
name_mask: native
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info] host 
name lookup methods: dns native
May
24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553 mail.info]
auto_clnt_create: transport=local endpoint=private/scache
May 24 11:41:59 myTestServer postfix/smtp[10413]: [ID 197553