Re: BCP on throttling outbound mail
On 7/24/2012 12:44 AM, CSS wrote: On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote: On 7/23/2012 4:16 PM, CSS wrote: I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use. See: http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit You would apply this to your submission service, eg: 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_connection_rate_limit=1 This limits spammers and legit users to 1 msg/min, 60 msgs per hour. Postfix is not psychic. This may be a problem for roaming users who send batches of mails when they get a connection--10 msgs takes 10 minutes. Thus, as with anything, some analysis and [re]tuning will be required. If you trust some users to never have their acct compromised, you can always create multiple submission services on different ports and have different limits for different sets of users, or even no limits for some. Not a perfect solution, but better than what you have now. If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers. Apparently you didn't read the docs I provided. http://www.postfix.org/postconf.5.html#anvil_rate_time_unit The time unit over which client connection rates and other rates are calculated. Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds) Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting? Probably. But I think you summarily discounted the inbuilt Postfix equivalent too quickly, without even looking at it. You can having it running in less than 60 seconds. It seems like the internet as whole would certainly benefit from a dead-simple policy daemon that could thwart the attempts of spammers using hijacked credentials to spew their junk. You'd think humans beings would be smart enough to follow directions and use strong passwords, AV software, etc, and not fall for phishing scams. Your adversary in this war isn't the spammers, it's not the technology, but your users. You should not be expending any more time/effort on the tech piece of the solution beyond finding the most basic rate limiting tool and enabling it to prevent spewage, right now. This is the smallest battle in this war. The big battles are user education (AV software on their machines, safe surfing habits, anti-phish education, etc), and wholesale forcing all users to change to *enforced* strong passwords. The user related stuff wins this war. The tech portion merely decreases the amount of damage per clueless user battle. -- Stan
Re: BCP on throttling outbound mail
On Jul 24, 2012, at 2:37 AM, Stan Hoeppner wrote: On 7/24/2012 12:44 AM, CSS wrote: On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote: On 7/23/2012 4:16 PM, CSS wrote: I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use. See: http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit You would apply this to your submission service, eg: 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_connection_rate_limit=1 This limits spammers and legit users to 1 msg/min, 60 msgs per hour. Postfix is not psychic. This may be a problem for roaming users who send batches of mails when they get a connection--10 msgs takes 10 minutes. Thus, as with anything, some analysis and [re]tuning will be required. If you trust some users to never have their acct compromised, you can always create multiple submission services on different ports and have different limits for different sets of users, or even no limits for some. Not a perfect solution, but better than what you have now. If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers. Apparently you didn't read the docs I provided. http://www.postfix.org/postconf.5.html#anvil_rate_time_unit I actually have some rate-limiting already, but obviously not enough. The time unit over which client connection rates and other rates are calculated. Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds) Perhaps I'm misunderstanding this, but I was under the impression that the anvil limits were all enforced on a per-connection or per-IP limit. I'm really after something that can track a particular sasl-authenticated user and punish them (and not other users). I'll re-read what I can find on anvil again, the recommendations against its use in this situation may have been dated. Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting? Probably. But I think you summarily discounted the inbuilt Postfix equivalent too quickly, without even looking at it. You can having it running in less than 60 seconds. Which I may just do in hopes it can provide a base level of protection. It seems like the internet as whole would certainly benefit from a dead-simple policy daemon that could thwart the attempts of spammers using hijacked credentials to spew their junk. You'd think humans beings would be smart enough to follow directions and use strong passwords, AV software, etc, and not fall for phishing scams. Your adversary in this war isn't the spammers, it's not the technology, but your users. I've worked with end users since 1995. They aren't changing. In fact, the facebook-ization of the internet is bringing us right back to the good old AOL days of walled gardens. Users are getting less, not more savvy. You should not be expending any more time/effort on the tech piece of the solution beyond finding the most basic rate limiting tool and enabling it to prevent spewage, right now. This is the smallest battle in this war. Funny, as I was speaking to my partner about this issue and he was wondering why all the spam wars are being fought on the recipient end - so many cpu cycles and hardware to filter the 20% or so of good mail from the bad. He could not grasp why the source of the spam could not be legislated away. The big battles are user education (AV software on their machines, safe surfing habits, anti-phish education, etc), and wholesale forcing all users to change to *enforced* strong passwords. I had suspected a guessable password, and I was wrong. This customer routinely calls in with various issues and the tech that works with them has the password so he can login to webmail as the customer and verify whatever oddity they see. It was not the best, but it was random, mixed-case, mixed numbers and letters. Was it a *unique* password? Probably not... The user related stuff wins this war. The tech portion merely decreases the amount of damage per clueless user battle. The war will be lost. TimeWarner, Comcast, Verizon and everyone else is not going to either lose customers by cutting off the ever-infected clueless or spend time (money) educating them... Charles -- Stan
Re: BCP on throttling outbound mail
On 7/24/2012 2:08 AM, CSS wrote: Perhaps I'm misunderstanding this, but I was under the impression that the anvil limits were all enforced on a per-connection or per-IP limit. I'm really after something that can track a particular sasl-authenticated user and punish them (and not other users). I'll re-read what I can find on anvil again, the recommendations against its use in this situation may have been dated. It's per client IP. But Postfix logs client IP with or in proximity to the SASL username, so it shouldn't be hard to x-reference the user who starts tripping anvil. But you'll want a log monitor that emails you when anvil trips, so you can disable compromised accounts, not allowing them to continue leaking, hitting traps, getting you blacklisted, etc. Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting? Probably. But I think you summarily discounted the inbuilt Postfix equivalent too quickly, without even looking at it. You can having it running in less than 60 seconds. Which I may just do in hopes it can provide a base level of protection. -o smtpd_client_connection_rate_limit=10 may be a good starting point. Road warriors can thus blast 10 saved msgs at full throttle, but msg 11 will have to wait until 60s after the first msg. After the 2nd/3rd email notification from your anvil watcher, you'll can be certain you have a compromised account (or a misbehaving user). If you/staff are able to react in 5 minutes, only 50 spams have escaped. Obviously full automation of account disabling along with staff notification would be preferable. Scripting all this shouldn't be too difficult. I've worked with end users since 1995. You sir are a saint. They aren't changing. In fact, the facebook-ization of the internet is bringing us right back to the good old AOL days of walled gardens. Users are getting less, not more savvy. Percentage wise I'd say savvy-ness is the same. Problem is we have ~100M more internet users (US anyway) than in '95. So yes, total number of dumb users has increased many fold, no argument there. Funny, as I was speaking to my partner about this issue and he was wondering why all the spam wars are being fought on the recipient end - so many cpu cycles and hardware to filter the 20% or so of good mail from the bad. He could not grasp why the source of the spam could not be legislated away. Heheh. That conversation can't have been as brief as you elude. ;) I had suspected a guessable password, and I was wrong. This customer routinely calls in with various issues and the tech that works with them has the password so he can login to webmail as the customer and verify whatever oddity they see. It was not the best, but it was random, mixed-case, mixed numbers and letters. Was it a *unique* password? Probably not... So if it wasn't guessed, how was it obtained? This user sounds like phish target, all the hand holding. The user related stuff wins this war. The tech portion merely decreases the amount of damage per clueless user battle. The war will be lost. That's the spirit! I won't predict the end game, but we can all agree the war against spam will last a long time. Also depends on the definition of 'win'. If we can get down to 1 spam in the inbox per week per worldwide average user, I'd call the war 'won'. One per day would be 'winning'. TimeWarner, Comcast, Verizon and everyone else is not going to either lose customers by cutting off the ever-infected clueless or spend time (money) educating them... They lose thousands of customers/day to one another just over pricing specials and promos. They wouldn't care one bit if they shed a few thousand problem users. They're likely losing profit on them anyway due to support calls and technician visits to reset modems and bs like that. Likely less phone costs now that most farm level 1 to India. -- Stan
Re: BCP on throttling outbound mail
At 04:16 PM 7/23/2012, you wrote: Hello, Sorry for the broad question, but is there any sort of best common practice these days regarding limiting outbound email? We recently had a customer's account compromised (not sure if it was brute-forced or keylogged) and then the perp proceeded to use their credentials to smtp-auth themselves a huge load of viagra spam. I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use. I assume this is not an uncommon scenario, but pointers from those with more Postfix experience would be quite welcome. I do have amavis available for outbound virus scanning, and could conceivably have it do the same with spam scanning but that feels not quite right (and probably fairly resource intensive if someone was trying to cram tens of thousands of messages through the system). Thanks, Charles I've been using postfwd.org for rate-limiting outbound senders, and inbound senders and IPs, plus lots of other inbound filtering, for a 2+ years. It killed our horrible problem of cracked passwords. Len
Re: BCP on throttling outbound mail
Len Conrad: I've been using postfwd.org for rate-limiting outbound senders, and inbound senders and IPs, plus lots of other inbound filtering, for a 2+ years. It killed our horrible problem of cracked passwords. I think that dedicated tools such as postfwd and the like are the way to go. This is better (for users and developers) than trying to provide all solutions within Postfix itself. Wietse
Minimal permissions on /etc/postfix
We store our virtual_foo_maps in, /etc/posfix/maps/virtual_foo_maps.pgsql and so the (read-only) database credentials are visible in that file. I'd like to tighten this up if possible, but I don't want to do anything stupid. If I'm not going about this all wrong, what can I do to prevent e.g. SSH users from reading the DB credentials? Ideally, I'd also like to prevent them from reading the rest of the maps, which contain lists of addresses, clients, etc.
Re: Minimal permissions on /etc/postfix
On Jul 24, 2012, at 18:09, Michael Orlitzky wrote: We store our virtual_foo_maps in, /etc/posfix/maps/virtual_foo_maps.pgsql and so the (read-only) database credentials are visible in that file. I'd like to tighten this up if possible, but I don't want to do anything stupid. If I'm not going about this all wrong, what can I do to prevent e.g. SSH users from reading the DB credentials? Ideally, I'd also like to prevent them from reading the rest of the maps, which contain lists of addresses, clients, etc. This works for us; $ ls -ald /etc/postfix drwxr-x--- 5 root postcfg 4096 Jul 24 18:05 /etc/postfix The postfix user is a member of the 'postcfg' group. Any admin accounts that need access to the contents can also be added if needs be. Cya, Jona
Re: Suppressing *all* MX lookups on a transport
On Jul 24, 2012, at 02:22, Ori Bani wrote: On Mon, Jul 23, 2012 at 5:07 PM, Viktor Dukhovni postfix-us...@dukhovni.org wrote: On Mon, Jul 23, 2012 at 03:33:53PM -0700, Marty Beckler wrote: Transport next hops can have MX lookups disabled by adding [] around the next hop. Is it possible to define a transport that always has MX lookups disabled without specifying the next hop? man 5 transport says that trivial-rewrite(8) doesn't allow substitutions in pcre tables, otherwise, this is what I'd want: /(.+\.internal)/ internal_smtp:[$1] So is there any other way to disable MX lookups wholesale for a given transport? What's wrong with MX lookups? If the records are absent, Postfix will use A records, Interesting, for me, postfix was throwing up its hands instead. so you generally don't need to suppress MX lookups unless you have wildcard MX records or incorrect MX records. Just make sure your MX records either don't exist or are sensible. Making up top level domains like .internal is not a good idea. If the TLD is not reserved by RFC and does not exist (yet) don't use it. With ICANN slated to register a few thousand new TLDs this year, you may find your fantasy TLD turning into someone else's reality. If your domain is example.com, consider internal.example.com as a root for internal domains. There's too many hosts we need to resolve so short of DNS tricks, just disabling lookups in postifx is easiest. OK, thanks for your advice. I appreciate it. Having valid, properly resolving DNS is not a trick, and a much better solution than compensating for it on a different level. If a subdomain is not an option, register a valid 'network domain' for your internal use, and use that. Like 'example-lan.net' if your main domain is 'example.com', or something similar. Routing mail to many hosts then becomes as simple as making sure they have valid A/ records within that domain. Makes your life easier with regard to IPv6, too. Cya, Jona
Re: Minimal permissions on /etc/postfix
On 07/24/12 12:24, DTNX Postmaster wrote: On Jul 24, 2012, at 18:09, Michael Orlitzky wrote: We store our virtual_foo_maps in, /etc/posfix/maps/virtual_foo_maps.pgsql and so the (read-only) database credentials are visible in that file. I'd like to tighten this up if possible, but I don't want to do anything stupid. If I'm not going about this all wrong, what can I do to prevent e.g. SSH users from reading the DB credentials? Ideally, I'd also like to prevent them from reading the rest of the maps, which contain lists of addresses, clients, etc. This works for us; $ ls -ald /etc/postfix drwxr-x--- 5 root postcfg 4096 Jul 24 18:05 /etc/postfix The postfix user is a member of the 'postcfg' group. Any admin accounts that need access to the contents can also be added if needs be. Thanks, I actually tried this but ran into a problem: Jul 24 01:45:50 localhost postfix/sendmail[26795]: fatal: open /etc/postfix/main.cf: Permission denied That alone is easy to fix (allow $authorized_submit_users read access to main.cf), but it suggested that I might run into more subtle problems if I started messing with /etc/postfix.
Re: BCP on throttling outbound mail
On Jul 24, 2012, at 6:23 AM, Len Conrad wrote: At 04:16 PM 7/23/2012, you wrote: Hello, Sorry for the broad question, but is there any sort of best common practice these days regarding limiting outbound email? We recently had a customer's account compromised (not sure if it was brute-forced or keylogged) and then the perp proceeded to use their credentials to smtp-auth themselves a huge load of vxa spam. I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use. I assume this is not an uncommon scenario, but pointers from those with more Postfix experience would be quite welcome. I do have amavis available for outbound virus scanning, and could conceivably have it do the same with spam scanning but that feels not quite right (and probably fairly resource intensive if someone was trying to cram tens of thousands of messages through the system). Thanks, Charles I've been using postfwd.org for rate-limiting outbound senders, and inbound senders and IPs, plus lots of other inbound filtering, for a 2+ years. It killed our horrible problem of cracked passwords. If you could share some of the basics of that config, I'd love to see them. I looked at that briefly before slogging through policyd/cluebringer, and a (very quick) read of their intro page didn't make it obvious that you could track per-user message counts. Does anyone use the old non-perl policyd1? That looked like an easy setup, but it's quite old. For anyone interested, a very basic per-user (more specifically, per authenticated user, which is the only kind of user I've got outside of web apps submitting w/php) setup ended up being fairly easy to implement. The config is all sql-based, I'd be more than happy to share a dump of the config I ended up with. I have some doubts about how well it scales, and I've also added another single point of failure to all inbound and outbound email, but it does what it says it does. The policy I setup basically matches all sasl-authenticated users and puts them in a queue that limits them to 100 messages per hour. That's my starting point, I'll probably adjust it at some point. For web applications, I'm going to install ssmtp and configure that to send with a dedicated username which will have its own limits. Thanks, Charles Len
Re: Minimal permissions on /etc/postfix
On Wednesday, July 25, 2012 at 12:09 AM, Michael Orlitzky wrote: We store our virtual_foo_maps in, /etc/posfix/maps/virtual_foo_maps.pgsql and so the (read-only) database credentials are visible in that file. I'd like to tighten this up if possible, but I don't want to do anything stupid. If I'm not going about this all wrong, what can I do to prevent e.g. SSH users from reading the DB credentials? Ideally, I'd also like to prevent them from reading the rest of the maps, which contain lists of addresses, clients, etc. Works for me with owner 'root', group 'postfix', permission 0640. Zhang Huangbin iRedMail: Open Source Mail Server Solution for Red Hat Enterprise Linux, CentOS, Scientific Linux, Debian, Ubuntu, Gentoo, openSUSE, FreeBSD, OpenBSD: http://www.iredmail.org/
Re: BCP on throttling outbound mail
Le 24/07/2012 08:37, Stan Hoeppner a écrit : On 7/24/2012 12:44 AM, CSS wrote: On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote: On 7/23/2012 4:16 PM, CSS wrote: I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use. See: http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit You would apply this to your submission service, eg: 587 inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_connection_rate_limit=1 This limits spammers and legit users to 1 msg/min, 60 msgs per hour. Postfix is not psychic. This may be a problem for roaming users who send batches of mails when they get a connection--10 msgs takes 10 minutes. Thus, as with anything, some analysis and [re]tuning will be required. If you trust some users to never have their acct compromised, you can always create multiple submission services on different ports and have different limits for different sets of users, or even no limits for some. Not a perfect solution, but better than what you have now. If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers. Apparently you didn't read the docs I provided. http://www.postfix.org/postconf.5.html#anvil_rate_time_unit anvil is not an anti-spam solution. it's measure against clients gone crazy. fighting outbound spam is a serious challenge. [skip] You'd think humans beings would be smart enough to follow directions and use strong passwords, AV software, etc, and not fall for phishing scams. Your adversary in this war isn't the spammers, it's not the technology, but your users. oh come on! the users excuse is wa too old. if your software accepts weak passwords, then the problem is with the software, not the user. AV? oh no, I don't want any on my unix boxen. phising? well, it's far from being a simple thing. when OS, pki browser vendors will ignore their business for the happiness of the universe, things might get better in an Alice wonderfull world. do you really believe it? You should not be expending any more time/effort on the tech piece of the solution beyond finding the most basic rate limiting tool and enabling it to prevent spewage, right now. This is the smallest battle in this war. The big battles are user education (AV software on their machines, safe surfing habits, anti-phish education, etc), and wholesale forcing all users to change to *enforced* strong passwords. I disagree. those who put the responsibility of their failure on others (call em users or whataver) should get another job. The user related stuff wins this war. The tech portion merely decreases the amount of damage per clueless user battle.
Re: Minimal permissions on /etc/postfix
Le 24/07/2012 18:09, Michael Orlitzky a écrit :
We store our virtual_foo_maps in,
/etc/posfix/maps/virtual_foo_maps.pgsql
and so the (read-only) database credentials are visible in that file.
I'd like to tighten this up if possible, but I don't want to do anything
stupid.
If I'm not going about this all wrong, what can I do to prevent e.g. SSH
users from reading the DB credentials? Ideally, I'd also like to prevent
them from reading the rest of the maps, which contain lists of
addresses, clients, etc.
map_directory = /var/db/postmap
cidr = cidr:${map_directory}/cidr
db = ${db_type}:${map_directory}/${db_type}
map_directory = /var/db/postmap
regex = ${regex_type}:${map_directory}/${regex_type}
sql = ${sql_type}:${map_directory}/${sql_type}
...
ls -l /var/db/
...
drwxr-x---9 root postfix 512 Feb 10 2011 postmap/
...
note that I prefer
/somedir/pgsql/foo_map
over
/somedir/foo_map.pgsql
this is because I can do
db_type=mysql
foo_map=${db_type}:/somedir/${db_type}/foo_map
Re: Minimal permissions on /etc/postfix
On 07/24/2012 07:33 PM, mouss wrote:
map_directory = /var/db/postmap
cidr = cidr:${map_directory}/cidr
db = ${db_type}:${map_directory}/${db_type}
map_directory = /var/db/postmap
regex = ${regex_type}:${map_directory}/${regex_type}
sql = ${sql_type}:${map_directory}/${sql_type}
...
ls -l /var/db/
...
drwxr-x---9 root postfix 512 Feb 10 2011 postmap/
...
Ok, thanks, I'll stick with this for a while and see what happens. It
seems sendmail needs to read main.cf, but not any of the map files (at
least, not the ones I'm using in the way I'm using them) or master.cf.
We've only got two boxes that have anything sensitive in the maps; on
the one with the mail store, I have just:
/etc/postfix:
cp -R etc/postfix /etc/
chgrp -R postfix /etc/postfix
find /etc/postfix -type d -print0 | xargs -0 chmod 755
find /etc/postfix -type f -print0 | xargs -0 chmod 640
chmod 644 /etc/postfix/main.cf
which is close to what you posted, modulo master.cf and 'rx' of the maps
directory.
On the MX, I also need to make one of the map files readable to the
amavis user, but there's nothing sensitive in that map, so 644 is fine
there.
I'll report if anything else breaks =)
Quarantine Spam Mails and Notification to User
Hi, Recently I got request if our mail server can notify the receiver if there is email spam and if the receiver feel it genuine email then they can release it by them self. Does postfix can do this? Or does anyone has implement this? Thank you
