Re: [exim] Help with exim acls

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: sysadmin
Dátum:  
Címzett: exim-users
CC: W B Hacker
Tárgy: Re: [exim] Help with exim acls
thanks for tips,

I will change acls and test them

Regards,

Marlon


Em Ter 11 Jul 2006 22:32, W B Hacker escreveu:
> sysadmin wrote:
> > Hi,
> >
> > I try to follow your recomendation, and setup some acls from
> > http://www.tldp.org/HOWTO/text/Spam-Filtering-for-MX
>
> The configuration cited incorpates a number of novel concepts that require
> very consistent integration and may not all be appropriate in your
> environment.
>
> Take these, or any other 'borrowed' configuration settings as examples, not
> gospel, until you have tested them, gained a better understanding of what
> the interactions are, and modifed them to work apropriately with other
> parts of your configuration.
>
> > With new acls , I can't receive mail from external hosts:
> >
> > Jul 11 20:16:36 scadufax exim[21272]: 2006-07-11 20:16:36 SMTP connection
> > from [200.195.199.2]:56212 I=[10.0.0.151]:25 (TCP/IP connection count =
> > 1) Jul 11 20:16:37 scadufax exim[21916]: 2006-07-11 20:16:37
> > H=ns2.onda.com.br (maresia.onda.com.br) [200.195.199.2]:56212
> > I=[10.0.0.151]:25 Warning: remote host presented unverifiable HELO/EHLO
> > greeting.
> > Jul 11 20:16:58 scadufax exim[21947]: 2006-07-11 20:16:58
> > cwd=/var/spool/mqueue 2 args: /usr/sbin/exim -q
> > Jul 11 20:16:58 scadufax exim[21947]: 2006-07-11 20:16:58 Start queue
> > run: pid=21947
> > Jul 11 20:16:58 scadufax exim[21947]: 2006-07-11 20:16:58 End queue run:
> > pid=21947
> > Jul 11 20:17:17 scadufax exim[21916]: 2006-07-11 20:17:17
> > H=ns2.onda.com.br (maresia.onda.com.br) [200.195.199.2]:56212
> > I=[10.0.0.151]:25
> > F=<marlon@???> rejected RCPT <marlon@???>
>
> Find that 'deny' verb and change it to a warn temporarily.
>
> What helps for finding and editing these fast is to add:
>
> - a acl ID or number to the comments of each acl set
>
> BOTH
>
> - a logwrite = <acl ID> <action>
>
> - a log_message = <acl ID> <whatever else you need>
>
> This will give you a lot more log entries than you will want to keep active
> once in production, but will make it much easier to ID:
>
> - which acl is being traversed (at all), because a 'logwrite' can be
> unconditional.
>
> - if it has 'activated', because a log_message can be conditional.
>
> (pay attention to the order in which they are placed within the acl!)
>
> When you edit, you can rapidly search on the coomented ID you have
> assigned: (CONNECT_3, RECPT_4, DATA_2) to jump directly to the specific acl
> code you wish to examine/modify.
>
> *snip*
>
> Example:
>
>      # RECPT_N  added for unique identification

>
> > # Deny if we have previously given a reason for doing so in $acl_m0.
> > # Also stall the sender for another 20s first.
> > #
> > deny
>
>       logwite   = RECPT_N deny on prior flag

>
> >    message     = $acl_m0
> >    log_message = RECPT_N $acl_m1
> >    condition   = ${if and {{def:acl_m0}{def:acl_m1}} {true}}
> >    delay       = 20s

>
> *snip*
>
> FWIW, HELO/EHLO very often do not have an exact match to anything in a DNS,
> and the gadzillions of domains using NetSol mail hosting *never* will - so
> a 'hard' deny is not a good idea on that basis alone.
>
> A delay (only) of 60 seconds or so, however, will cause many such that are
> zombies to abandon the connection. 20s seldom works as well as 30s or more.
>
> HTH,
>
> Bill