Block certain remote hosts on submission port
Hi all, This isn't about spam, this is about blocking obvious attempts to hack/connect to my submission port. I know and understand the argument against just blanket blocking hosts based on the country of origin, but I've recently been seeing random connections on my submission port from hosts @ .ru and .cn domains. The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? I'd also like to be able to whitelist certain domains, in the rare case where someone might be on vacation abroad, and when they call me complaining that they cannot send email, I can see the country they are in my reject logs and whitelist that country temporarily. Thanks, -- Best regards, */Charles/*
Re: Block certain remote hosts on submission port
On 22 Aug 2013 13:52, Charles Marcus cmar...@media-brokers.com wrote: Hi all, This isn't about spam, this is about blocking obvious attempts to hack/connect to my submission port. I know and understand the argument against just blanket blocking hosts based on the country of origin, but I've recently been seeing random connections on my submission port from hosts @ .ru and .cn domains. The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? I'd also like to be able to whitelist certain domains, in the rare case where someone might be on vacation abroad, and when they call me complaining that they cannot send email, I can see the country they are in my reject logs and whitelist that country temporarily. Surely the simplest solution is fail2ban with the false attempts in x minutes resulting in a 20 minute ban? This works for me... Otherwise you'd get more flexibility at the firewall level for geoip ranges.. Simon
Re: Block certain remote hosts on submission port
On 2013-08-22 8:03 AM, Simon B simon.buongio...@gmail.com wrote: Surely the simplest solution is fail2ban with the false attempts in x minutes resulting in a 20 minute ban? No for two reasons... 1. Again, we have ZERO users who are outside the US, so why allow connections at all? and 2. I am not currently seeing massive hack/crack attempts from the same IP, just random connections from lots of different IP's. Otherwise you'd get more flexibility at the firewall level for geoip ranges.. Actually, yeah, that is probably a better way to do this anyway, seeing as we don't need to allow users from anywhere else to connect... Now to figure out how to log these firewall rejections to a separate log file, so I can see them if/when someone complains about not being able to connect. Thanks Simon. -- Best regards, */Charles/*
Re: Block certain remote hosts on submission port
Am 22.08.2013 14:23, schrieb Charles Marcus: Now to figure out how to log these firewall rejections to a separate log file, so I can see them if/when someone complains about not being able to connect nothing easier than that * the first rule logs with rate-control to avoid self-DOS * the second one rejects * the same works for any iptables rule (log-line excatly like the other rule, different action) iptables -A INPUT -p tcp --dport 587 -s source-range/ip -m conntrack --ctstate NEW -m limit --limit 1/m -j LOG --log-level debug --log-prefix Firewall: iptables -A INPUT -p tcp --dport 587 -s source-range/ip -m conntrack --ctstate NEW -j REJECT --reject-with icmp-admin-prohibited ___ rsyslog.conf *before* all other rules :msg, contains, Firewall -/var/log/firewall.log ~
Filtering outgoing email
When an outgoing email's target address is prefixed by '+', I would like postfix to delete it replying back to the client ok status. I had previously setup below. But this sends back to the client 554. I would like the client to think that in this situation everything is fine. main.cf smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/recipient_access.pcre reject recipient_access.pcre /\+(,*)/reject /(,*)/ permit
Re: Block certain remote hosts on submission port
On 8/22/2013 6:51 AM, Charles Marcus wrote: The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? Use the us.zone ipdeny file to build a CIDR table to accept any US client IPs and reject everything else. http://ipdeny.com/ipblocks/data/countries/us.zone But not now as it's currently broken. Already notified the OPs. Not sure how this happened. This is a big deal as automated systems rely on this data. I'd think it'll be fixed today, within hours. Anyway, your solution should be as simple as something like this: submission inet n - - - - smtpd ... -o smtpd_client_restrictions=check_client_access\ /etc/postfix/us.cidr, reject You could do the reverse and reject the rest of the world with your table, however building an maintaining that CIDR file is a massive PITA. If you have personnel traveling in other countries they use a VPN client to get into your network. That's what roaming VPN clients are for. You can setup a FLOSS VPN server for no cost but your labor/learning curve. Or simply enable/configure it on your edge router if it has VPN capability. -- Stan
Re: Filtering outgoing email
When an outgoing email's target address is prefixed by '+', I would like postfix to delete it replying back to the client ok status. I had previously setup below. But this sends back to the client 554. I would like the client to think that in this situation everything is fine. main.cf smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/recipient_access.pcre reject recipient_access.pcre /\+(,*)/reject /(,*)/ permit You might be interested in looking at discard http://www.postfix.org/discard.8.html
What are the LDAP config diffs between 2.2.10 and 2.10.1
I am upgrading from 2.2.10 to the current 2.10.1 primarily because the former does not understand milters and we are trying to implement DKIM. The problem is that LDAP appears to be broken and we make extensive use of LDAP. When I first copied the production main.cf over to my development box and tried to start Postfix, I got 100's of warning bout unused parameters, and always, they were LDAP configurations that were used and worked on 2.2.10. A quick look at the Postfix HowTo at Postfix.orghttp://Postfix.org, I see I need to create an ldap-aliases.cf file and add it to the alias_maps parameter. But I also do virtual aliases which I specify using a virtual_alias_maps parameter. So, to get me off to a good start, could someone please translate the virtual configuration below into something that will work in 2.10.1: virtual_alias_maps = ldap:ldaptag,ldap:grouptag,ldap:dormtag,ldap:deptag,ldap:divtag ldaptag_server_host = $default_ldap_host ldaptag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu ldaptag_bind_pw = pwd ldaptag_search_base = o=linfield.eduhttp://linfield.edu ldaptag_query_filter = ((|(mailLocalAddress=%s)(uid=%s))(!(ou=Alumni Email Users))) ldaptag_result_attribute = mailRoutingAddress grouptag_server_host = $default_ldap_host grouptag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu grouptag_bind_pw = pwd grouptag_search_base = ou=groups,o=linfield.eduhttp://linfield.edu grouptag_query_filter = ((|(mailLocalAddress=%s)(uid=%s))) grouptag_special_result_attribute = uniquemember grouptag_result_attribute = mailRoutingAddress dormtag_server_host = $default_ldap_host dormtag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu dormtag_bind_pw = pwd dormtag_search_base = ou=DormLists,o=linfield.eduhttp://linfield.edu dormtag_query_filter = (uid=%s) dormtag_special_result_attribute = uniquemember dormtag_result_attribute = mailRoutingAddress deptag_server_host = $default_ldap_host deptag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu deptag_bind_pw = pwd deptag_search_base = ou=departments,o=linfield.eduhttp://linfield.edu deptag_query_filter = (|(mailLocalAddress=%s)(uid=%s)) deptag_special_result_attribute = uniquemember deptag_result_attribute = mailRoutingAddress divtag_server_host = $default_ldap_host divtag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu divtag_bind_pw = pwd divtag_search_base = ou=divisions,o=linfield.eduhttp://linfield.edu divtag_query_filter = (uid=%s) divtag_special_result_attribute = uniquemember divtag_result_attribute = mailRoutingAddress In all but the ldaptag above, the query filter will return a single entry which has a number of uniqueMember attributes, each of which contains the DN of an entry that has a mailRoutingAddress attribute that contains the actual email address. The divtag uniqueMember attribute actually returns the DNs for departments in the division which, in turn, have uniqueMember attributes, each of which contains the DN of an actual person with a mailRoutingAddress attribute. A translation of the above should give me what I need to translate the rest of my LDAP configuration. Thanks. Rob Tanner rtan...@linfield.edumailto:rtan...@linfield.edu
Re: What are the LDAP config diffs between 2.2.10 and 2.10.1
Rob Tanner: I am upgrading from 2.2.10 to the current 2.10.1 primarily because the former does not understand milters and we are trying to implement DKIM. The problem is that LDAP appears to be broken and we make extensive use of LDAP. When I first copied the production main.cf over to my development box and tried to start Postfix, I got 100's of warning bout unused parameters, and always, they were LDAP configurations that were used and worked on 2.2.10. A quick look at the Postfix HowTo at Postfix.orghttp://Postfix.org, I see I need to create an ldap-aliases.cf file and add it to the alias_maps parameter. But I also do virtual aliases which I specify using a virtual_alias_maps parameter. So, to get me off to a good start, could someone please translate the virtual configuration below into something that will work in 2.10.1: virtual_alias_maps = ldap:ldaptag,ldap:grouptag,ldap:dormtag,ldap:deptag,ldap:divtag ldaptag_server_host = $default_ldap_host ldaptag_bind_dn = cn=Postfix,ou=Special Users,o=linfield.eduhttp://linfield.edu ldaptag_bind_pw = pwd ldaptag_search_base = o=linfield.eduhttp://linfield.edu ldaptag_query_filter = ((|(mailLocalAddress=%s)(uid=%s))(!(ou=Alumni Email Users))) I don't see why this would result in hundreds of warnings. I pasted the first part into my main.cf and there were no surprises. Wietse
piping bounce service to external program
I am trying to set up postfix to send bounced messages to an external script
to log the bounce to an external logging service so that we can monitor
bounce rates to different recipient domains. I want to keep the default
bounce behavior intact, so bounce notices are still send to the original
sender.
I have been hunting and testing different configurations for 2 days and
haven't had success, yet, in figuring it out.
First I tried changing the bounce service to use a pipe command:
in master.cfg I changed to bounce service to this bounce unix - n n - -
pipe flags=Fhq user=bouncelog argv=/usr/local/bin/bounches.sh ${sender}
${recipient}
I found somewhere people recommending not to do this because it is a system
critical service. This also destroys the default bounce behavior, which I'm
trying to keep intact. It generated the following errors, but it is probably
not the right approach anyway:
smtp postfix/pipe[13243]: warning: unexpected attribute nrequest from bounce
socket (expecting: flags)
smtp postfix/pipe[13243]: warning: deliver_request_get: error receiving
common attributes
Next I tried a custom transport for bounce notification emails
in main.cfg
notify_classes = bounce
bounce_notice_recipient = boun...@domain.com
at the top of my transport map:
boun...@domain.combounces:
in master.cfg:
bounces unix - n n - - pipe
flags=FXhq user=bouncelog argv=/usr/local/bin/bounces.sh ${sender}
${recipient}
I was sure to run `postmap /etc/postfix/transport` after making changes to
the transport and `postfix reload` after modifying config files.
This one appeared to be working, but it doesn't quite. It has a few issues.
${sender} ends up being double-bou...@smtp.domain.com and ${recipient} is
boun...@domain.com. I believe, however, by looking at the logs that this
issue is caused because the bounce_notify email is actually sent, then
bounces, and that bounce notification is the one that gets logged instead of
the original bounce. I haven't found what I'm doing wrong, but it seems to
not be the correct approach since I want to log the bounce not parse an
email about the bounce.
We have an ebook copy of Postfix - The Definitive Guide. I've read
everything in it regarding bounces and pipes. I haven't found anything that
points me in the right direction or answers my questions.
I'm wondering if anyone on the list can point me to the right documentation
and give me some pointers as to what I'm missing and what I need to
correct/fix to get this working. I'm almost to the point just writing a
script that tails the maillog and parses any line with status=bounced or
status=deferred in it. I would like something a little more real-time and
fault tolerant, though, and I'd like to do it correctly.
Thanks in advance for your help!
--
View this message in context:
http://postfix.1071664.n5.nabble.com/piping-bounce-service-to-external-program-tp60729.html
Sent from the Postfix Users mailing list archive at Nabble.com.
Re: piping bounce service to external program
Brian Armstrong: I am trying to set up postfix to send bounced messages to an external script to log the bounce to an external logging service so that we can monitor bounce rates to different recipient domains. I want to keep the default bounce behavior intact, so bounce notices are still send to the original sender. I have been hunting and testing different configurations for 2 days and haven't had success, yet, in figuring it out. Configure the appropriate bounce-recipient and use a transport map to pipe mail for that recipient into a script: /etc/postfix/main.cf notify_classes = bounce, bounce_notice_recipient = u...@example.com transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: u...@example.com bounce-pipe: /etc/postfix/master.cf bounce-pipe pipe flags=xxx user=yyy argv=/path/to/script # postmap /etc/postfix/transport # postfix reload The bounce message contains the failed recipient (the Final-Recipient: field) and the envelope sender (the X-Postfix-Sender: field). An example of all this is at the end of ADDRESS_REWRITING_README. Wietse
Re: Filtering outgoing email
Thanks a lot. Exactly what I was looking for. On Thu, Aug 22, 2013 at 1:43 PM, Drizzt dri...@wizzard.sinners.be wrote: When an outgoing email's target address is prefixed by '+', I would like postfix to delete it replying back to the client ok status. I had previously setup below. But this sends back to the client 554. I would like the client to think that in this situation everything is fine. main.cf smtpd_recipient_restrictions = check_recipient_access pcre:/etc/postfix/recipient_access.pcre reject recipient_access.pcre /\+(,*)/reject /(,*)/ permit You might be interested in looking at discard http://www.postfix.org/discard.8.html
Re: piping bounce service to external program
Wietse, Thank you very much for your response. I'd mentioned that I'd tried this approach in my first message. You are, however, correct. I was misreading the maillog when I thought it was sending the message and well as hitting my script. I need to look at the daemon/queue/service that is logging the message instead of just assuming the to= field means that it was going out over SMTP. The thing I was missing, for history, are the following: 1) With this method, the command line arguments to the script are not the original recipient; they are about the new recipient who is getting the bounce notification (the bounce_notice_recipient). This seems obvious now, after a break of a couple hours. After hitting my heads against it all morning I was fairly numb. 2) The contents of the email are given to the script as standard input. This is well document all over the internet, but - since I kept thinking of this as the same as piping the bounce service - I missed the message contents completely and was just focusing on the macros passing arguments to the script. Thanks for pointing out the fields that I need to look for! That made my life significantly easier in this instance. Your help has been invaluable! -- View this message in context: http://postfix.1071664.n5.nabble.com/piping-bounce-service-to-external-program-tp60729p60732.html Sent from the Postfix Users mailing list archive at Nabble.com.
Re: Block certain remote hosts on submission port
On 8/22/2013 9:57 AM, Stan Hoeppner wrote: On 8/22/2013 6:51 AM, Charles Marcus wrote: The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? Use the us.zone ipdeny file to build a CIDR table to accept any US client IPs and reject everything else. http://ipdeny.com/ipblocks/data/countries/us.zone But not now as it's currently broken. It's fixed now. Anyway, your solution should be as simple as something like this: submission inet n - - - - smtpd ... -o smtpd_client_restrictions=check_client_access\ /etc/postfix/us.cidr, reject After you modify master.cf as above, do ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. -- Stan
Recipient address rejected: aol.com
Does this mean the email address doesn't exist? exam...@aol.com: host mailin-04.mx.aol.com[64.12.138.161] said: 550 5.1.1 exam...@aol.com: Recipient address rejected: aol.com (in reply to RCPT TO command) - Grant
