Postfix and compromised accounts
First of all, sorry for my English.
I think it's very common to set the permit_mynetworks and permit_sasl_authenticated restrictions on first positions of the smtpd_recipient_restriction list, but, if an account is compromised (a virus uses stolen credentials -from Outlook configuration files, for example- to send SPAM), and authenticated clients can send email without further restriction, your last opportunity is your milters correctly reject SPAM messages from compromised accounts; but, isn't it less efficient?
I think postfix is more efficient rejecting SPAM since it uses information from the SMTP protocol and so on, but milters must scan the contents of the messages to detect if a mail is SPAM or not.
However, all of my clients uses TLS to connect to my server. Can viruses/spammers use encrypted connections to send email (provided they stole a password)? I don't think so since spammers try to delivery messages as fastest as possible, and encrypted connections are too slow for these purposes.
If it's the case, I've no problems to permit authenticated clients to send mail, but I would like to be sure about it.
Solution 1:
Based on our discussion in the comments I can think of another way to approach the problem. This used to happen to me all the time in the hosting business- you have to let anybody with basically any client connect to your smtp server, and if their workstation is compromised, they can do what they want.
Again, my approach was defense in depth, with a little offense on the customer service side (ie, tell them if you cause us a spam problem again, we're dropping you).
1)Use Postfix's Rate Controls (you can google for more info- very extensive) This is good for saving cpu cycles and memory on your server in the event a user starts sending spam. This will slow down the damage and not drown a destination host if you have a problem- so it helps you be a polite citizen as well as protect yourself and other users.
local_destination_concurrency_limit = 2
default_destination_concurrency_limit = 10
2)Rate limit based on SMTP user
Postfix has the ability to use policy addons such as this one designed to do exactly what you want
http://wiki.policyd.org/
http://www.simonecaruso.com/limit-sender-rate-in-postfix/
You can be as aggressive as you want with these policies- including disabling the user's account completely so they can't log in until they call you.
3)Don't forget about viruses
Configure postfix to scan outbound mail with http://amavis.sourceforge.net/
I hope this was an acceptable answer. Let me know if you have other questions.
Cheers!
Solution 2:
... if an account is compromised (a virus uses stolen credentials -from Outlook configuration files, for example- to send SPAM), and authenticated clients can send email without further restriction, your last opportunity is your milters correctly reject SPAM messages from compromised accounts; but, isn't it less efficient?
I think postfix is more efficient rejecting SPAM since it uses information from the SMTP protocol and so on, but milters must scan the contents of the messages to detect if a mail is SPAM or not.
As @Binary said in his posts, it's all about multi layer defense. At the first line, postfix have lightweight checks such as postscreen and stmpd_*_restriction (including permit_mynetworks and permit_sasl_authenticated). This defense will be efficient and save many resources.
After lightweight checks, postfix will pass the spam checking to external content_filter (before or after queue). Of course, it will consume more resources but this checks only invoke for (little percent of) emails that passed first line of defense. The deep of defense layer will be determined by your resources.
However, all of my clients uses TLS to connect to my server. Can viruses/spammers use encrypted connections to send email (provided they stole a password)? I don't think so since spammers try to delivery messages as fastest as possible, and encrypted connections are too slow for these purposes.
Of course TLS/encrypted connection is slower than unencrypted one. But the technique like TLS cache has improved performance of SSL handshake for long time. And of course, the spammer/infected client has little care about it. They just need an attack vector to launch the spam/virus email via your server.