On 17/12/2012 3:03 PM, /dev/rob0 wrote:
On Mon, Dec 17, 2012 at 01:54:59PM -0500, John Allen wrote:
For various reasons it has been decided that internal users will
only be allowed to use IMAPS/Submiission for email.
Our setup is a fairly conventional Postfix/Dovecot/Amavis/... on
Debian/Ubuntu.
q1) am i correct in assuming that the smtpd section of main.cf is
aimed at SMTP (tcp port 25) and the the "submission" section in
master.cf is aimed at TCP port 587.
Not exactly. Your main.cf smtpd_* settings are the global defaults
for all smtpd processes. You override those defaults for submission
using -o override options.
It is obvious how it works, once someone points it out. Thanks for the
explanation, its a great help and makes a number of other things clearer.
q2) is it possible (or desirable) to deny staff the ability to
send via port 25, while allowing the rest of the world to send
to port 25. and the obverse is it possible to allow only staff
access to port 587.
Sure. Simply do not include any permit_* restrictions in main.cf
(global) smtpd_recipient_restrictions. Override this with simple
submission_recipient_restrictions for submission:
main.cf :
smtpd_recipient_restrictions = [ ... nothing with permit ... ],]
reject_unauth_destination[, et c. ]
# smtpd_sasl_auth_enable not set
# this could optionally include permit_mynetworks if desired
submission_recipient_restrictions = permit_sasl_authenticated,
reject
master.cf :
submission inet n - n - - smtpd
-o smtpd_sasl_auth_enable=yes
-o smtpd_recipient_restrictions=$submission_recipient_restrictions
-o syslog_name=postfix/submission
-o milter_macro_daemon_name=ORIGINATING
This would, however, allow any of your own senders to reach your
recipients on port 25, assuming they passed any spam checks you
impose. This may or may not be a problem. It can be tightened up
further by use of smtpd_sender_login_maps and requiring AUTH with
reject_unauthenticated_sender_login_mismatch in the global
smtpd_recipient_restrictions. (Remember, you're not even offering
AUTH on port 25, so senders cannot AUTH.)
I have come to the conclusion that the whole basis for my question
is/was stupid. The idea of restricting staff to IMAP/submission is a
policy problem not a technical one.
Thread Closed
--
"He who opens a school door, closes a prison" - Victor Hugo
Sent using Mozilla Thunderbird
