detecting successful delivery to reset error count in DB
Hi, I manage a web site that sends price change alerts to subscribers using postfix with VERP to detect failed deliveries. When a bounce comes in it is fed to a perl script (through procmail) which increments the email's error count in the database until that count reaches 4 and the email is disabled. My problem is that sometimes delivery errors are transient (server change, etc.) but the error count is never reset on a successful delivery. What strategy could I use to detect a successful delivery in order to reset the error count? Thanks,
virtual_alias_maps question
Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal?
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:42:07AM +0200, Ralf Hildebrandt wrote: * Louis-David Mitterrand vindex+lists-postfix-us...@apartia.org: Hi, I have a virtual_alias_maps with a pcre entry like /^(info|contact|etc)@/ localuser and it delivers i...@anydomain.com to localuser even though 'anydomain.com' is not in virtual_alias_domains, is that normal? Yes. So I have to write (and maintain) that entry like this? /^(info|contact|etc)@(domain1|domain2|domain3|etc).com$/ localuser Is there a better way?
Re: virtual_alias_maps question
On Thu, Oct 24, 2013 at 10:04:08AM -0500, /dev/rob0 wrote: On Thu, Oct 24, 2013 at 10:00:00AM -0500, /dev/rob0 forgot to terminate a PCRE expression: if /@example\.(com|net|org)$/ /^(info|contact|etc)@ localuser@mydestination.domain endif if /@example\.(com|net|org)$/ /^(info|contact|etc)@/localuser@mydestination.domain endif This is really, really nice. I always forget the power of if/endif in posfix confs. Thanks!
outside mail from double-bounce@ ?
Hi, Why is this accepted e-mail from=double-bounce@ instead of the real sender address? [later] Ah, maybe I understand... Is it a probe postfix sends to verify the recipient (LDM@ in uppercase, which normally is always lowercas)? May 9 10:38:03 zenon postfix/smtpd[26553]: connect from smtp3.airfrance.fr[193.57.218.25] May 9 10:38:03 zenon postfix/smtpd[26553]: setting up TLS connection from smtp3.airfrance.fr[193.57.218.25] May 9 10:38:03 zenon postfix/smtpd[26553]: certificate verification failed for smtp3.airfrance.fr[193.57.218.25]: untrusted issuer /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 May 9 10:38:03 zenon postfix/smtpd[26553]: smtp3.airfrance.fr[193.57.218.25]: Untrusted: subject_CN=smtp1.airfrance.fr, issuer=VeriSign Class 3 Secure Server CA - G3, fingerprint=C6:CA:87:A1:DD:E7:62:02:88:14:C9:DD:16:28:F9:F4 May 9 10:38:03 zenon postfix/smtpd[26553]: Untrusted TLS connection established from smtp3.airfrance.fr[193.57.218.25]: TLSv1 with cipher RC4-SHA (128/128 bits) May 9 10:38:04 zenon postfix/cleanup[26498]: 3653D424A600C: message-id=20110509083804.3653d424a6...@zenon.example.com May 9 10:38:04 zenon postfix/qmgr[28377]: 3653D424A600C: from=double-bou...@zenon.example.com, size=245, nrcpt=1 (queue active) May 9 10:38:04 zenon postfix/local[26499]: 3653D424A600C: to=l...@example.com, relay=local, delay=0.16, delays=0.14/0/0/0.02, dsn=2.0.0, status=deliverable (delivers to command: /usr/bin/procmail -a $EXTENSION) May 9 10:38:04 zenon postfix/qmgr[28377]: 3653D424A600C: removed
Re: UTF8 header matching problem
On Tue, Jul 20, 2010 at 12:29:09PM -0400, Victor Duchovni wrote: On Tue, Jul 20, 2010 at 10:14:01AM +0200, Louis-David Mitterrand wrote: I can't seem to get postfix to match that header: Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?= with this /etc/postfix/header_check entry (PCRE): /^(Subject: =\?UTF-8\?Q\?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249\?=)/ REJECT yet a: postmap -q 'Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?=' /etc/postfix/header_check does match. The subject probably gets RFC2049 (re-)encoded by an MTA between your Postfix server and mailbox server. You need to record the original Subject, perhaps by putting the message on HOLD or otherwise capturing a copy before delivery to other MTAs. The original subject is: Nov 9 13:18:16 zenon postfix/cleanup[11310]: 3384E42508017: warning: header Sub ject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?= from .. and there is no other postfix involved. Does postfix first decode the =?UTF-8? before matching? or did I miss something else? No, Postfix does not decode the subject. Using the _exact_ header displayed by postfix in its header 'warning': ZENON:~# postmap -q 'Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?=' pcre:/etc/postfix/header_access_local REJECT nous savons gérer nos échéances! I get a match from postmap. Yet postfix does not block the message... Why?
transport according to sender (not recipient)?
Hi, Can I select a specific transport depending on the envelope sender?
Re: transport according to sender (not recipient)?
On Thu, Sep 02, 2010 at 08:21:06AM -0400, Wietse Venema wrote: Louis-David Mitterrand: Hi, Can I select a specific transport depending on the envelope sender? No, that would break mail delivery with local recipients. You can have sender-dependent relayhost or default_transport, for mail delivery with non-local recipients. http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps The sender_dependent_relayhost_maps is probably what I need. I tried a sender_dependent_default_transport_maps but it seems overriden by transport_maps, isn't it? My transport_maps looks like this: /^abuse@/ :[example1.host.com] /^sp...@paypal.com/ :[example2.host.com] ... ## using this instead of a relayhost /./ :[main.relay.host.com]:submission
Re: transport according to sender (not recipient)?
On Thu, Sep 02, 2010 at 09:01:44AM -0400, Wietse Venema wrote: Louis-David Mitterrand: On Thu, Sep 02, 2010 at 08:21:06AM -0400, Wietse Venema wrote: Louis-David Mitterrand: Hi, Can I select a specific transport depending on the envelope sender? No, that would break mail delivery with local recipients. You can have sender-dependent relayhost or default_transport, for mail delivery with non-local recipients. http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps The sender_dependent_relayhost_maps is probably what I need. I tried a sender_dependent_default_transport_maps but it seems overriden by transport_maps, isn't it? This may come as a surprise, but Postfix behaves as documented. *gasp* No shit? I guess I had it coming :) But nowhere in the postconf.5.html is it written that tranport_maps overrides sender_dependent_default_transport_maps. I only see the following Note: this overrides default_transport, not transport_maps which is not quite the same.
UTF8 header matching problem
Hi, I can't seem to get postfix to match that header: Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?= with this /etc/postfix/header_check entry (PCRE): /^(Subject: =\?UTF-8\?Q\?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249\?=)/ REJECT yet a: postmap -q 'Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?=' /etc/postfix/header_check does match. Does postfix first decode the =?UTF-8? before matching? or did I miss something else? Thanks, Here are log entries: Jul 20 09:13:47 zenon postfix/smtpd[14052]: AC5BA5B93D146: client=aussmtpmrkps312.us.dell.com[143.166.224.212] Jul 20 09:13:48 zenon postfix/cleanup[14960]: AC5BA5B93D146: message-id=2301567.1279610009277.javamail.ora...@ausgoprdap08.us.dell.com Jul 20 09:13:48 zenon postfix/cleanup[14960]: AC5BA5B93D146: warning: header Subject: =?UTF-8?Q?Vos_Factures_arrivant_a_=C3=A9ch=C3=A9ance_-_FR0905249?= from aussmtpmrkps312.us.dell.com[143.166.224.212]; from=x...@dell.com to=x...@example.com proto=ESMTP helo=aussmtpmrkps312.us.dell.com Jul 20 09:13:48 zenon postfix/cleanup[14960]: AC5BA5B93D146: warning: header Content-Type: application/pdf; ??name=Document_FR_REL_ENTP_9230813_2010-07-20_PR1.pdf from aussmtpmrkps312.us.dell.com[143.166.224.212]; from=x...@dell.com to=x...@example.com proto=ESMTP helo=aussmtpmrkps312.us.dell.com Jul 20 09:13:48 zenon postfix/cleanup[14960]: AC5BA5B93D146: warning: header Content-Disposition: attachment; ??filename=Document_FR_REL_ENTP_9230813_2010-07-20_PR1.pdf from aussmtpmrkps312.us.dell.com[143.166.224.212]; from=x...@dell.com to=x...@example.com proto=ESMTP helo=aussmtpmrkps312.us.dell.com Jul 20 09:13:48 zenon postfix/qmgr[6879]: AC5BA5B93D146: from=x...@dell.com, size=14508, nrcpt=1 (queue active) Jul 20 09:13:48 zenon postfix/local[14971]: AC5BA5B93D146: to=x...@example.com, relay=local, delay=18, delays=18/0/0/0.27, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a $EXTENSION) Jul 20 09:13:48 zenon postfix/qmgr[6879]: AC5BA5B93D146: removed
Re: Stopping spam from a specifig subnet (relayed through a freemail provider)
On Wed, May 05, 2010 at 01:44:54PM -0400, Brian Evans - Postfix List wrote: You could try this in /etc/postfis/header_checks if /^(Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):/ if !/^(X-Original-)?To:[...@]*(africanspamlover1|africanspamlover2|etc..)@/ /\b(41\.1(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 1 /\b(41\.3(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 2 .. and all other rules ... endif endif This will not work. Postfix analyzes headers one at a time. You cannot check multiple headers at once in header_checks. You need a milter or other filter to do that. Could this be entered as a postfix wishlist item then? A 'm' flag to pcre_table that would match on the whole headers (instead of line-by-line), akin to Perl's 'm' regexp flag: m Treat string as multiple lines. That is, change ^ and $ from matching the start or end of the string to matching the start or end of any line anywhere within the string. It would be very powerful, yet retain the ability to match on any individual header line with ^ and $ anchors.
Re: Stopping spam from a specifig subnet (relayed through a freemail provider)
On Thu, May 06, 2010 at 11:15:21AM +0200, Tom Hendrikx wrote: On 06/05/10 10:58, Louis-David Mitterrand wrote: On Wed, May 05, 2010 at 01:44:54PM -0400, Brian Evans - Postfix List wrote: You could try this in /etc/postfis/header_checks if /^(Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):/ if !/^(X-Original-)?To:[...@]*(africanspamlover1|africanspamlover2|etc..)@/ /\b(41\.1(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 1 /\b(41\.3(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 2 .. and all other rules ... endif endif This will not work. Postfix analyzes headers one at a time. You cannot check multiple headers at once in header_checks. You need a milter or other filter to do that. Could this be entered as a postfix wishlist item then? A 'm' flag to pcre_table that would match on the whole headers (instead of line-by-line), akin to Perl's 'm' regexp flag: m Treat string as multiple lines. That is, change ^ and $ from matching the start or end of the string to matching the start or end of any line anywhere within the string. It would be very powerful, yet retain the ability to match on any individual header line with ^ and $ anchors. Hi, I think that postfwd can do all of this already, working as a policy daemon. See http://www.postfwd.org/ No need to complicate postfix any further: it is an MTA, and should concentrate on mail delivery. There is a reason that you can hook up a myriad of external tools into postfix. What is more complicated? Plug yet another policy daemon to one's postfix installation (with all the care and feeding it entails) or add a totally transparent and optional 'm' flag to postfix's pcre_table?
Re: Stopping spam from a specifig subnet (relayed through a freemail provider)
On Wed, May 05, 2010 at 07:00:37PM +0200, Laurent CARON wrote: Hi, I'm basically trying to protect my users from the following: Spam - Sent from accounts hosted on freemail providers (yahoo, ...) - Originating from AfriNIC ranges - Tergetted at several dozen of users The headers look like this: Received: from [41.207.213.162] by web1104.biz.mail.sk1.yahoo.com via HTTP; Tue, 04 May 2010 14:44:20 PDT It is fairly trivial to block suck things via a header access map if /^(Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):/ /\b(41\.\d+\.\d+\.\d+)\b/ REJECT regional junk 001 #Africa endif Some of my users receive a few legitimate emails from Africa. You could try this in /etc/postfis/header_checks if /^(Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):/ if !/^(X-Original-)?To:[...@]*(africanspamlover1|africanspamlover2|etc..)@/ /\b(41\.1(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 1 /\b(41\.3(6\d|7[0-5])\.\d+\.\d+)\b/ REJECT african spam rule 2 .. and all other rules ... endif endif (the indent is purely for clarity. Not sure postfix accepts it.) -- http://www.cruisefish.net
max length of pcre rule?
Hi, I am using an (insanely) long pcre (see below) to reject african/chinese/etc. spam that relays through large ISP's. An now it seems I have reached a limit. When trying to add a single more expression with a set of () parens I get this error: postmap: warning: pcre map /etc/postfix/header_access_local, line 2: too many (...) Is this a limitation (or sanity check) of the pcre engine? My rule is long because I need to share the prefix: Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script) and would rather not edit it more than once each time a new variation of 'X-Originating-IP' appears. Any suggestion on improving the following rule is welcome. Thanks, /^((Received|X-((Origin(ating)?|Client|MDRemote|Sender)-?IP|(Client|Remote_)Addr|PHP-Script)):.+\b((41\.245.\d+|60\.1(6[6-9]|7[0-5])\.\d+|41\.184\.(3[2-9]|4[0-7])|112\.110\.(46|61|9[6-9]|1([01]\d|2[0-7]))|41\.214\.(3[2-9]|4[0-7]|9[6-9])|211\.144\.(6[4-9]|[78]\d|9[0-5])|192\.83\.191|41\.2[78]\.\d+|121\.148\.199|112\.20[0-7]\.\d+|119\.(9[6-9]|10[0-3])\.\d+|117\.(2[4-9]|3[01])\.\d+|123\.16[0-3]\.\d+|222\.8[89]\.\d+|41\.138\.1([678]\d|9[01])|195\.78\.11[23]|61\.54\.\d+|80\.255\.61|213\.255\.1(2[89]|[3-5]\d)|86\.62\.([0-5]?\d|6[0-3])|41.221.194|41\.29\.\d+|218\.1[3-8].\d+|213\.136\.(9[6-9]|1([01]\d|2[0-7]))|202\.112\.([0-2]?\d|3[01])|116\.206\.\d+|120\.14[01]\.\d+|41\.215\.1(6\d|7[0-5])|41\.232\.\d+|88\.208\.206|120\.(9[6-9]|1([01]\d|2[0-7]))\.\d+|165\.146\.([1-5]?\d|6[0-3])|212\.52\.1(2[89]|[34][0-9]|5[0-9])|202\.96\.1(2[89]|[3-8]\d|9[01])|114\.12[0-7]\.\d+|189\.127\.143|86\.96\.2(2[6-9]|3\d)|41\.222\.19[2-5]|41\.203\.(6[4-9]|[78]\d|9[0-5]|2(2[4-9]|3[0-9]))|174\.143\.\d+|62\.56\.(1(2[8-9]|[3-9]\d)|2([0-4]\d|5[0-5]))|115\.13[2-5]\.\d+|196\.46\.24[0-7]|196\.220\.1[0-4]|41\.31\.\d+|61\.134\.0|80\.89\.1(7[6-9]|8\d|9[01])|213\.209\.162|217\.20\.8[0-6]|74\.220\.(19[2-9]|2([01]\d|2[0-3]))|41\.19\.\d+|81\.199\.\d+|217\.21\.(6[4-9]|[78]\d|9[0-5])|89\.248\.194|58\.(4[89]|5[0-5])\.\d+|77\.211\.(6[4-9]|[7-9]\d|[12]\d\d)|196\.3\.1(6[4-9]|7\d|8[13])|41.191.1(0[89]|1[01])|220\.22[4-7]\.\d+|41\.218\.(19[2-9]|2([0-4]\d|5[0-5]))|41\.219\.(1(2[89]|[3-8]\d|9[016])|24[24])|41\.26\.\d+|121\.([89]|1[0-5])\.\d+|61\.18[34]\.\d+|41.184.(1[6-9]|2\d|3[01])|83\.234\.72|203\.79\.224|41\.205\.1(6[57]|72)|81\.202\.\d+|41\.223\.2(48|51)|41\.191\.(6[89]|7[01]|8[4-7])|212\.116\.2(1[5-9]|2[0-3])|196\.28\.2(4\d|5[0-2])|213\.152\.(6[4-9]|[78]\d|9[0-5])|124\.23[6-9]\.\d+|41\.25[2-5]\.\d+|61\.135\.\d+|41\.1(6\d|7[0-5])\.\d+|196\.207\.254|193\.227\.(3[2-9]|[45]\d|6[0-3])|41\.30\.\d+|41\.217\.([1-9]?\d|1([01]\d|2[0-7]))|212.100.(6[4-9]|[78]\d|9[0-5])|222\.16[0-3]\.\d+|212\.92\.(19[2-9]|2([01]\d|2[0-3]))|87\.126\.(19[2-9]|2([0-4]\d|5[0-5]))|95\.1[67]\.\d+|77\.70\.12[89]|41\.220\.(75|1(7[6-9]|8\d|9[01]))|78\.138\.3|218\.2[89]\.\d+|219\.23[67]\.\d+|41\.204\.2(2[4-7]|[34]\d|5[0-5])|121\.121\.\d+|123\.(6[4-9]|[78]\d|9[0-5])\.\d+|58\.2(0[89]|1\d|2[0-3])\.\d+|219\.15[23]\.\d+|219\.151\.(1(2[89]|[3-9]\d)|2([0-4]\d|5[0-5]))|72\.9\.(9[6-9]|1(0[0-9]|1[01]))|220\.249\.1([6-8]\d|9[01])|60\.2(0[89]1[0-7]|).\d+|41.218.(19[2-9]|2([01]\d|2[0-3]))|124\.122\.(1(2[89]|[3-9]\d)|2([0-4]\d|5[0-4]))|196\.1\.17[6-9]|41\.208\.(1(2[89]|[3-9]\d)|2(0[0-7]))|82\.151\.131|196\.207\.218|207\.235\.61|123.5[2-5].\d+|124\.120\.1(2[89]|[3-8]\d|9[01])|41\.213\.(\d?\d|1([01]\d|2[0-7]))|82\.128\.(\d?\d|1([01]\d|2[0-7]))|121\.245\.116|41\.211\.([0-3]|19[2-9]|2([0-4]\d|5[0-5]))|81\.91\.2(2[4-9]|3[0-9])|41\.189\.([1-3]?\d|4[0237]|5[0-6]|9[6-9]|1([01]\d|2[0-7]))|41\.202\.\d+|41\.207\.([0-9]|1[5-9]|2[0-9]|3[01]|1([6-9]\d)|2([01]\d|2[0-3]))|196\.201\.(64|72|8[34])|41\.216\.(3[2-9]|[45]\d|6[0-3]))\.\d+|83\.229\.87\.24[0-7]|83\.229\.48\.1(4[4-9]|5[01]))\b)/ REJECT aviso.ci junk 2
Re: max length of pcre rule?
On Mon, Mar 29, 2010 at 04:38:17PM +0200, Steve wrote: Ohhh boy. Now looking at the regexp I see an error. Every line starting with /[^:]*.+ should be replaced by /[^:]*:.+. Sorry for that. Hi Steve, You if/endif suggestion for the prefix is interesting. For added safety, the individual rules should be anchored with ^ and the bracketed atom plussed, no? /^[^:]+:.+ Thanks,
Re: max length of pcre rule?
On Mon, Mar 29, 2010 at 04:55:19PM +0200, Steve wrote: You if/endif suggestion for the prefix is interesting. For added safety, the individual rules should be anchored with ^ and the bracketed atom plussed, no? /^[^:]+:.+ Yes. You are right. But to be honest this should be enough (just an example): 001) if /^Received|X\-((Origin(ating)?|Client|MDRemote|Sender)\-?IP|(Client|Remote_)Addr|PHP\-Script):/ 002) /\b(127\.0.\d+\.\d+)\b/ REJECT aviso.ci junk 2 003) endif * Rule 001 will match a specific header. * Rule 002 will match 127.0.xxx.xxx * 127.0.xxx.xxx could be anchored with ^ but the rule/if-condition in 001 is already taking care of that 127.0.xxx.xxx is not part of the header name. So you can shorten the regexp to just /\b(ip you check/rule)/b REJECT blah-blah-blah Indeed, on second thought the anchoring is useless in individual rules, making it much more readable/managable. Thanks for taking to time to de-parse my giga-rule into its component parts!
Re: max length of pcre rule?
On Mon, Mar 29, 2010 at 05:16:39PM +0200, Steve wrote: Ach. Again. I made errors. Sorry. It's hard to write here in such a small edit box in a web interface. The above is not 100% correct. What I wanted to write is: You need the 'itsalltext' firefox extension to edit any web textarea with your $EDITOR. https://addons.mozilla.org/en-US/firefox/addon/4125 -- /\b(41\.26\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 /\b(41\.29\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 /\b(41\.2[78]\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 /\b(41\.30\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 /\b(41\.31\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 Could be shortened to: /\b(41\.(2[6-9]|3[01])\.\d+\.\d+)\b/ REJECT aviso.ci junk 2 -- And of course your line-by-line rules makes it so much easier to sort, and regroup, them. Cheers,
matching IP ranges in headers
Hi, A lot of spam comes from certain ip ranges (e.g. west africa) through relays (large ISPs) that would be too onerous to block. To filter these I am presently matching: /^((Received|X-Originating-IP):.+\b(124\.120\.1\.(IP RANGE IN REGEX)\b/ in pcre:/etc/postfix/header_access. But converting IP ranges to regex'es is time consuming and error prone. Is there a way to use a cidr table for header matching while retaining control of the prefix ^(Received|X-Originating-IP) ? Or another better way? Thanks,
auto-whitelist outgoing addresses?
Hi,
I'd like to implement an automatic whitelisting of outgoing addresses
(people I write to should be able to pass my heavy spam filter).
For a year I've been testing a minimal, proof-of-concept, whitelisting
script (see below) but haven't maintained or improved it. What I'd like
ideally is have per-user whitelists.
Is there already a serious solution out there? or should I keep
developping my script?
Thanks
#!/usr/bin/perl
use strict;
use Sys::Syslog qw(:DEFAULT setlogsock);
my $syslog_priority = info;
setlogsock(unix);
openlog($0, pid, mail);
my @block = do { local $/ = \n\n; split(\n, STDIN); };
my %attr = map {/^(.+)=(.*)/} @block;
my $recipient = $attr{recipient};
if (open(WHITELIST, + /tmp/whitelist) seek(WHITELIST,0,0)) {
if (!grep (/$recipient/, WHITELIST)) {
print WHITELIST /^.$recipient.\$/ OK ## sender:
$attr{sender},
client: $attr{client_address}\n;
close(WHITELIST);
syslog($syslog_priority, WHITELISTED: $recipient);
} else {
syslog($syslog_priority, NOT WHITELISTED: $recipient);
}
} else {
syslog('error', WHITELISTING ERROR: .$@);
}
print STDOUT action=dunno\n\n;
--
http://www.lesculturelles.net
