postfix permit_sasl_authenticated in smtpd_client_restrictions for submission on 587

Question

First let me explain my setup. I'm using postfix 2.9.6 on Debian Wheezy. I do not allow AUTH on port 25, and force MUAs to use a submission service on port 587 instead. Debian comes with the following configuration in master.cf (commented by default):

submission inet n       -       -       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

I do not understand why permit_sasl_authenticated is in smtpd_client_restrictions. To allow relay access it has to also be added to smtpd_recipient_restrictions (or smtpd_relay_restrictions, for postfix >= 2.10), either in main.cf or preferably in an additional override for the submission service in master.cf:

  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Either way results in checking for authentication twice, and with delayed evaluation of restriction lists, both checks are done at the RCPT TO stage. Without relay access, AUTH clients could send to $mydestination, but the MTA on port 25 already allows that anyway. Without delayed evaluation, the smtpd wouldn't even have information about AUTH yet when it does the client checks.

Is there any benefit at all to having permit_sasl_authenticated in smtpd_client_restrictions, ever? What is the use case for this?

Answer 1

It's simply a clean way of overriding main.cf since usually smtpd_client_restrictions in main.cf isn't used, which is the same as saying by default it is set to smtpd_client_restrictions = permit.

You could achieve the same result by overriding smtpd_recipient_restrictions as you say in your question, in which case you wouldn't need the smtpd_client_restrictions statement, perhaps that might have an unnoticeable performance benefit but if there were other restrictions present in smtpd_recipient_restrictions in main.cf relevant to authenticated clients you would also have to add them to master.cf too and remember to keep them in sync with future edits.

Also from the debian packagers point of view, overriding smtpd_client_restrictions is a safer bet since it's much less likely it was doing anything in main.cf compared with smtpd_recipient_restrictions.

Answer 2

Postfix started supporting mixed restriction lists. Rleated lines from: Postfix Docs

Around the time that smtpd_delay_reject was introduced, Postfix was also changed 
to support mixed restriction lists that combine information about the client, 
helo, sender and recipient or etrn command. 

Mixing is needed for complex whitelisting policies. For example, in order to 
reject local sender addresses in mail from non-local clients, you need to be 
able to mix restrictions on client information with restrictions on sender 
information in the same restriction list. Without this ability, many per-user
access restrictions would be impossible to express. 

The above paragraphs clearly explains why mixed restrictions are supported and required.

In your case, you dont want any restrictions to be enforced on the client(connecting IP/host),once they are authenticated. Assume you have a requirement like "Even if the users authenticate, they shouldn't be able to send email to someone@somedomain.com", then your smtpd_recipient_restrictions should be

#/etc/postfix/main.cf
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/blocked_rcptto
             permit_sasl_authenticated
#/etc/postfix/blocked_rcptto
someone@somedomain.com REJECT No mails can reach this user from us

Hope that helps.

Answer 3

Answering my own question, but I suppose one possible use case would be this:

If I later added smtpd_client_restrictions to main.cf (it is empty by default), to block spam or whatever, then having the override already present for submission in master.cf would allow AUTH clients to skip those restrictions. Not overriding smtpd_client_restrictions might surprise someone by subjecting AUTH clients to spam checks. Of course that may not necessarily be a bad thing..