Postfix - Sandy - 1 more Q re: /etc/postfix/recepient_check
Sandy, List: I need a little more help with syntax in my /etc/postfix/recipient_check file. I have several domains resolving to my IP. I am rejecting certain common system names using the /etc/postfix/recipient_check scheme Sandy suggested when my server was getting bombarded a while back. It works great. But as I need to block more and more of these accounts, I have to make multiple entries for each domain that points to my server. Is there any syntax I could use in the file that would reject mail for all domains, say for support@domain without having to specifically list support@domain1, support@domain2, etc... in the recipient_check file? My current recipient_check file is: [david@bonza ~]$ cat /etc/postfix/recipient_check sales@rankin-bertin.com REJECT assistance@rankin-bertin.com REJECT root@rbpllc.com REJECT root@rankin-bertin REJECT root@rankinlawfirm REJECT root@drrankin.com REJECT uucp@rbpllc.com REJECT uucp@rankin-bertin REJECT uucp@rankinlawfirm REJECT uucp@drrankin.com REJECT Is there an easier way to do this??? I plan on adding all system accounts to the file. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
file. I have several domains resolving to my IP. I am rejecting certain common system names using the /etc/postfix/recipient_check scheme Sandy suggested when my server was getting bombarded a while back. It works great. But as I need to block more and more of these accounts, I have to make multiple entries for each domain that points to my server. Is there any syntax I could use in the file that would reject mail for all domains, say for support@domain without having to specifically list support@domain1, support@domain2, etc... in the recipient_check file? My current recipient_check file is:
Use regular expressions. You've presumably got something like recipient_check = hash:/etc/postfix/recipient_check Create a file called /etc/postfix/recipient_check.pcre : /^support@[domain1|domain2|domain3....]$/ REJECT or /^support@/ REJECT Then change your recipient_check= line to: recipient_check = pcre:/etc/postfix/recipient_check.pcre (You can use plain regex's instead if you prefer). Per Jessen
Sorry, I forgot to change the To: line to Suse..
From: "Per Jessen"
david rankin wrote:
file. I have several domains resolving to my IP. I am rejecting certain common system names using the /etc/postfix/recipient_check scheme Sandy suggested when my server was getting bombarded a while back. It works great. But as I need to block more and more of these accounts, I have to make multiple entries for each domain that points to my server. Is there any syntax I could use in the file that would reject mail for all domains, say for support@domain without having to specifically list support@domain1, support@domain2, etc... in the recipient_check file? My current recipient_check file is:
Use regular expressions.
You've presumably got something like
recipient_check = hash:/etc/postfix/recipient_check
That is correct.
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
or
/^support@/ REJECT
Then change your recipient_check= line to:
recipient_check = pcre:/etc/postfix/recipient_check.pcre
(You can use plain regex's instead if you prefer).
Per, I think you just told me exactly what I needed, but, unfortunately, I don't seem to be smart enough to understand what it is you just told me.... I guess the first point I don't understand is "what is the difference between recipient_check = hash: and recipient_check = prce: ?" The second point I'm missing is "why can't I just use the existing recepient_check file and put "support@ reject" in there?" man postconf says: hash An indexed file type based on hashing. This is available only on systems with support for Berkeley DB databases. pcre (read-only) A lookup table based on Perl Compatible Regular Expres- sions. The file format is described in pcre_table(5). Can't I do something similar with hash?? I don't have a clue about perl. Assembler, Fortran, C, C++ maybe, but definately not perl..... Thanks! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Per, I think you just told me exactly what I needed, but, unfortunately, I don't seem to be smart enough to understand what it is you just told me.... I guess the first point I don't understand is "what is the difference between recipient_check = hash: and recipient_check = prce: ?"
Hi David, good question. the bit before the : (colon) is the access method for postfix to use. "hash" says to expect the table to be in DB format, "pcre" says to expect to find lines of text containing PCRE (Posix Compatible Regular Expressions). There are a few other variations - static:, regex: - time to reach for the postfix manual :-)
The second point I'm missing is "why can't I just use the existing recepient_check file and put "support@ reject" in there?"
Because postfix lookup tables don't work like that :-)
Can't I do something similar with hash?? I don't have a clue about perl. Assembler, Fortran, C, C++ maybe, but definately not perl.....
I'm none too fond of perl myself - but fortunately you don't need to know anything about perl to write PCREs. Are you any good with regular expressions in general? Per
Per Jessen wrote:
expect to find lines of text containing PCRE (Posix Compatible Regular Expressions).
Ooops, that should have been Perl Compatible Regular Expressions of course. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
From: "Per Jessen"
The second point I'm missing is "why can't I just use the existing recepient_check file and put "support@ reject" in there?"
Because postfix lookup tables don't work like that :-)
Can't I do something similar with hash?? I don't have a clue about perl. Assembler, Fortran, C, C++ maybe, but definately not perl.....
I'm none too fond of perl myself - but fortunately you don't need to know anything about perl to write PCREs. Are you any good with regular expressions in general?
Uhh... I'm a little hesitant to answer, because I'm not sure what "regular" means in this case. I'm mean, I can hande "regular" anything as long as I have a man page that tells me what the syntax is : - ). I will give your suggestions a try and take it on faith that regular, in the PCREs case, means the /^ ... @ ...$/ as in: Create a file called /etc/postfix/recipient_check.pcre : /^support@[domain1|domain2|domain3....]$/ REJECT or /^support@/ REJECT Thanks for your help! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Uhh... I'm a little hesitant to answer, because I'm not sure what "regular" means in this case. I'm mean, I can hande "regular" anything as long as I have a man page that tells me what the syntax is : - ).
OK, that says enough. A "regular expression" is a pattern used for, well, pattern matching :-) - it uses a particular syntax.
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
This should be read to mean: if the recipient-address begins with "support@" followed by "domain1" or "domain2" or "domain3" followed by end of line, then REJECT. The ^ says to match the beginning of line, the $ to match the end. The // delineate the expression - if you need to use / in the expression itself, you can escape it using \ Regular expressions are very powerful and occasionally incredibly complex. I have found this site to be very helpful in the past: http://www.regular-expressions.com/ Feel free to ask again - I know I found regexes to be pretty complex beasts in the beginning, but it doesn't take long to get the idea. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
From: "Per Jessen"
david rankin wrote:
Uhh... I'm a little hesitant to answer, because I'm not sure what "regular" means in this case. I'm mean, I can hande "regular" anything as long as I have a man page that tells me what the syntax is : - ).
OK, that says enough. A "regular expression" is a pattern used for, well, pattern matching :-) - it uses a particular syntax.
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
This should be read to mean: if the recipient-address begins with "support@" followed by "domain1" or "domain2" or "domain3" followed by end of line, then REJECT. The ^ says to match the beginning of line, the $ to match the end.
The // delineate the expression - if you need to use / in the expression itself, you can escape it using \
Regular expressions are very powerful and occasionally incredibly complex. I have found this site to be very helpful in the past:
http://www.regular-expressions.com/
Feel free to ask again - I know I found regexes to be pretty complex beasts in the beginning, but it doesn't take long to get the idea.
Thanks Per, Yes, I'm cool with most of the BASH regular expressions. I didn't know the "^ and $" parts though. I'll give it a try and let you know...... -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Regular expressions are very powerful and occasionally incredibly complex. I have found this site to be very helpful in the past:
http://www.regular-expressions.com/
Feel free to ask again - I know I found regexes to be pretty complex beasts in the beginning, but it doesn't take long to get the idea.
Thanks Per,
Yes, I'm cool with most of the BASH regular expressions. I didn't know the "^ and $" parts though. I'll give it a try and let you know......
Definitely test your pattern file with postmap before you use it in your productive configuration! I know that I am still making enough mistakes that I alway check with a should-be-matching test and also a should-NOT-be-matching test. (^-^) By the way, pcre maps and regexp maps do NOT need to be postmapped. you can just edit them and they are effective immediately. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
david rankin wrote:
From: "Per Jessen"
The second point I'm missing is "why can't I just use the existing recepient_check file and put "support@ reject" in there?"
Because postfix lookup tables don't work like that :-)
Can't I do something similar with hash?? I don't have a clue about perl. Assembler, Fortran, C, C++ maybe, but definately not perl.....
I'm none too fond of perl myself - but fortunately you don't need to know anything about perl to write PCREs. Are you any good with regular expressions in general?
Uhh... I'm a little hesitant to answer, because I'm not sure what "regular" means in this case. I'm mean, I can hande "regular" anything as long as I have a man page that tells me what the syntax is : - ). I will give your suggestions a try and take it on faith that regular, in the PCREs case, means the /^ ... @ ...$/ as in:
Regular expressions are an absolute must for adminstrators. You will encounter these pattern matching expressions in most scripting and programming languages.
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
The square brackets don't work on my system with either pcre or regexp. I use round brackets instead. Have you tried it, Per? What you have here is a pattern set between the to slashes: / pattern start ^ the beginning of the line, pattern can not start in the middle support@ just text. (^-^) (val1|val2...) the pattern can have one of the mentioned values within the brackets. | OR $ the end of the line / pattern end hash: support@example.com REJECT pcre: /^support@example\.com$/ REJECT The backslash is escaping the ".", otherwise it would have a special meaning and would match any single character. A literal $ would have to be escaped as \$ to avoid the use as expression matching denominator. The big advantage of pattern versus hashes is that pattern can have placeholders and/or multiple values. testpcre: /^(support@(*example\.com|example2\.*))$/ REJECT internal address $1 rejected! This will hit every the following patterns: support@*example.com support@example2.* Additionally it will use the content in the round brackets as $1, $2 (content of first found expression in brackets, second found... postmap -q "support@testsystem.example.com" pcre:testpcre REJECT internal address support@testsystem.example.com rejected! Take a while to get accustomed to regular expressions. As Per already said, it takes some time and lots of own tests to build up experience and confidence with regular expressions. They will slooowly grow on you. (^-^) Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
The square brackets don't work on my system with either pcre or regexp. I use round brackets instead. Have you tried it, Per?
Duh! My mistake - they should of course be round brackets - square brackets are for characters classes/sets. Good catch, Sandy! /Per Jessen, Zürich
From: "Sandy Drobic"
david rankin wrote:
From: "Per Jessen"
The second point I'm missing is "why can't I just use the existing recepient_check file and put "support@ reject" in there?"
Because postfix lookup tables don't work like that :-)
Can't I do something similar with hash?? I don't have a clue about perl. Assembler, Fortran, C, C++ maybe, but definately not perl.....
I'm none too fond of perl myself - but fortunately you don't need to know anything about perl to write PCREs. Are you any good with regular expressions in general?
Uhh... I'm a little hesitant to answer, because I'm not sure what "regular" means in this case. I'm mean, I can hande "regular" anything as long as I have a man page that tells me what the syntax is : - ). I will give your suggestions a try and take it on faith that regular, in the PCREs case, means the /^ ... @ ...$/ as in:
Regular expressions are an absolute must for adminstrators. You will encounter these pattern matching expressions in most scripting and programming languages.
Create a file called /etc/postfix/recipient_check.pcre :
/^support@[domain1|domain2|domain3....]$/ REJECT
The square brackets don't work on my system with either pcre or regexp. I use round brackets instead. Have you tried it, Per?
What you have here is a pattern set between the to slashes:
/ pattern start
^ the beginning of the line, pattern can not start in the middle
support@ just text. (^-^)
(val1|val2...) the pattern can have one of the mentioned values within the brackets. | OR
$ the end of the line / pattern end hash: support@example.com REJECT
pcre: /^support@example\.com$/ REJECT
The backslash is escaping the ".", otherwise it would have a special meaning and would match any single character. A literal $ would have to be escaped as \$ to avoid the use as expression matching denominator.
The big advantage of pattern versus hashes is that pattern can have placeholders and/or multiple values.
testpcre: /^(support@(*example\.com|example2\.*))$/ REJECT internal address $1 rejected!
This will hit every the following patterns: support@*example.com support@example2.*
Additionally it will use the content in the round brackets as $1, $2 (content of first found expression in brackets, second found...
postmap -q "support@testsystem.example.com" pcre:testpcre REJECT internal address support@testsystem.example.com rejected!
Take a while to get accustomed to regular expressions. As Per already said, it takes some time and lots of own tests to build up experience and confidence with regular expressions.
They will slooowly grow on you. (^-^)
Sandy
Now this is awesome! You mean I even get to test it without having to mail myself something! Who would have thunk.... I switched to pcre with: [root@bonza postfix]# cat recipient_check.pcre /^support@/ REJECT /^info@/ REJECT /^uucp@/ REJECT /^assistance@(rbpllc\.com|rankin-bertin\.com|guillorylaw\.com|garthlawfirm\.com|drrankin\.com)$/ REJECT /^root@/ REJECT /^sales@/ REJECT And all is working fine .... I think........ Thanks Per and Sandy for all of your help! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
Thu, 23 Feb 2006, by drankin@cox-internet.com:
Sandy, List:
I need a little more help with syntax in my /etc/postfix/recipient_check file. I have several domains resolving to my IP. I am rejecting certain common system names using the /etc/postfix/recipient_check scheme Sandy suggested when my server was getting bombarded a while back. It works great. But as I need to block more and more of these accounts, I have to make multiple entries for each domain that points to my server. Is there any syntax I could use in the file that would reject mail for all domains, say for support@domain without having to specifically list support@domain1, support@domain2, etc... in the recipient_check file? My current recipient_check file is:
[david@bonza ~]$ cat /etc/postfix/recipient_check sales@rankin-bertin.com REJECT assistance@rankin-bertin.com REJECT [..] Is there an easier way to do this??? I plan on adding all system accounts to the file.
Sorry for barging in, but that is absolutely the wrongest way possible to do this. If you don't want mail for a user, be it local or virtual, then just do not put the user in your aliases table, /etc/passdwd file, relay_recipient_maps, local_recipient_maps, virtual_aliases_maps etc and set unknown_local_recipient_reject_code = 550. That way Postfix will tell all unknown users they're not welcome. Do *not* use a catch-all, unless you're willing to deal with the torrents of spam arriving in your mailbox. Don't forget that mail for certain accounts are mandatory to to receive, like abuse and postmaster. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
From: "Theo v. Werkhoven"
Thu, 23 Feb 2006, by drankin@cox-internet.com:
Sandy, List:
I need a little more help with syntax in my /etc/postfix/recipient_check file. I have several domains resolving to my IP. I am rejecting certain common system names using the /etc/postfix/recipient_check scheme Sandy suggested when my server was getting bombarded a while back. It works great. But as I need to block more and more of these accounts, I have to make multiple entries for each domain that points to my server. Is there any syntax I could use in the file that would reject mail for all domains, say for support@domain without having to specifically list support@domain1, support@domain2, etc... in the recipient_check file? My current recipient_check file is:
[david@bonza ~]$ cat /etc/postfix/recipient_check sales@rankin-bertin.com REJECT assistance@rankin-bertin.com REJECT [..] Is there an easier way to do this??? I plan on adding all system accounts to the file.
Sorry for barging in, but that is absolutely the wrongest way possible to do this. If you don't want mail for a user, be it local or virtual, then just do not put the user in your aliases table, /etc/passdwd file, relay_recipient_maps, local_recipient_maps, virtual_aliases_maps etc and set unknown_local_recipient_reject_code = 550.
That way Postfix will tell all unknown users they're not welcome.
Do *not* use a catch-all, unless you're willing to deal with the torrents of spam arriving in your mailbox.
Don't forget that mail for certain accounts are mandatory to to receive, like abuse and postmaster.
Theo
Thanks Theo, that is good information. And, I appologize, I didn't really mean "all system accounts." The problem is those creative spammers are beginning to send spam to users like uucp@rankin-bertin.com, etc... What I am looking for is a way to have postfix reject mail sent to these accounts with 550. My current setup is this: [root@bonza david]# postconf -n <snip> mydestination = $myhostname, localhost.$mydomain, $mydomain, rankin-bertin.com, guillorylaw.com, rankinlawfirm.com, drrankin.com myorigin = $mydomain <snip> smtpd_hard_error_limit = 3 smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_check unknown_local_recipient_reject_code = 550 with [david@bonza ~]$ cat /etc/postfix/recipient_check uucp@rankin-bertin.com REJECT uucp@guillorylaw.com REJECT uucp@rankinlawfirm.com REJECT uucp@drrankin.com REJECT How are you guys handling/rejecting mail sent to these type of systmem accounts? I like Per's pcre approach, that at least cuts down on typing. Is this the right approach for what it is I'm trying to do?? -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Thanks Theo, that is good information. And, I appologize, I didn't really mean "all system accounts." The problem is those creative spammers are beginning to send spam to users like uucp@rankin-bertin.com, etc... What I am looking for is a way to have postfix reject mail sent to these accounts with 550. My current setup is this:
As Theo already said, if you don't need an address, then don't use it. If it's an address for internal use only then protect it by rejecting all external/undesired clients for that address.
How are you guys handling/rejecting mail sent to these type of systmem accounts? I like Per's pcre approach, that at least cuts down on typing. Is this the right approach for what it is I'm trying to do??
Delete the alias if you don't need it (or comment it if you aren't sure) or protect it with a recipient check or restriction class. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
david rankin wrote:
Thanks Theo, that is good information. And, I appologize, I didn't really mean "all system accounts." The problem is those creative spammers are beginning to send spam to users like uucp@rankin-bertin.com, etc... What I am looking for is a way to have postfix reject mail sent to these accounts with 550. My current setup is this:
As Theo already said, if you don't need an address, then don't use it. If it's an address for internal use only then protect it by rejecting all external/undesired clients for that address.
How are you guys handling/rejecting mail sent to these type of systmem accounts? I like Per's pcre approach, that at least cuts down on typing. Is this the right approach for what it is I'm trying to do??
PCRE will at least cut down on typing that is true. /^support@/ REJECT /^uucp@/ REJECT ... Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
From: "Sandy Drobic"
david rankin wrote:
Thanks Theo, that is good information. And, I appologize, I didn't really mean "all system accounts." The problem is those creative spammers are beginning to send spam to users like uucp@rankin-bertin.com, etc... What I am looking for is a way to have postfix reject mail sent to these accounts with 550. My current setup is this:
As Theo already said, if you don't need an address, then don't use it. If it's an address for internal use only then protect it by rejecting all external/undesired clients for that address.
How are you guys handling/rejecting mail sent to these type of systmem accounts? I like Per's pcre approach, that at least cuts down on typing. Is this the right approach for what it is I'm trying to do??
Delete the alias if you don't need it (or comment it if you aren't sure) or protect it with a recipient check or restriction class.
Sandy
Ah Hah! (light bulb goes on). The "delete the alias" was the part I was missing. One of these days I will actually learn postfix. Thanks again Sandy! -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
Fri, 24 Feb 2006, by drankin@cox-internet.com:
From: "Theo v. Werkhoven"
Thu, 23 Feb 2006, by drankin@cox-internet.com:
[..]
sales@rankin-bertin.com REJECT assistance@rankin-bertin.com REJECT [..] Is there an easier way to do this??? I plan on adding all system accounts to the file.
Sorry for barging in, but that is absolutely the wrongest way possible to do this. If you don't want mail for a user, be it local or virtual, then just do not put the user in your aliases table, [..]
Thanks Theo, that is good information. And, I appologize, I didn't really mean "all system accounts." The problem is those creative spammers are beginning to send spam to users like uucp@rankin-bertin.com, etc... What I am looking for is a way to have postfix reject mail sent to these accounts with 550. My current setup is this:
[root@bonza david]# postconf -n <snip> mydestination = $myhostname, localhost.$mydomain, $mydomain, rankin-bertin.com, guillorylaw.com, rankinlawfirm.com, drrankin.com myorigin = $mydomain <snip> smtpd_hard_error_limit = 3 smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_check unknown_local_recipient_reject_code = 550
This setup looks ok. If there are no unwanted users in the tables I mentioned earlier, you should see dictionary attacks and mail to fantasy names be rejected in the log. My recipient_restiction rules: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_unlisted_recipient, check_recipient_access hash:/etc/postfix/recipient-whitelist, check_recipient_access cidr:/etc/postfix/ok-clients, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
participants (4)
-
david rankin -
Per Jessen -
Sandy Drobic -
Theo v. Werkhoven