Prev: Milter rejecting far too many emails
Next: O Poder do DOIS: Uma rota simples ao Sucesso... Responda para você mesmo essas perguntas: Você pode adquirir um Pacote Standard por mês por US$20 dólares? Você pode afiliar todos os meses DUAS pessoas que façam o mesmo que VOCÊ? BEM... Se você foc
From: ait on 19 Jan 2010 09:05
On Jan 19, 4:53 pm, ait <ait.mei...(a)gmail.com> wrote:
> On Jan 19, 2:05 pm, Andrzej Adam Filip <a...(a)onet.eu> wrote:
>
>
>
> > ait <ait.mei...(a)gmail.com> wrote:
> > > On Jan 18, 4:15 pm, Andrzej Adam Filip <a...(a)onet.eu> wrote:
> > >> ait <ait.mei...(a)gmail.com> wrote:
> > >> > Is it possible to put custom Local_check_relay rules before dnsbl
> > >> > checks?
>
> > >> > For example, I've created 'SLocal_check_relay' rules (checking for the
> > >> > regex match on words like "ppp, adsl, dialup", etc.), but it looks
> > >> > like dnsbl checks are being performed before my rule.
> > >> > It would be much better to have my regex checks occure before DNS
> > >> > lookup in blacklists, thus reducing excessive connections.
>
> > >> FEATURE(`enhdnsbl') [ cf/feature/enhdnsbl.m4 file ] uses divert(8) to
> > >> put its R lines in right place of sendmail.cf. You can use divert(8) in
> > >> sendmail.mc before any FEATURE(`enhdnsbl') to consult
> > >> Local_check_relay rule set before later enhdnsbl checks
> > >> or insert your own R lines.
>
> > >> sendmail.mc:
>
> > >> divert(8)
> > >> # put your checks/rule set consulting here
> > >> divert(-1)
>
> > > Thanks so much for your help, Andrzej!
>
> > > Looks like it worked, but anyway the behavior of checks is really odd..
>
> > > For example, I can see a spam connection from a node
> > > 219.64.195.35.static-pune.vsnl.net.in.
> > > Ok, it gets rejected on ruleset=check_rcpt (I have feature
> > > delay_checks enabled) by dnsbl feature:  ...SPAM from 219.64.195.35
> > > blocked...
>
> > > But actually it should have been rejected by my regex check:
>
> > > divert(8)
> > > LOCAL_CONFIG
> > > Kcheckhost      regex -a(a)MATCH -f (static|ppp|dynamic|cable|broadband)
>
> > > LOCAL_RULESETS
> > > SLocal_check_rcpt
> > > R$*             $: $&{client_name}
> > > R$*             $: $(checkhost $1 $)
> > > R(a)MATCH    $#error $@ 5.7.1 $: "550 Access denied"
>
> > > divert(-1)
> > > ...
> > > [...]
>
> > 1) -a flag of regexp means "append tag on successful match"
> > It is not "replace on match" as you interpreted. Try
>
> > R$*@MATCH    $#error $@ 5.7.1 $: "550 Access denied"
> > R$*          $: OKSOFAR
>
> Ok, got it. I wonder how the hell it worked before, assuming that my
> tag was always appended? :)
>
> > 2) *For rejecting* you may consider using $&{client_ptr}
> > (sendmail-8.13.0+) instead of $&{client_name}.
>
> > client_name requires "closed loop of PTR->A DNS records".
> > client_ptr reports "PTR lookup" only.
>
> Sounds reasonable. Thanks! ;)
>
> > P.S.
> > A) I would not use such rules as you try myself, but feel free to
> >    try/search :-)
>
> It's kinda sinister to get such advice from _you_. :) Can you please
> explain what's the problem with these rules?
>
> Actually this regex check and dnsbl checks are doing a good job on our
> mx, keeping the spam amount at a very low level. And the actual
> regular expression is much longer than I provided as an example. B)
>
> > B) Do you use MIMEDEfang milter for AS and AV checks?
>
> Nope. We have found out that aforementioned checks are enough for our
> requirements. The load on the mx is not very high.



BTW, just in case anyone else will ever read it, please do note:

I also needed to have SMTP AUTH enabled, so I figured that I should
use SLocal_check_relay and not SLocal_check_rcpt.
Otherwise authenticated hosts will be rejected by regex check anyway.
I believe that's beacuse of delay_checks.


From: Andrzej Adam Filip on 19 Jan 2010 14:59
ait <ait.meijin(a)gmail.com> wrote:
> On Jan 19, 2:05 pm, Andrzej Adam Filip <a...(a)onet.eu> wrote:
>> [...]
>> P.S.
>> A) I would not use such rules as you try myself, but feel free to
>> try/search :-)
>
> It's kinda sinister to get such advice from _you_. :) Can you please
> explain what's the problem with these rules?
>
> Actually this regex check and dnsbl checks are doing a good job on our
> mx, keeping the spam amount at a very low level. And the actual
> regular expression is much longer than I provided as an example. B)

I would expect unacceptable level of false positives on system
"I am concentrated on" but it may be perfectly OK for "family server",
small ISP or even some medium ISP.
BTW I hope to be "usually right", I do not expect to be always right ;-)

I usually prefer to block giving DNSBL link in reject message as it
lowers number of "support requests" (unless you run BIG ISP) and
it does make sense at least in "legal culture" I live in.
Your mileage may vary - I have seen reasoning from "another legal
culture" why to carefully avoid providing exact reason for blocking.

