On 12/08/2011 11:24 AM, Grant wrote:
You don't really need the permit_sasl_authenticated, since you shouldn't be
trying to auth on port 25. It doesn't hurt, though.
I just noticed that I can't send mail from Thunderbird unless I
include permit_sasl_authenticated in the above
smtpd_recipient_restrictions block. I get relay access denied
otherwise.
Oh, sorry. You have this in master.cf:
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
The -o smtpd_foo_restrictions here is supposed to override the
restrictions in main.cf:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
permit
So you should change 'client' to 'recipient' in master.cf before you
remove the 'permit_sasl_authenticated' in main.cf.
At that point, SquirrelMail (or anything else) won't be able to send
mail unless it authenticates on port 587, sends to one of your domains
on port 25, or is in $mynetworks and sends on port 25.
The path of least resistance is probably to add the SquirrelMail box to
$mynetworks, and have it send to port 25. If someone can gain control of
the SquirrelMail box, you're screwed mail-wise anyway, so I don't think
you lose any security that way.
The alternative that you had working was letting SquirrelMail auth in
plain text on port 25, which is, should someone compromise the
SquirrelMail box, not going to save you.
