[ top-posting fixed ]
> -----Ursprungligt meddelande-----
> [mailto:owner-postfix-us...@postfix.org] För /dev/rob0
>
> On Thu, Nov 17, 2016 at 05:31:43PM +0100, Sebastian Nielsen wrote:
> > The advantage with using "permit_sasl_authenticated, reject" as
> > check_sender_access in the global config, is that authenticated
> > senders won't be able to send with a adress outside of your
> > domain either, thus achieving both local spoof prevention for
> > unauthenticated users, but also prevents foregin spoof from
> > authenticated users.
>
> That's not true.
>
> "permit_sasl_authenticated" does exactly what it says, regardless
> of sender address. If the client successfully authenticated, the
> mail is accepted.
On Sat, Nov 19, 2016 at 07:47:40PM +0100, Sebastian Nielsen wrote:
> Im talking about this:
>
> smtpd_sender_restrictions = check_sender_access hash:/etc/file
>
> /etc/file (before postmap)
> mydomain.com permit_sasl_authenticated, reject
Please don't use a real domain as an example. We have example.com
(and in many other TLDs besides com, guaranteed by RFC 6761 in net
and org) for that.
> The result is that if sender domain is mydomain.com, the policy
> applied will be "permit_sasl_authenticated, reject". This will
> result in any unauthenticated mail claiming to be from mydomain.com
> to be rejected (, reject), even if the destination is authorized
> since the policy stack will see a plain "reject" before
> "reject_unauth_destination".
This part is correct.
> BUT, if the sender is NOT mydomain.com, the check_sender_access
> will return nothing, thus there will be no
> "permit_sasl_authenticated" on the policy stack, thus the mail will
> be rejected with "Relay access denied" even for authenticated
"Relay access denied" comes only in smtpd_relay_restrictions (or
smtpd_recipient_restrictions in older versions.) Look again: your
example is in smtpd_sender_restrictions and is therefore incorrect.
> users, as the policy stack will end up on
> "reject_unauth_destination" without seeing any
> permit_sasl_authenticated.
Your repeated reference to a "policy stack" suggests that you might
wrongly believe there is a connection between the various
smtpd_mumble_restrictions stages. There is not. Each stage must
result in a permit action (or "DUNNO", which invokes the implied
"permit" at the end of each one) or the mail is not accepted. More
specifically, the result from any one "mumble" stage has no bearing
on the result from any other stage.
> (Note that this means that every instance of
> "permit_sasl_authenticated" need to be replaced with
> "check_sender_access hash:/etc/file")
Okay, sort of. You didn't say this part before. It's true if you
are replacing permit_sasl_authenticated in *relay* restrictions. BTW
smtpd_relay_restrictions has a default setting which includes
permit_sasl_authenticated, so that default would also have to be
changed; your plan fails if smtpd_relay_restrictions are not
specified in the main.cf file.
A much simpler and better way to do this and to force the use of
submission for your clients is to change the default on port 25, and
to override relay restrictions in master.cf for submission, port 587:
main.cf :
[ ... ]
mua_relay_restrictions =
check_sender_access <some-lookup-or-query-file>, reject
smtpd_relay_restrictions = reject_unauth_destination
[ ... ]
master.cf :
[ ... ]
submission [ ... ] smtpd
-o smtpd_relay_restrictions=$mua_relay_restrictions
[ -o to unset any other restrictions in use, plus the ones
which are found in the sample master.cf submission entry ]
[ ... ]
> You understand the idea now?
I understood it before. :)
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
