Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sendmail greeting delay
204 views
Skip to first unread message
David Parker
Jan 13, 2015, 12:40:04 PM1/13/15
to
Hello,
We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit. We're using the file /etc/mail/access for access control and rate limiting, and this is enabled via the following lines in /etc/mail/sendmail.cf:
Kaccess hash -T<TMPF> /etc/mail/access
# FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access', `skip')dnl
For some reason, I just can't get it to not pause when greeting external (non-localhost) connections. I was testing SSL/TLS connectivity when I discovered the delay, using "openssl s_client -connect smtp-server:465". If I run this command from the SMTP server, it connects and then prints all of the SSL and certificate information immediately. But if I test from another PC on our network, it connects, pauses for 5 seconds, and then prints the SSL information.
My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to connect with no delay. I have also tried setting the default GreetPause to "0" but it still made no difference.
########################################
Connect:localhost RELAY
GreetPause:localhost 0
ClientRate:localhost 0
ClientConn:localhost 0
Connect:127 RELAY
GreetPause:127 0
ClientRate:127 0
ClientConn:127 0
Connect:IPv6:::1 RELAY
GreetPause:IPv6:::1 0
ClientRate:IPv6:::1 0
ClientConn:IPv6:::1 0
Connect:10 RELAY
GreetPause:10 0
ClientRate:10 0
ClientConn:10 0
# Defaults
Connect: REJECT
GreetPause: 5000
ClientRate: 10
ClientConn: 10
# Whitelisted users
Spam:postmaster@ FRIEND
Spam:abuse@ FRIEND
Spam:spam@ FRIEND
# Blacklisted users
reject@ REJECT
# Block invalid IPs
Connect:169.254 REJECT
Connect:192.0.2 REJECT
Connect:224 REJECT
Connect:255 REJECT
########################################
Dave Parker
Systems AdministratorUtica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
Burhan Hanoglu
Jan 13, 2015, 1:10:04 PM1/13/15
to
Hi Dave,
I'd add the IP address of that PC to /etc/hosts.allow on sendmail machine to rule out TCP Wrappers...
Also; any chance something is doing reverse dns check?
Burhan
Chris Davies
Jan 13, 2015, 2:20:04 PM1/13/15
to
David Parker <dpa...@utica.edu> wrote:
> We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit.
> We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit.
> Kaccess hash -T<TMPF> /etc/mail/access
> # FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access', `skip')dnl
> For some reason, I just can't get it to not pause when greeting external
> (non-localhost) connections. [...]
> # FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access', `skip')dnl
> For some reason, I just can't get it to not pause when greeting external
> if I test from another PC on our network, it connects, pauses for 5
> seconds, and then prints the SSL information.
Does your PC have an rDNS entry, and if not could this delay be a DNS
> seconds, and then prints the SSL information.
lookup timeout?
Chris
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/rfqdobx...@news.roaima.co.uk
David Parker
Jan 13, 2015, 2:30:06 PM1/13/15
to
Thanks for the replies.
The system is not using tcpwrappers, and it's also not a DNS issue. The client PC does have a reverse DNS entry. A tcpdump packet capture on the server shows the initial connection from the client followed by a bunch of DNS traffic, all within the same second. Then nothing happens for exactly 5 seconds, then the server sends data back to the client.
Just to be extra sure, I added an entry for it in /etc/hosts so DNS wouldn't even be needed. Still made no difference.
Thanks,
Dave
Joe
Jan 13, 2015, 3:20:04 PM1/13/15
to
On Tue, 13 Jan 2015 20:12:11 +0000
Joe <j...@jretrading.com> wrote:
> On Tue, 13 Jan 2015 14:27:42 -0500
> David Parker <dpa...@utica.edu> wrote:
>
> > Thanks for the replies.
> >
> > The system is not using tcpwrappers, and it's also not a DNS issue.
> > The client PC does have a reverse DNS entry. A tcpdump packet
> > capture on the server shows the initial connection from the client
> > followed by a bunch of DNS traffic, all within the same second.
> > Then nothing happens for exactly 5 seconds, then the server sends
> > data back to the client.
> >
> > Just to be extra sure, I added an entry for it in /etc/hosts so DNS
> > wouldn't even be needed. Still made no difference.
> >
>
> Is it asking for an ident from the connecting server (TCP port 7)?
> This is an old-fashioned custom, when computers with MTAs also ran
> ident servers, which provided some fairly harmless information.
>
> Exim4 can certainly ask for an ident, and does nothing for a
> configurable timeout unless one is received, or the sender address is
> whitelisted. It is a simple anti-spam measure, as practically nothing
> runs ident servers today, and most malware will give up before a
> thirty-second timeout expires, whereas a legitimate MTA will wait
> for that long.
>
OK, where did the 7 come from? Should be port 113. I saw it just as the
mouse button clicked...
--
Joe
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150113201...@jresid.jretrading.com
Joe <j...@jretrading.com> wrote:
> On Tue, 13 Jan 2015 14:27:42 -0500
> David Parker <dpa...@utica.edu> wrote:
>
> > Thanks for the replies.
> >
> > The system is not using tcpwrappers, and it's also not a DNS issue.
> > The client PC does have a reverse DNS entry. A tcpdump packet
> > capture on the server shows the initial connection from the client
> > followed by a bunch of DNS traffic, all within the same second.
> > Then nothing happens for exactly 5 seconds, then the server sends
> > data back to the client.
> >
> > Just to be extra sure, I added an entry for it in /etc/hosts so DNS
> > wouldn't even be needed. Still made no difference.
> >
>
> This is an old-fashioned custom, when computers with MTAs also ran
> ident servers, which provided some fairly harmless information.
>
> Exim4 can certainly ask for an ident, and does nothing for a
> configurable timeout unless one is received, or the sender address is
> whitelisted. It is a simple anti-spam measure, as practically nothing
> runs ident servers today, and most malware will give up before a
> thirty-second timeout expires, whereas a legitimate MTA will wait
> for that long.
>
OK, where did the 7 come from? Should be port 113. I saw it just as the
mouse button clicked...
--
Joe
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joe
Jan 13, 2015, 3:20:04 PM1/13/15
to
> Thanks for the replies.
>
> The system is not using tcpwrappers, and it's also not a DNS issue.
> The client PC does have a reverse DNS entry. A tcpdump packet
> capture on the server shows the initial connection from the client
> followed by a bunch of DNS traffic, all within the same second. Then
> nothing happens for exactly 5 seconds, then the server sends data
> back to the client.
>
> Just to be extra sure, I added an entry for it in /etc/hosts so DNS
> wouldn't even be needed. Still made no difference.
>
>
> The system is not using tcpwrappers, and it's also not a DNS issue.
> The client PC does have a reverse DNS entry. A tcpdump packet
> capture on the server shows the initial connection from the client
> followed by a bunch of DNS traffic, all within the same second. Then
> nothing happens for exactly 5 seconds, then the server sends data
> back to the client.
>
> Just to be extra sure, I added an entry for it in /etc/hosts so DNS
> wouldn't even be needed. Still made no difference.
>
Is it asking for an ident from the connecting server (TCP port 7)? This
is an old-fashioned custom, when computers with MTAs also ran ident
servers, which provided some fairly harmless information.
Exim4 can certainly ask for an ident, and does nothing for a
configurable timeout unless one is received, or the sender address is
whitelisted. It is a simple anti-spam measure, as practically nothing
runs ident servers today, and most malware will give up before a
thirty-second timeout expires, whereas a legitimate MTA will wait
for that long.
--
is an old-fashioned custom, when computers with MTAs also ran ident
servers, which provided some fairly harmless information.
Exim4 can certainly ask for an ident, and does nothing for a
configurable timeout unless one is received, or the sender address is
whitelisted. It is a simple anti-spam measure, as practically nothing
runs ident servers today, and most malware will give up before a
thirty-second timeout expires, whereas a legitimate MTA will wait
for that long.
Joe
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Siegle
Jan 13, 2015, 3:30:03 PM1/13/15
to
On 2015-01-13 at 12:38, David Parker wrote:
> Hello,
I'm struggling with a reference beyond my own work. Please try
putting a second and maybe a third octet on your GreetPause: 10 line.
Also, please verify you are issuing a kill -HUP on sendmail. We never got
sendmail greetpause to work with a single octet. Normally we do 3 octets
for all the RFC1918 addresses we use.
-Jonathan
> Hello,
>
> My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to
> connect with no delay. I have also tried setting the default GreetPause to "0" but it still made no difference.
>
> ########################################
> Connect:localhost RELAY
> GreetPause:localhost 0
> ClientRate:localhost 0
> ClientConn:localhost 0
> Connect:127 RELAY
> GreetPause:127 0
> ClientRate:127 0
> ClientConn:127 0
> Connect:IPv6:::1 RELAY
> GreetPause:IPv6:::1 0
> ClientRate:IPv6:::1 0
> ClientConn:IPv6:::1 0
> Connect:10 RELAY
> GreetPause:10 0
> ClientRate:10 0
> ClientConn:10 0
Dave,
> My /etc/mail/access file is pasted below. The PC I'm testing from is on the 10.x.x.x network, which should be allowed to
> connect with no delay. I have also tried setting the default GreetPause to "0" but it still made no difference.
>
> ########################################
> Connect:localhost RELAY
> GreetPause:localhost 0
> ClientRate:localhost 0
> ClientConn:localhost 0
> Connect:127 RELAY
> GreetPause:127 0
> ClientRate:127 0
> ClientConn:127 0
> Connect:IPv6:::1 RELAY
> GreetPause:IPv6:::1 0
> ClientRate:IPv6:::1 0
> ClientConn:IPv6:::1 0
> Connect:10 RELAY
> GreetPause:10 0
> ClientRate:10 0
> ClientConn:10 0
I'm struggling with a reference beyond my own work. Please try
putting a second and maybe a third octet on your GreetPause: 10 line.
Also, please verify you are issuing a kill -HUP on sendmail. We never got
sendmail greetpause to work with a single octet. Normally we do 3 octets
for all the RFC1918 addresses we use.
-Jonathan
David Parker
Jan 13, 2015, 3:30:04 PM1/13/15
to
Yes! That seems to be the culprit. I ran an strace on the sendmail process and that's exactly what happens:
[ ... ]
4007 15:09:08.386921 connect(5, {sa_family=AF_INET, sin_port=htons(113), sin_addr=inet_addr("10.3.1.40")}, 16 <unfinished ...>
3792 15:09:13.386272 <... select resumed> ) = 0 (Timeout)
[ ... ]
Where 10.3.1.40 is the IP of the client PC. So now I just need to dig into the config and figure out how to stop it. Thanks!
David Parker
Jan 13, 2015, 3:30:04 PM1/13/15
to
Thanks, but it looks like the IDENT setting was the culprit. I just had to change this setting in sendmail.cf:
O Timeout.ident=5s
Changing it from 5s to 0s resolved the problem immediately. Thanks again, everyone!
David Parker
Jan 13, 2015, 3:50:04 PM1/13/15
to
Just for the sake of completeness, this wasn't actually an issue with the GreetPause option or anything else in the access file. The problem was that sendmail was attempting an IDENT query to the client, with a 5-second timeout. The access file wasn't even checked until after the timeout expired. In retrospect, I guess it makes sense because I was testing this by connecting with openssl, which is just looking for the SSL/TLS info at the beginning of the connection, and doesn't need to wait for the greeting. The GreetPause values work as expected for actual client connections on port 25, 465, or 587.
Thanks!
0 new messages