>> B) Do you use MIMEDEfang milter for AS and AV checks?
>>
> Nope. We have found out that aforementioned checks are enough for our
> requirements. The load on the mx is not very high.

For postmasters using MIMEDefang anyway for AV&AS checks implementing
"checks like yours" (based on revDNS) would be simpler in MIMEDefang (IMHO).

--
[pl>en Andrew] Andrzej Adam Filip : anfi(a)onet.eu : Andrzej.Filip(a)gmail.com
"Whoever undertakes to set himself up as a judge of Truth and Knowledge is
shipwrecked by the laughter of the gods."
-- Albert Einstein
From: D. Stussy on 19 Jan 2010 20:21
"ait" <ait.meijin(a)gmail.com> wrote in message
news:b7fb8ad3-fcda-4890-b402-22a9436249c1(a)30g2000yqu.googlegroups.com...
>divert(8)
>LOCAL_CONFIG
>Kcheckhost regex -a(a)MATCH -f (static|ppp|dynamic|cable|broadband)
>...

You choose to reject static assignments too? That is unusual.

I realize that you're really targeting those sites with static assignments
that never changed the dummy rDNS entry that the provider may have put into
DNS before or in place of the client's choice.

Note that your choice to use a regex map instead of a class map could lead
to false rejections. I use:

C{Dialup} ADSL Cable catv dynamic ppp ....

R$* $={Dialup} $* $#error ...

So, what's the difference? Using the class map ensures that via the M4
parsing, only substrings bracketed by periods will match (e.g. ".cable.").
A regex will match anything that contains (any of) the string(s) specified
in it.

Yours would match: cablecarmuseum.sf.ca.us
Mine would not.

Chances are that you want to target only CATV providers, not other uses of
"cable".


From: ait on 20 Jan 2010 00:55
On Jan 19, 10:59 pm, Andrzej Adam Filip <a...(a)onet.eu> wrote:
> ait <ait.mei...(a)gmail.com> wrote:
> > On Jan 19, 2:05 pm, Andrzej Adam Filip <a...(a)onet.eu> wrote:
> >> [...]
> >> P.S.
> >> A) I would not use such rules as you try myself, but feel free to
> >>    try/search :-)
>
> > It's kinda sinister to get such advice from _you_. :) Can you please
> > explain what's the problem with these rules?
>
> > Actually this regex check and dnsbl checks are doing a good job on our
> > mx, keeping the spam amount at a very low level. And the actual
> > regular expression is much longer than I provided as an example. B)
>
> I would expect unacceptable level of false positives on system
> "I am concentrated on" but it may be perfectly OK for "family server",
> small ISP or even some medium ISP.
> BTW I hope to be "usually right", I do not expect to be always right ;-)

I see, but due to specific area of semi-constant message sources, the
level of false positives is almost 0, which is rather acceptable for
us. ;) Dunno how to classify our service, the load is about 3-20
thousands msgs/day, with average load about 7000.

> I usually prefer to block giving DNSBL link in reject message as it
> lowers number of "support requests" (unless you run BIG ISP) and
> it does make sense  at least  in "legal culture" I live in.
> Your mileage may vary - I have seen reasoning from "another legal
> culture" why to carefully avoid providing  exact reason for blocking.

That's a good point to cut out such information in spite of blacklist
recommendations. We have experienced a massive DDoS attack on our mx,
which was actually pointed to cause DNS overload. I'm pretty sure that
those evildoers were able to figure out that we were using dnsbl
checks, basing on our mx reject replies with abundant dnsbl
information.


> >> B) Do you use MIMEDEfang milter for AS and AV checks?
>
> > Nope. We have found out that aforementioned checks are enough for our
> > requirements. The load on the mx is not very high.
>
> For postmasters using MIMEDefang anyway for AV&AS checks implementing
> "checks like yours" (based on revDNS) would be simpler in MIMEDefang (IMHO).

Will dig into this, thanks.


From: Ole Hansen on 10 Feb 2010 15:48
On 19-Jan-10 06:05, Andrzej Adam Filip wrote:
> ait<ait.meijin(a)gmail.com> wrote:
>> Kcheckhost regex -a(a)MATCH -f (static|ppp|dynamic|cable|broadband)
>>
>
> 1) -a flag of regexp means "append tag on successful match"
> It is not "replace on match" as you interpreted.
>

For the record, I believe that in this case -a _does_ effectively mean
"replace on match". By default, the map lookups _replace_ the key with
the value. With the regex map, the "value" seems to be an empty string.
(You can infer this from reading the relevant chapter in the sendmail
book closely, though it is not very clear by any means.) The end effect
is that, with regex, -a appends the tag to an empty string, which is of
course the same as replacing. You can check with a simple test rule. If
you really do want to _append_ something to a regex match, you also need
to use -m.

> R$*@MATCH $#error $@ 5.7.1 $: "550 Access denied"

Of course, both R$*@MATCH and R(a)MATCH match @MATCH, so the rule will
work either way.

Ole
First  |  Prev  | 
Pages: 1 2
Prev: Milter rejecting far too many emails
Next: O Poder do DOIS: Uma rota simples ao Sucesso... Responda para você mesmo essas perguntas: Você pode adquirir um Pacote Standard por mês por US$20 dólares? Você pode afiliar todos os meses DUAS pessoas que façam o mesmo que VOCÊ? BEM... Se você foc