W B Hacker wrote:
> Wakko Warner wrote:
> >> Second, I *think* you will need to split that into two separate SQL
> >> calls. ELSE simplify. See below.
> >
> > That was 2 seperate SQL statements.
> >
>
> ACK - what I meant was each on their own 'condition = ' call.
> (which a router may not be happy with anyway ...)
If a router could handle multiple condition lines, it would have made it
much simpler.
> >>> The entire ${lookup is not supposed to return anything.
> >>>
>
> One begs to ask why use it, then ..
The act of the lookup is what I wanted. Using non-select sql lookups either
results in a true or false condition. I only need to query to be performed.
The result is meaningless. The router itself is also meaningless.
I'm sure that as long as the condition is false, it'll skip and I don't need
the unseen, but incase for some odd reason it does, unseen shouldn't kill
the message since the router would have dumped it to null anyway.
> > Would be nice if there was a "null" router available. I plan on adding
> > another "null" router to gather data for several others (and yes, I know
> > that exim caches queries)
>
> In the practical sense, any router that does not call a 'viable'
> transport IS a 'null' router, though blackholing or specifically
> transporting to /dev/null OR using an 'unseen' (that works) to reach a
> router that is not 'null' may be considerably kinder to your queue AND
> NOT generate DFB's
My router used to be an accept router with a devnull transport. I wanted to
remove that so I went with a redirect. The original one has not had any
problems.
> One might may or may not want suhc a router to verify. Or might want to
> use the DB to verify instead of a router-walk at all.
It's configured for no verification, expn, or address testing.
> BTW - speaking of DFB's - if you want your sender_verify probes to be
> 'handled' correctly, it may help to make their calls in such a manner as
> to not appear to be originating on a zombified WinBox whose rDNS doesn't
> match anything you have published in *your* DNS.
Can't, I don't have a choice. Embarq will not set rDNS for static users.
The generic test for dynamic IPs doesn't always work. embarq uses
.dyn.embarqhsd.net for dynamic, and .sta.embarqhsd.net for static. I've
already asked them about it.
> Check your logs for my attempt to honor your request to be 'CC'ed...
I did with the first email:
2008-02-29 13:27:41 H=conducive.net (conducive.org) [203.194.153.81]
I=[192.168.2.7]:25 sender verify fail for <wbh@???>: response to
"initial connection" from mx.conducive.org [203.194.153.81] was:
550-\n550-Sender tn-76-7-162-186.sta.embarqhsd.net blacklisted for
abuse\n550 Reasons at:
http://conducive.net/rejection.html
That aside, I like CCs because it places the reply in my "personal" view.
Sometimes in mailing list view, I miss the reply.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???
