I'm going to check two headers (which I have always in my emails) content by rulesets:
HX-Spam-Status: $>ruleset1 HSubject: $>ruleset2
Sruleset1 ROK $* ....... ?!
Sruleset2 RSPAM $#error $: 553 rejected spam mail
The second rule result must depend of first rule result. I'd like ruleset2 reject email only if ruleset1 is matched. How Can I arrange these 2 rulesets together ? Can I define, for example, a temporary variable to store ruleset1 result so I can test it in ruleset2 ?
> Can I define, for example, a temporary variable to store ruleset1 > result so I can test it in ruleset2 ?
I believe it is possible to define a macro that is valid for the (processing) lifetime of the message across multiple rule sets. But I have no idea how to go about doing it.
Naturally your second rule would have to test the contents of the new macro as part of its condition.
>The second rule result must depend of first rule result. >I'd like ruleset2 reject email only if ruleset1 is matched. >How Can I arrange these 2 rulesets together ? >Can I define, for example, a temporary variable to store ruleset1 >result so I can test it in ruleset2 ?
Yes, check out the 'macro' map in doc/op/op.*. There is also an example of usage in cf/cf/knecht.mc. Just remember that the order of headers in an e-mail message is undefined (except for Received: headers), and that the header rulesets are processed in the order the headers appear in the message.
I.e. for robust operation, you probably need to handle either order of invocation of the two rulesets. A good idea can be to just set macros in the two header rulesets, and have the actual logic in the check_eoh ruleset.
> >The second rule result must depend of first rule result. > >I'd like ruleset2 reject email only if ruleset1 is matched. > >How Can I arrange these 2 rulesets together ? > >Can I define, for example, a temporaryvariableto store ruleset1 > >result so I can test it in ruleset2 ?
> Yes, check out the 'macro' map in doc/op/op.*. There is also an example > of usage in cf/cf/knecht.mc. Just remember that the order of headers in > an e-mail message is undefined (except for Received: headers), and that > the header rulesets are processed in the order the headers appear in the > message.
> I.e. for robust operation, you probably need to handle either order of > invocation of the two rulesets. A good idea can be to justsetmacros in > the two header rulesets, and have the actual logic in the check_eohruleset.
>> Yes, check out the 'macro' map in doc/op/op.*. There is also an example >> of usage in cf/cf/knecht.mc. Just remember that the order of headers in >> an e-mail message is undefined (except for Received: headers), and that >> the header rulesets are processed in the order the headers appear in the >> message.
>> I.e. for robust operation, you probably need to handle either order of >> invocation of the two rulesets. A good idea can be to justsetmacros in >> the two header rulesets, and have the actual logic in the check_eohruleset. >Can you highlight "example of defining macro inside ruleset" in cf/cf/ >knecht.mc file, please ?
If you had read up on the basics of sendmail maps, and the specifics of the 'macro' map, in doc/op/op.*, it would be trivial to find - and if you haven't, you'll likely not be able to make use of the example. But anyway, here are some relevant snippets...
LOCAL_RULESETS
HMessage-Id: $>CheckMessageId
SCheckMessageId # Record the presence of the header R$* $: $(storage {MessageIdCheck} $@ OK $) $1
LOCAL_CONFIG Kstorage macro
LOCAL_RULESETS
Scheck_eoh # Check if a Message-Id was found R$* $: < $&{MessageIdCheck} >
Dec 15 14:50:59 mail sendmail[8751]: mBF9oxvp008751: syslog:Rec0:<from[138.88.3.196] by.apache.anrb.ru.with.ESMTP.id.mBF9WrfP006924.for<parad...@anrb.ru>;Mon, 15.Dec.2008.14:33:02+0500> Dec 15 14:50:59 mail sendmail[8751]: mBF9oxvp008751: syslog:Rec1:<from[138.88.3.196](pool-138-88-3-196.res.east.verizon.net [138.88.3.196])by.apache.anrb.ru(8.13.8/8.13.8) with.ESMTP.id.mBF9WrfP006924.for<parad...@anrb.ru>;Mon,15.Dec. 2008.14:33:02+0500>
Dec 15 14:50:42 mail sendmail[8607]: mBF9ocfM008607: syslog:Rec0:<; 15.Dec.2008.09:44:16.-0000> Dec 15 14:50:42 mail sendmail[8607]: mBF9ocfM008607: syslog:Rec1:<(qmail.46011.invoked.by.uid.60001);15.Dec. 2008.09:44:16.-0000>