While having this configuration
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" zen.spamhaus.org"', `t', `127.0.0.3.',`127.0.0.4.')dnl
I still got this in the logs
Sep 17 15:45:09 sendmail[125009]: STARTTLS=server, relay=122-151-202-217.sta.wbroadband.net.au [122.151.202.217], version=TLSv1.2, verify=NO, cipher=ECDHE-RSA-AES256-GCM-SHA384,
bits=256/256
Sep 17 15:45:17 sendmail[125009]: 38HDj8TH125009: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure:
checkpass failed, user=xxxxxxxx,
relay=122-151-202-217.sta.wbroadband.net.au [122.151.202.217]
Sep 17 15:45:18 sendmail[125009]: 38HDj8TH125009: 122-151-202-217.sta.wbroadband.net.au [122.151.202.217] did not issue MAIL/EXPN/VRFY/ETRN during connection to TLSMTA
At first I thought maybe zen.spamhaus.org was not returning anything
because of some error, but when doing a tcpdump on this mail server I
saw a dns request/answer at 15:45:08.
Maybe this is some trick using timeouts or so?
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" zen.spamhaus.org"', `t', `127.0.0.3.',`127.0.0.4.')dnl
Any ideas what is going on? Should I start changing timeouts?
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr} >>> " zen.spamhaus.org"', `t', `127.0.0.3.',`127.0.0.4.')dnl
Any ideas what is going on? Should I start changing timeouts?
Do you use FEATURE(delay_checks)?
Do you use FEATURE(delay_checks)?
no that is commented out
Do you use FEATURE(delay_checks)?
no that is commented out
How?
Please quote the entry from your mc file and
and show the output of
grep '^Scheck_' YOUR.cf.file
[@mail]# cat sendmail.mc | grep 'delay'
Do you use FEATURE(delay_checks)?
no that is commented out
How?
Please quote the entry from your mc file and
and show the output of
grep '^Scheck_' YOUR.cf.file
dnl FEATURE(delay_checks)dnl
dnl FEATURE(`ratecontrol', `nodelay',`terminate')dnl
dnl FEATURE(`conncontrol', `nodelay',`terminate')dnl
[@mail]# grep '^Scheck_' sendmail.cf
Scheck_relay
Scheck_mail
Scheck_rcpt
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" zen.spamhaus.org"', `t', `127.0.0.3.',`127.0.0.4.')dnl
Sep 17 15:45:09 sendmail[125009]: STARTTLS=server, relay=122-151-202-217.sta.wbroadband.net.au [122.151.202.217],
At first I thought maybe zen.spamhaus.org was not returning anything
because of some error, but when doing a tcpdump on this mail server I
saw a dns request/answer at 15:45:08.
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" zen.spamhaus.org"', `t', `127.0.0.3.',`127.0.0.4.')dnl
Sep 17 15:45:09 sendmail[125009]: STARTTLS=server,
relay=122-151-202-217.sta.wbroadband.net.au [122.151.202.217],
Does the blocking work sometimes, never, ... ?
Some "libraries" mess around with DNS lookups and return bogus
results in case of timeouts etc - do you have one of those
systems (systemd and "weird" lookup mechanisms)?
At first I thought maybe zen.spamhaus.org was not returning anything
because of some error, but when doing a tcpdump on this mail server I
saw a dns request/answer at 15:45:08.
That could have been the lookup of the hostname for the client IP
done by sendmail.
I am wondering if there is a relationship between this waiting of the
client issuing more smtp commands and sendmail 'flushing' the dnsbl
lookup. Or maybe it flushes when STARTTLS is requested?
None wrote:
I am wondering if there is a relationship between this waiting of the
client issuing more smtp commands and sendmail 'flushing' the dnsbl
lookup. Or maybe it flushes when STARTTLS is requested?
The DNSBL lookups are done before a process to accept the connection
is started and the result of the check_relay ruleset is passed
to the "smtp" process.
So the only way this can "fail" is if something goes wrong with
the DNS lookup.
As mentioned some "DNS" lookup code in C libraries is broken
returning bogus results.
You could turn on some debugging (-D /tmp/dns.log -d38.40)
or increase the LogLevel to at least 10
to get more info about lookups done via a "dns" map.
That is probably the best way to track down the problem.
What about if multiple A records are returned by spamhaus? This is with
None wrote:
What about if multiple A records are returned by spamhaus? This is with
Good find!
Add '-z -Z9' to the K line:
Kednsbl dns -R A -a. -T<TMP> -r5 -z -Z9
(note there are two spaces after "-z"!)
and try again.
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" SPAM (zen.spamhaus.org)"', `t', `127.0.0.3.',`127.0.0.4.')dnl
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}
" SPAM (zen.spamhaus.org)"', `t', `127.0.0.3.',`127.0.0.4.')dnl
Unfortunately this requires many more changes...
First: remove the trailing dot for each IP:
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"554 Rejected " $&{client_addr}" SPAM (zen.spamhaus.org)"', `t', `127.0.0.3',`127.0.0.4')dnl
Next: put this enhdnsbl.m4 file into cf/fea*/
(make sure nothing messed up the TABs!)
Hopefully it will work...
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 35:49:28 |
Calls: | 6,707 |
Files: | 12,239 |
Messages: | 5,353,388 |