Re: [sid-milter-discuss] Bug in sid-milters PRA lookup routine?

[Dick St.P. <stp...@ne...>]

fre...@va... writes:

> There seems to be some sort of trouble with the PRA check with
> sid-milter v. 0.2.14 then a person emails us.
> 
> Looking in the logs, I see this:
> 
> Dec 11 10:43:46 mx1 sendmail[4218]: [ID 801593 mail.info]
> kBB9hkBu004218: Milter (sid-filter): init success to negotiate
> Dec 11 10:43:49 mx1 sendmail[4218]: [ID 801593 mail.info]
> kBB9hkBu004218: from=<xxx...@ma...>, size=235422, class=0,
> nrcpts=1, msgid=<200...@mx...>,
> bodytype=8BITMIME, proto=ESMTP, daemon=MTA-v4, relay=mail.maxm.se
> [62.119.138.101]
> Dec 11 10:43:55 mx1 sid-filter[18609]: [ID 337111 mail.error]
> kBB9hkBu004218 ar_waitreply() failed: Too many retries

I was seeing a similar problem with mail involving a particular site,
and it turned out to have nothing to do with sid-milter.

The BIND my sid-milter was querying had happened to choose UDP port
1433 as its source port for its queries.  UDP port 1433 is the ms-sql
service port, and the remote site's firewall was blocking the queries
from my BIND (without sending an ICMP back).

Simply telling my BIND to use a different port for its queries
overcame the problem.

Of course, blocking incoming UDP from port 1433 is a stupid thing for
the remote site to do.  (They might well want to block incoming UDP
*to* UDP port 1433 and/or block *outgoing* UDP from UDP port 1433, to
protect their ms-sql servers.)  Probably someone was simply following
advice to "block port 1433" without understanding why.

BIND picks a query-source port on startup, and always uses that same
source port - at least until BIND is restarted or reloaded with a new
config specifying a different query-source port port.

If you can manually query a site's servers, but your sid-milter
cannot, try changing your BIND's query-source port or specifying a
different nameserver in resolv.conf.

--
Dick St.Peters, stpeters@NetHeaven.com 
Gatekeeper, NetHeaven, Saratoga Springs, NY