3

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.

  • Malware and spam can be (and usually is) delivered via TLS to MTA or MSA (ESMTPSA). Enforcing TLS is advisable and may reduce risk of passwords being cloned off a wireless network, but that's a small risk compared to phishing, keyloggers or your users reusing the password on some website, which you really can't stop users from doing. So your own outgoing AV/AS, rate-limiting and detection procedures are important. "Spam" is not usually written in capitals, except as a trademark. – Cedric Knight Aug 21 '16 at 14:48
6

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!

  • Yes, it's an answer. I was just configuring SMTP rate limits that I've found in the postfix docs. About anti-virus, my server uses ClamAV. And thanks to add local/default_detination_*, I didn't know them. – Peregring-lk Nov 13 '14 at 23:38
  • Good answer, relevant to postfix, particularly the link to send_rate_policyd github.com/bejelith/send_rate_policyd per-user rate limiting. However, I wonder why you mention local_destination_concurrency_limit = 2 when (a) that's not going to affect spam outgoing via SMTP; (b) it's the postfix default anyway. Wouldn't it make sense to set smtp_destination_concurrency_limit, and perhaps lower than 10? Similarly might want to lower smtp_initial_destination_concurrency smtp_destination_recipient_limit and – Cedric Knight Aug 21 '16 at 14:50
  • I was saying... might want to lower smtp_initial_destination_concurrency, smtp_destination_recipient_limit, and set a non-zero smtp_destination_rate_delay, all in aid of reducing outgoing spam impact while the postmaster takes action. – Cedric Knight Aug 21 '16 at 14:57
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.

1

I agree that using outbound spam filtering as a front line defense against sending spam is inefficient, but it is still important. The alternative is that spam gets through and lands you on a blacklist, then your whole domain is in trouble. So, I think a defense in depth approach is really the only approach here, including frequent password rotations, 2FA, etc. The outbound spam filter is just a layer of that onion- and its an important one. Think of it as the last line of defense, not the first one. Also, you should run this on separate hardware from your mail cluster.

The particular implementation (milters, vs everything else out there) is less important than the overall efficiency of your system. In the layered approach you can determine the effectiveness of each step by measuring the spam that gets through in relation to total email, thus establishing a quantitative way to measure efficiency- or effectiveness. Hopefully by the time outbound spam gets to milter, there will be so little of it that it won't hurt performance.

To answer your last question: I see no reason why any client should not use TLS in 2014. It is another layer in a solid security process. New spam techniques happen every day, and using TLS just protects you incrementally better than no TLS/other encryption.

  • 1
    Thank for your answer, but I'm not asking about if a client should use TLS or not. My server doesn't allow authentication by non-secure channels by default. What I'm asking about if spammers can use stolen credentials under "secure channels" to send SPAM. I'm more warried about what happens when the source of SPAM is my server (when accounts are compromised) than when the source of SPAM is external. – Peregring-lk Nov 13 '14 at 22:40
  • 1
    Ah ok. So for instance are you asking if with TLS enabled, is it possible for an attacker to sniff smtp credentials over the wire (or air)? If not, what attack vectors are you worried about when it comes to these smtp credentials? I managed a few hundred shared hosting servers for several years with postfix email, so perhaps I can help. – Binary Nov 13 '14 at 22:45
  • The attack vectors I'm worry about are the user's computers itself (viruses). Many of my client are too naive; old computers, broken configurations, old mail clients and so on. Over TLS encrypted connections it's impossible nowadays to desencript credentials, so, I'm not worried about it. Ok, some of my clients have passwords like 1234 and so on, and dictionary attacks will need ms to get passwords, but we will ask them to enforce their passwords and solve the problem. So, my main concern is infected computers. – Peregring-lk Nov 13 '14 at 22:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.