Viktor Wrote:
On Thu, Jan 15, 2009 at 10:01:51PM +0100, mouss wrote:
> jeff_homeip a ?crit :
> > [snip]
> > When I added this back, all worked fine. If I remove this one
restriction
> > (check_sender_access), I can no longer send.
> >
> > is this check_sender_access, because it's not rejecting the
sender, allowing it somehow?
> >
>
> no. it's more probable that you have errors in your config.
>
I this it's absolutely certain that I had errors in my config. As you
noticed, I have been having a challenge trying to isolate and fix them.
> if you think you have a problem with one particular configuration,
then
> we need to see that configuration, so
>
> 1) configure postfix to reproduce the problem
> 2) restart postfix
> 3) from now, don't change any setting until the end of this
procedure
> 4) reproduce the problem (test...)
> 5) if you succeed, send us the
> -- contents of master.cf
> -- the output of 'postconf -n'
> -- the contents of main.cf (to see "custom" variables)
6) "postmap -q - <table>" output for all relevant keys in all relevant
tables.
7) verbose logging from the smtpd(8) showing the events that lead
up to reject restriction. Configure via "debug_peer_list" or "-v"
entry in master.cf. It is enough to report just 10-20 lines of
logging above the "reject" event, that demonstrate which restrictions
is being processed and associated table lookup keys and results.
As I noted earlier, I restored my main.cf and master.cf from backup (a
known working version) and started over.
I ran these tests with that version and found no problems. I then
changed the configurations to the desired end-point and ran these (and
a few other) tests again. Again no problems.
So I was not able to reproduce this. I have to conclude that I took
interim steps on the way to the desired state, and one of those
resulted in the errors I observed. Since I did not document my steps,
only my goal, I cannot reproduce each one, and since I cannot find the
combination that produced the error, I have to conclude that I did
something seriously wrong at some point.
So I must apologize - I have asked you to help chase an issue that
seems to have been just an interim error. I appreciate your help and
effort, but I am sorry that it appears unnecessary. (of course, if it
recurs, I'll run these tests again, and if I can reproduce it, post
all the information here)
I now have it working, as far as I can tell, as I want. The goal was
to have a submission service that forces authentication and requires
that authenticated users only send from addresses they own.
So I now have:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=
$
587_master_sender_restrictions
,reject_sender_login_mismatch,permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
with, in main.cf:
587_master_sender_restrictions=check_sender_access pcre:/etc/postfix/
smtpd_sender_restrictions.pcre
and
smtpd_sender_restrictions.pcre containing one line:
/^(.*)/ PREPEND X-Envelope-Sender: <${1}>
I was concerned that the "match" on PREPEND would obviate the further
sender_restrictions, but that appears not to be the case, in limited
testing so far.
The recipient_restrictions are solely meant to avoid the many checks
( e.g. RBL, unauth_pipelining, etc.) in my main.cf for my smtp service.
This appears to work. I am of course, open to any and all suggestions
on how this can be improved.
Again, sorry for dragging you down an dead-end path, but thank you for
your help - I've learned a lot along the way.
--Jeff
