> > Not the way they are supposed to. Alot of the true localhost activity is
> > getting blocked which shouldn't for starters. Am I missing
> something on the
> > syntax?
>
> You're going to have to ask more specific questions about what you want
> to accomplish, and how it's failing, if we're going to be able to
> help you.
Sometimes logs are available, but more commonly when it doesn't fail and
should there are no logs available that would help. Your {1}{0} explanation
below helped with a couple of the problematic conditions. That leaves me
with this one:
drop message = Security breach $sender_helo_name is one of MY names!
condition = ${lookup{$sender_helo_name}
lsearch{/etc/virtual/domains}{1}{0}}
hosts = ! +whitelist_hosts_ip
Here I want to add to the condition telling it not to be valid if using port
587 like I have on a few others. I have tried this and it is getting a
temporary local problem.
condition = ${if and {{ lookup{$sender_helo_name}
lsearch{/etc/virtual/domains}}{! eq{$interface_port}{587}}}}
My final rule is even tougher. I want to block IP literals that are
pretending to be an IP it is not, with the exception of 192.168.*.* or
90.0.*.*. Why you may ask? It seems the only time that a valid IP literal is
used it contains either [ip of router] or [ip of mach behind firewall]. In
all other cases it is a random [nnn.nnn.nnn.nnn] that has absolutely nothing
to do with the router, its route, or the ISP. These guys using the random
values are the spammers.
So.... if $sender_helo_name is an IP in a [nnn.nnn.nnn.nnn] and ip in the
bracket doesn't equal [$sender_host_address], doesn't equal [192.168.*.*],
and doesn't equal [90.0.*.*] then block it unless it is port 587. Yes this
one is my toughest ones yet and I know it is going to stimulate conversation
regarding the RFCs what to do and what not to do. Of course my $0.02 is; Why
should spammers performing illegal activity be able to use the RFCs for
protection?
> The "condition=" condition expects its parameter to be a boolean string
> (1 or 0, or spelled out as true or false, or yes or no). The $if
> expansion defaults it's final two parameters (the then case and the else
> case) to 1 and 0, but that's fairly new behaviour, so you'll see a lot
> of examples out there with the {1}{0} parameters at the end. You can
> just leave them off in recent versions of exim, I find it simpler to
> read that way. {0}{1} is just a negation of the condition, I find it
> simpler to just use ! to negate the condition.
So in short {1}{0} is default and not needed unless a negate is required and
then {0}{1} is used. Yes I agree that ! is a better option and would make
things much cleaner.
> You should read chapter 11 of the docs:
> http://exim.org/exim-html-current/doc/html/spec_html/ch11.html
I was there once and then couldn't find it again. Thanks for the reference.
Wil
