Re: Sendmail greeting delay
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! On Tue, Jan 13, 2015 at 3:27 PM, David Parker wrote: > 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! > > On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle wrote: > >> On 2015-01-13 at 12:38, David Parker wrote: >> >> 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, >> 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 > > > > > -- > Dave Parker > Systems Administrator > Utica College > Integrated Information Technology Services > (315) 792-3229 > Registered Linux User #408177 > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
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! On Tue, Jan 13, 2015 at 3:07 PM, Jonathan Siegle wrote: > On 2015-01-13 at 12:38, David Parker wrote: > > 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, > 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 -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
On 2015-01-13 at 12:38, David Parker wrote: 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, 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
Re: Sendmail greeting delay
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
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!
On Tue, Jan 13, 2015 at 3:16 PM, Joe wrote:
> On Tue, 13 Jan 2015 20:12:11 +
> Joe wrote:
>
> > On Tue, 13 Jan 2015 14:27:42 -0500
> > David Parker 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-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/20150113201613.0b84c...@jresid.jretrading.com
>
>
--
Dave Parker
Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177
Re: Sendmail greeting delay
On Tue, 13 Jan 2015 20:12:11 + Joe wrote: > On Tue, 13 Jan 2015 14:27:42 -0500 > David Parker 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-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150113201613.0b84c...@jresid.jretrading.com
Re: Sendmail greeting delay
On Tue, 13 Jan 2015 14:27:42 -0500 David Parker 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. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150113201211.68976...@jresid.jretrading.com
Re: Sendmail greeting delay
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 On Mon, Jan 12, 2015 at 4:21 PM, Chris Davies wrote: > David Parker wrote: > > We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit. > > > Kaccess hash -T /etc/mail/access > > # FEATURE(`access_db', `hash -T /etc/mail/access', `skip')dnl > > > For some reason, I just can't get it to not pause when greeting external > > (non-localhost) connections. [...] > > 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 > lookup timeout? > > Chris > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/rfqdobx8se@news.roaima.co.uk > > -- Dave Parker Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177
Re: Sendmail greeting delay
David Parker wrote: > We have an SMTP server running Sendmail 8.14.4-4 on Debian 7 64-bit. > Kaccess hash -T /etc/mail/access > # FEATURE(`access_db', `hash -T /etc/mail/access', `skip')dnl > For some reason, I just can't get it to not pause when greeting external > (non-localhost) connections. [...] > 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 lookup timeout? Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/rfqdobx8se@news.roaima.co.uk
Re: Sendmail greeting delay
On Tue, Jan 13, 2015 at 7:38 PM, David Parker wrote: > 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 /etc/mail/access > # FEATURE(`access_db', `hash -T /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 > > > Any help would be greatly appreciated. Thanks! > > 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
