[GLLUG] sendmail puzzle
Marco van Beek
mvanbeek at supporting-role.co.uk
Tue Oct 11 07:33:55 UTC 2022
Hi,
It might be the difference between a missing entry in a zone file, and a
missing zone file. Maybe it is the lookup mechanism that fails, rather
than it checking the IP address itself. It might be another rule set
that is trying to do a reverse lookup (eg hostname), and it barfs out at
that point.
Maybe increase the logging verbosity and check the logs again?
Cheers,
Marco
On 10/10/2022 22:54, Ken Smith via GLLUG wrote:
>
> I'm trying to sort out a Rocky 8.5 server that has sendmail installed.
> (Please don't go on a diversion about how I should tell the owner to
> dump sendmail and switch to exim or postfix - save that for another
> thread please. )
>
> I'm pretty good with sendmail but this problem has me a bit foxed. I'd
> value some suggestions of where to look as I think I'm not seeing the
> wood for the trees.
>
> It will send from addresses in the local network, without auth,
> because I have "connect:192.168.123 relay" in the access file - that
> being the local LAN.
>
> I've tested sasl auth and that is authenticating.
>
> Using telnet from an IP off their LAN (over a VPN) I can connect using
> TLS (openssl s_client etc etc) and authenticate (perl -MMIME::Base64
> etc etc) it accepts my credentials and then if I try to send a
> message I get "Relaying denied. IP name lookup failed [my local ip]"
> The same happens with a test using Thunderbird.
>
> If I do the same test from the host that sendmail is on, it works fine.
>
> Also if I do the same test from another host on the same LAN it works
> fine.
>
> Somehow its complaining about the source IP in authenticated sessions
> outside the LAN range.
>
> In the test from my local LAN (172.16.0.x), over a VPN, the remote dns
> can't resolve the reverse dns of my LAN. I've done a similar test with
> another sendmail site and remote auth is working fine.
>
> Maybe sendmail is doing reverse DNS when it shouldn't be.
>
> Suggestions most welcome....
>
> Thanks
>
> Ken
>
>
>
>
More information about the GLLUG
mailing list