Re: Sendmail Five Second Greeting Delay
On Fri, 02 Apr 2010 12:46:24 -0400 Jon Radel j...@radel.com wrote: On 4/2/10 11:49 AM, David Allen wrote: On 4/2/10, Jon Radelj...@radel.com wrote: On 4/2/10 8:33 AM, David Allen wrote: [much stuff deleted --SB] Interesting reading. Thanks for elaborating. So the IDENT protocol was relied on in the time of the dinosaurs, it's value today is so much less (a polite way of saying not used at all?), and IDENT packets are commonly dropped by firewalls. Do I have that right? Yes, except for the not used at all bit. Well, as a mid-Triassic dinosaur who didn't reach the rapidly growing continent of UNIXia until the mid-Jurassic (SysVR1.05-4.3BSD), long after the breakup of Panibmea had begun, I'd like to say in our defense that when authd and identd first made their appearances as the latest fashion statements, those of us who had evolved properly suspicious natures due to exposure to our own user communities long before becoming networked, looked at each other, rolled our eyeballs, chuckled, and proceeded not to install either. If so, then a reasonable conclusion is that the default sendmail behaviour with respect to IDENT (sending queries and then waiting for a reply) is an anachronism. And the workaround (setting a timeout of zero) is a fix for that anachronism. Should I consider those two points as features, or should I just get off your lawn before I get yelled at? ;-) People who get all bent out of shape about 5 second delays in e-mail delivery deserve to suffer, therefore I personally think the default behavior is fine the way it is. But as I said, you can find many sendmail cookbooks on the Internet that recommend that you set it to 0 sec and get on with your life. Indeed. :-) Or you could just set all your firewalls to reject the traffic with much the same end result. In the same day's digest, on Fri, 02 Apr 2010 18:37:38 +0100, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 02/04/2010 15:12:33, Jon Radel wrote: This is why there's a school of thought that even if your default for firewall configuration is to quietly drop unwanted packets, IDENT is a protocol that you should actively reject. It makes things move along more quickly. Nonsense. When a system is harassed by useless crap like that, it is indeed appropriate to drop the packets. I remain grateful to this day to the person on this list who long ago pointed out blackhole(4) to me in response to my queries about how to deal with my system's kernel issuing console complaints that it was limiting the sending of RSTs to 200 per second. Let the buggers eat silence, I say. It can help to slow down their assaults. That, and the fact that the ident protocol is utterly pointless -- it's trivially easy for a server to lie about the owner of the other end of a TCP connection. In fact, doing that is a standard part of the functionality of identd implementations. Just a waste of packets. Precisely. So are the RSTs in such cases. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: Matthew Seaman m.sea...@infracaninophile.co.uk writes: Ident queries like this will cause a delay if the other side doesn't respond respond to the ident query ... I consider it polite for firewalls to actively refuse to open the connection (TCP reset) rather than just dropping the request, though. There's really no downside to doing so. Other than giving port-scanners an affirmative indication that there is a device of some sort at the IP address involved. Some firewalls even drop pings for exactly this reason. If the request comes from an address to which I've recently* initiated a connection -- so he already knows that my address is currently alive -- I ought to either respond per protocol or reset. If it comes from who-knows-where, it may be safer to drop it. The ident protocol is useful for the purpose for which it was designed: to pass whom to blame info between servers which have reason to trust one another's identity (based on, e.g., stable IP addresses) and administration. Granted the circumstances in which these conditions are met are a lot less prevalent than they once were. * for some resonable definition of recently ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2010 01:51:27, Norbert Papke wrote:
When I connect to sendmail on a local interface, sendmail responds to the
connection with its 220 greeting immediately. If I connect to sendmail
from
another machine on my (home) LAN, sendmail delays five seconds before sending
the greeting. I would like it to respond immediately.
A quick search turned up a greet_delay feature in sendmail that would cause
this type of behavior. To the best of my knowledge, I do not use this
feature. Just to be sure, I tried to explicitly enable it with both a
default
0 second timeout and an explicit 0 second access rule. This did not the
resolve the issue.
For the sake of the archives, I'd like to note that the `greet_pause'
feature is actually a pretty effective and very cheap to implement
anti-spam measure. You need:
FEATURE(greet_pause, `5000')dnl ## 5 seconds
in your $(hostname).mc file -- this gives you a default 5 second delay.
If you also have
FEATURE(`access_db')
you can override that value for particular IP ranges or domain names.
This is also a handy addition to the .mc file:
LOCAL_RULESETS
SLocal_greet_pause
R$* $: ${daemon_flags}
R$* a $*$# 0
This turns off greet_pause on network ports where authentication is
required, ie. if you use port 587 for submitting new mail and reserve
port 25 for MTA to MTA mail transfers.
The way this works is that it requires the sending side to wait until
your system prints out the greeting banner. If the sending side starts
speaking before then, sendmail will refuse to accept any mail during
that session. All real MTAs will get this right, as it is part of the
SMTP specification in the RFCs. Many spambots on the other hand, send
e-mail by simply replaying one side of a recorded SMTP conversation
without reguard for what the other side says. This feature weeds out
that sort of spambot with very little effort.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku1isIACgkQ8Mjk52CukIxZHgCfYCSyseFoQ+M89C1kJIt+Oq8n
bKcAoIpNrzUS2xN3ZGGZ889qLZq6TRmD
=U4Ip
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On 4/1/10, Matthew Seaman wrote:
On 02/04/2010 01:51:27, Norbert Papke wrote:
When I connect to sendmail on a local interface, sendmail responds to the
connection with its 220 greeting immediately. If I connect to sendmail
from
another machine on my (home) LAN, sendmail delays five seconds before
sending
the greeting. I would like it to respond immediately.
A quick search turned up a greet_delay feature in sendmail that would
cause
this type of behavior. To the best of my knowledge, I do not use this
feature. Just to be sure, I tried to explicitly enable it with both a
default
0 second timeout and an explicit 0 second access rule. This did not the
resolve the issue.
For the sake of the archives, I'd like to note that the `greet_pause'
feature is actually a pretty effective and very cheap to implement
anti-spam measure. You need:
FEATURE(greet_pause, `5000')dnl ## 5 seconds
in your $(hostname).mc file -- this gives you a default 5 second delay.
If you also have
FEATURE(`access_db')
you can override that value for particular IP ranges or domain names.
This is also a handy addition to the .mc file:
LOCAL_RULESETS
SLocal_greet_pause
R$* $: ${daemon_flags}
R$* a $*$# 0
This turns off greet_pause on network ports where authentication is
required, ie. if you use port 587 for submitting new mail and reserve
port 25 for MTA to MTA mail transfers.
The way this works is that it requires the sending side to wait until
your system prints out the greeting banner. If the sending side starts
speaking before then, sendmail will refuse to accept any mail during
that session. All real MTAs will get this right, as it is part of the
SMTP specification in the RFCs. Many spambots on the other hand, send
e-mail by simply replaying one side of a recorded SMTP conversation
without reguard for what the other side says. This feature weeds out
that sort of spambot with very little effort.
Useful reading. Two questions ...
First, I'm wondering what is logged as a result of using greet_pause when
getting slammed by a bot. Is it something along the lines of User did
not issue..., LA LA LA I wasn't listening, or nothing at all?
Secondly, it seems the cause of the OP's problem was a delay associated
with an IDENT query. Specificially
confTO_IDENT Timeout.ident [5s] The timeout waiting for a
response to an IDENT query.
If he had local DNS configured, there would be no query, and therefore no
issue, but setting the timeout to 0 seconds using
define(`confTO_IDENT', 0s)
does remove the delay, but not the underlying problem.
Put another way, I'm wondering why IDENT queries are made? My knowledge
of that protocol is superficial, but my understanding is that running an
identity service is widely considered a security problem. FreeBSD doesn't
run identd by default, for example, but it's possible that some Linux
distros do. The Wikipedia article suggests It's an IRC thing, but that
doesn't address the default sendmail behavior.
Thanks.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On 4/2/10 8:33 AM, David Allen wrote: Secondly, it seems the cause of the OP's problem was a delay associated with an IDENT query. Specificially confTO_IDENT Timeout.ident [5s] The timeout waiting for a response to an IDENT query. If he had local DNS configured, there would be no query, and therefore no issue, but setting the timeout to 0 seconds using define(`confTO_IDENT', 0s) does remove the delay, but not the underlying problem. You sure? IDENT has nothing to do with DNS, and I don't know of any program that does an IDENT query solely if DNS data is not available. I can't see why that would make any sense. What is most likely the OP's root problem is that he's sending e-mail from a machine that's on the other side of a firewall that blocks IDENT traffic but doesn't actively reject it. So sendmail has to sit around and wait for the query to time out. This is why there's a school of thought that even if your default for firewall configuration is to quietly drop unwanted packets, IDENT is a protocol that you should actively reject. It makes things move along more quickly. Put another way, I'm wondering why IDENT queries are made? My knowledge of that protocol is superficial, but my understanding is that running an identity service is widely considered a security problem. FreeBSD doesn't run identd by default, for example, but it's possible that some Linux distros do. The Wikipedia article suggests It's an IRC thing, but that doesn't address the default sendmail behavior. Things can make more sense when you realize that TCP/IP networks have changed over the years. Long ago, when dinosaurs roamed the earth, and timesharing servers were big things with professional admins and lots of users, it could be helpful to know that if you got an irritating connection from the Math Dept. server using source port X, and IDENT said the owner of the process that was using port X was a user called Jimbob, that you could go to the admin of that server and tell him to slap Jimbob upside the head. After all, if his IDENT server had been subverted, he would have mentioned it when you had a beer with him last night. These days, when so much traffic comes from individual workstations where the user can frequently arrange for an IDENT server to return any fool information they want, if they have it running at all, the value added is much less. Do remember that some of these things date from back when Linus was still in diapers (well, actually, he was about 15 when the earliest RFC with the genesis of IDENT was published), so trying to figure out why they make sense based solely on what Linux does can be futile. ;-) -- --Jon Radel j...@radel.com
Re: Sendmail Five Second Greeting Delay
On April 2, 2010, Jon Radel wrote: On 4/2/10 8:33 AM, David Allen wrote: Secondly, it seems the cause of the OP's problem was a delay associated with an IDENT query. Specificially confTO_IDENT Timeout.ident [5s] The timeout waiting for a response to an IDENT query. If he had local DNS configured, there would be no query, and therefore no issue, but setting the timeout to 0 seconds using define(`confTO_IDENT', 0s) does remove the delay, but not the underlying problem. You sure? IDENT has nothing to do with DNS, and I don't know of any program that does an IDENT query solely if DNS data is not available. I can't see why that would make any sense. What is most likely the OP's root problem is that he's sending e-mail from a machine that's on the other side of a firewall that blocks IDENT traffic but doesn't actively reject it. So sendmail has to sit around and wait for the query to time out. Allow me to clarify the scenario. The intent is for a local Windows box to relay outgoing SMTP through the FreeBSD box. Both machines are on the same LAN segment. No intervening Firewalls (except software firewalls on the boxes). Without the IDENT timeout, this is the traffic. FreeBSD box on 172.16.0.3, Windows box on 172.16.0.11. No. TimeSourceDestination Protocol Info 10844 18.153005 172.16.0.11 172.16.0.3TCP 55100 smtp [SYN] Seq=0 Win=8192 Len=0 MSS=1460 10845 18.153031 172.16.0.3172.16.0.11 TCP smtp 55100 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 10846 18.153306 172.16.0.11 172.16.0.3TCP 55100 smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0 10847 18.153944 172.16.0.3172.16.0.254 DNS Standard query PTR 11.0.16.172.in-addr.arpa 10849 18.163505 172.16.0.254 172.16.0.3DNS Standard query response PTR tiggr.lan.provenpath.ca 10850 18.163690 172.16.0.3172.16.0.254 DNS Standard query PTR 3.0.16.172.in-addr.arpa 10856 18.173804 172.16.0.254 172.16.0.3DNS Standard query response PTR proven.lan.provenpath.ca 10857 18.173943 172.16.0.3172.16.0.254 DNS Standard query A tiggr.lan.provenpath.ca 10860 18.176306 172.16.0.254 172.16.0.3DNS Standard query response A 172.16.0.11 10861 18.176532 172.16.0.3172.16.0.11 TCP 57889 ident [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=142487140 TSER=0 12402 21.156922 172.16.0.3172.16.0.11 TCP 57889 ident [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=142490140 TSER=0 13637 23.145692 172.16.0.3172.16.0.11 SMTP S: 220 proven.lan.provenpath.ca ESMTP Sendmail 8.14.4/8.14.4; Fri, 2 Apr 2010 08:26:47 -0700 (PDT) 13741 23.337234 172.16.0.11 172.16.0.3TCP 55100 smtp [ACK] Seq=1 Ack=98 Win=64143 Len=0 Basically, sendmail performs and IDENT even though the DNS lookup seems to have succeeded. The Windows box does not reject the IDENT. Cheers, -- Norbert Papke. npa...@acm.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On 4/2/10, Jon Radel j...@radel.com wrote: On 4/2/10 8:33 AM, David Allen wrote: Secondly, it seems the cause of the OP's problem was a delay associated with an IDENT query. Specificially confTO_IDENT Timeout.ident [5s] The timeout waiting for a response to an IDENT query. If he had local DNS configured, there would be no query, and therefore no issue, but setting the timeout to 0 seconds using define(`confTO_IDENT', 0s) does remove the delay, but not the underlying problem. You sure? IDENT has nothing to do with DNS, and I don't know of any program that does an IDENT query solely if DNS data is not available. I can't see why that would make any sense. Well, I'm sure that on a network with functional DNS, sendmail sends no IDENT queries. And by extension, there are no delays due to timeouts of unaswered queries . What is most likely the OP's root problem is that he's sending e-mail from a machine that's on the other side of a firewall that blocks IDENT traffic but doesn't actively reject it. So sendmail has to sit around and wait for the query to time out. That much I get, but the question is why sendmail, by default sends those queries? This is why there's a school of thought that even if your default for firewall configuration is to quietly drop unwanted packets, IDENT is a protocol that you should actively reject. It makes things move along more quickly. Fair enough. But that reasoning is based on a premise that IDENT is widely depended upon (and implicitly widely used), yes? Put another way, I'm wondering why IDENT queries are made? My knowledge of that protocol is superficial, but my understanding is that running an identity service is widely considered a security problem. FreeBSD doesn't run identd by default, for example, but it's possible that some Linux distros do. The Wikipedia article suggests It's an IRC thing, but that doesn't address the default sendmail behavior. Things can make more sense when you realize that TCP/IP networks have changed over the years. Long ago, when dinosaurs roamed the earth, and timesharing servers were big things with professional admins and lots of users, it could be helpful to know that if you got an irritating connection from the Math Dept. server using source port X, and IDENT said the owner of the process that was using port X was a user called Jimbob, that you could go to the admin of that server and tell him to slap Jimbob upside the head. After all, if his IDENT server had been subverted, he would have mentioned it when you had a beer with him last night. These days, when so much traffic comes from individual workstations where the user can frequently arrange for an IDENT server to return any fool information they want, if they have it running at all, the value added is much less. Do remember that some of these things date from back when Linus was still in diapers (well, actually, he was about 15 when the earliest RFC with the genesis of IDENT was published), so trying to figure out why they make sense based solely on what Linux does can be futile. ;-) Interesting reading. Thanks for elaborating. So the IDENT protocol was relied on in the time of the dinosaurs, it's value today is so much less (a polite way of saying not used at all?), and IDENT packets are commonly dropped by firewalls. Do I have that right? If so, then a reasonable conclusion is that the default sendmail behaviour with respect to IDENT (sending queries and then waiting for a reply) is an anachronism. And the workaround (setting a timeout of zero) is a fix for that anachronism. Should I consider those two points as features, or should I just get off your lawn before I get yelled at? ;-) -- David Off to reconfigure the firewall not to silently drop port 113 traffic. And 70 and 79, just in case. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On 4/2/10 11:49 AM, David Allen wrote: On 4/2/10, Jon Radelj...@radel.com wrote: On 4/2/10 8:33 AM, David Allen wrote: Secondly, it seems the cause of the OP's problem was a delay associated with an IDENT query. Specificially confTO_IDENT Timeout.ident [5s] The timeout waiting for a response to an IDENT query. If he had local DNS configured, there would be no query, and therefore no issue, but setting the timeout to 0 seconds using define(`confTO_IDENT', 0s) does remove the delay, but not the underlying problem. You sure? IDENT has nothing to do with DNS, and I don't know of any program that does an IDENT query solely if DNS data is not available. I can't see why that would make any sense. Well, I'm sure that on a network with functional DNS, sendmail sends no IDENT queries. And by extension, there are no delays due to timeouts of unaswered queries . Very odd. Why on earth would that be the case? What is most likely the OP's root problem is that he's sending e-mail from a machine that's on the other side of a firewall that blocks IDENT traffic but doesn't actively reject it. So sendmail has to sit around and wait for the query to time out. That much I get, but the question is why sendmail, by default sends those queries? Historical reasons. So that you know, when bad mail is sent to you from the Math Dept. server by Jimbob playing around with his own SMTP program, whom to yell at. (See below for references.) Please don't make out like I'm advocating as this being of much utility these days; I'm not. You can find all sorts of recommendations to turn this off if you look around. This is why there's a school of thought that even if your default for firewall configuration is to quietly drop unwanted packets, IDENT is a protocol that you should actively reject. It makes things move along more quickly. Fair enough. But that reasoning is based on a premise that IDENT is widely depended upon (and implicitly widely used), yes? It's still deployed enough to result in tedious discussions, such as this one, coming up fairly frequently. None of this is a problem until you have people who drop ident packets *and* get upset that there are servers out there that wait for a timeout. And just think, we could be in the bad old days, when you *had* to wait for the IP stack to timeout and sendmail didn't have a handy place to set the timeout to a short value. To paraphrase: One of the underlying rules of getting along on the Internet is to be strict in what you send and forgiving in what you accept. So do something sensible with IDENT requests or expect odd delays, and don't waste time wondering why there are still servers out there that do things that don't really make a lot of sense anymore. Put another way, I'm wondering why IDENT queries are made? My knowledge of that protocol is superficial, but my understanding is that running an identity service is widely considered a security problem. FreeBSD doesn't run identd by default, for example, but it's possible that some Linux distros do. The Wikipedia article suggests It's an IRC thing, but that doesn't address the default sendmail behavior. Things can make more sense when you realize that TCP/IP networks have changed over the years. Long ago, when dinosaurs roamed the earth, and timesharing servers were big things with professional admins and lots of users, it could be helpful to know that if you got an irritating connection from the Math Dept. server using source port X, and IDENT said the owner of the process that was using port X was a user called Jimbob, that you could go to the admin of that server and tell him to slap Jimbob upside the head. After all, if his IDENT server had been subverted, he would have mentioned it when you had a beer with him last night. These days, when so much traffic comes from individual workstations where the user can frequently arrange for an IDENT server to return any fool information they want, if they have it running at all, the value added is much less. Do remember that some of these things date from back when Linus was still in diapers (well, actually, he was about 15 when the earliest RFC with the genesis of IDENT was published), so trying to figure out why they make sense based solely on what Linux does can be futile. ;-) Interesting reading. Thanks for elaborating. So the IDENT protocol was relied on in the time of the dinosaurs, it's value today is so much less (a polite way of saying not used at all?), and IDENT packets are commonly dropped by firewalls. Do I have that right? Yes, except for the not used at all bit. If so, then a reasonable conclusion is that the default sendmail behaviour with respect to IDENT (sending queries and then waiting for a reply) is an anachronism. And the workaround (setting a timeout of zero) is a fix for that anachronism. Should I consider those two points as features, or should I just
Re: Sendmail Five Second Greeting Delay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2010 15:12:33, Jon Radel wrote: This is why there's a school of thought that even if your default for firewall configuration is to quietly drop unwanted packets, IDENT is a protocol that you should actively reject. It makes things move along more quickly. That, and the fact that the ident protocol is utterly pointless -- it's trivially easy for a server to lie about the owner of the other end of a TCP connection. In fact, doing that is a standard part of the functionality of identd implementations. Just a waste of packets. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku2K2IACgkQ8Mjk52CukIyriQCfWZc/AzYIS/38IVFScCG6jkYb tTMAoItnWUk1g2ClDTR/CWMk47lTdj1B =WYGc -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2010 13:33:09, David Allen wrote:
Secondly, it seems the cause of the OP's problem was a delay associated
with an IDENT query. Specificially
confTO_IDENT Timeout.ident [5s] The timeout waiting for a
response to an IDENT query.
If he had local DNS configured, there would be no query, and therefore no
issue, but setting the timeout to 0 seconds using
Ident queries like this will cause a delay if the other side doesn't
respond respond to the ident query. That's typical behaviour for most
machines that run firewalls nowadays. Given that ident is broken as
designed (see rant in other post) turning it off is a good idea in my book.
Note that the 5s delay produced by ident-flail doesn't prevent ultimate
delivery of the message. FEATURE('greet_pause', ...) does when the
other side is rude enough not to play by the rules.
As far as I know, the ident protocol doesn't depend on the availability
of DNS -- mind you, SMTP really really does depend on working DNS, so it
would be pretty broken anyhow.
define(`confTO_IDENT', 0s)
does remove the delay, but not the underlying problem.
Should disable use of the ident protocol with sendmail.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku2Ll0ACgkQ8Mjk52CukIybUQCfUS1juVDpbmEVuZ1K9LhZGiBo
PxwAoJSXWMl0wPqIx/co7cNjp2dNXyoU
=+PB0
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
Matthew Seaman m.sea...@infracaninophile.co.uk writes: Ident queries like this will cause a delay if the other side doesn't respond respond to the ident query. That's typical behaviour for most machines that run firewalls nowadays. Given that ident is broken as designed (see rant in other post) turning it off is a good idea in my book. I consider it polite for firewalls to actively refuse to open the connection (TCP reset) rather than just dropping the request, though. There's really no downside to doing so. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Sendmail Five Second Greeting Delay
When I connect to sendmail on a local interface, sendmail responds to the connection with its 220 greeting immediately. If I connect to sendmail from another machine on my (home) LAN, sendmail delays five seconds before sending the greeting. I would like it to respond immediately. A quick search turned up a greet_delay feature in sendmail that would cause this type of behavior. To the best of my knowledge, I do not use this feature. Just to be sure, I tried to explicitly enable it with both a default 0 second timeout and an explicit 0 second access rule. This did not the resolve the issue. I am at a loss. What could be going on? Cheers, -- Norbert. sendmail mc file: VERSIONID(`$Id: proven.lan.mc,v 1.1 2005/07/30 08:31:09 npapke Exp $')dnl OSTYPE(freebsd6) DOMAIN(generic) FEATURE(access_db, `hash -o -TTMPF /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(local_procmail) FEATURE(mailertable, `hash -o /etc/mail/mailertable') FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') FEATURE(always_add_domain)dnl FEATURE(masquerade_envelope)dnl FEATURE(`accept_unresolvable_domains')dnl MODIFY_MAILER_FLAGS(`LOCAL', `+S')dnl define( `SMART_HOST', `shawmail.vc.shawcable.net')dnl define(`confCW_FILE', `-o /etc/mail/local-host-names') DAEMON_OPTIONS(`Name=IPv4, Family=inet') define(`confBIND_OPTS', `WorkAroundBroken') define(`confNO_RCPT_ACTION', `add-to-undisclosed') define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy') # Virtual hosts FEATURE(virtusertable)dnl VIRTUSER_DOMAIN_FILE(`/etc/mail/virtdomains')dnl FEATURE(`virtuser_entire_domain')dnl MAILER(procmail)dnl MAILER(smtp)dnl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
A delay of that long can be cause by the system attempting to do name resolution on your IP. Try entering the IP of the testing system into /etc/hosts and see if the delay goes away. If it does, then you know. Bruce On 04/01/2010 05:51 PM, Norbert Papke wrote: When I connect to sendmail on a local interface, sendmail responds to the connection with its 220 greeting immediately. If I connect to sendmail from another machine on my (home) LAN, sendmail delays five seconds before sending the greeting. I would like it to respond immediately. A quick search turned up a greet_delay feature in sendmail that would cause this type of behavior. To the best of my knowledge, I do not use this feature. Just to be sure, I tried to explicitly enable it with both a default 0 second timeout and an explicit 0 second access rule. This did not the resolve the issue. I am at a loss. What could be going on? Cheers, -- Norbert. sendmail mc file: VERSIONID(`$Id: proven.lan.mc,v 1.1 2005/07/30 08:31:09 npapke Exp $')dnl OSTYPE(freebsd6) DOMAIN(generic) FEATURE(access_db, `hash -o -TTMPF /etc/mail/access') FEATURE(blacklist_recipients) FEATURE(local_procmail) FEATURE(mailertable, `hash -o /etc/mail/mailertable') FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') FEATURE(always_add_domain)dnl FEATURE(masquerade_envelope)dnl FEATURE(`accept_unresolvable_domains')dnl MODIFY_MAILER_FLAGS(`LOCAL', `+S')dnl define( `SMART_HOST', `shawmail.vc.shawcable.net')dnl define(`confCW_FILE', `-o /etc/mail/local-host-names') DAEMON_OPTIONS(`Name=IPv4, Family=inet') define(`confBIND_OPTS', `WorkAroundBroken') define(`confNO_RCPT_ACTION', `add-to-undisclosed') define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy') # Virtual hosts FEATURE(virtusertable)dnl VIRTUSER_DOMAIN_FILE(`/etc/mail/virtdomains')dnl FEATURE(`virtuser_entire_domain')dnl MAILER(procmail)dnl MAILER(smtp)dnl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On April 1, 2010, Bruce Ferrell wrote: A delay of that long can be cause by the system attempting to do name resolution on your IP. Try entering the IP of the testing system into /etc/hosts and see if the delay goes away. If it does, then you know. Thanks for the suggestion, unfortunately it does not make a difference. Cheers, -- Norbert. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
At 08:51 PM 4/1/2010, Norbert Papke wrote: When I connect to sendmail on a local interface, sendmail responds to the connection with its 220 greeting immediately. If I connect to sendmail from another machine on my (home) LAN, sendmail delays five seconds before sending the greeting. I would like it to respond immediately. What if you add define(`confTO_IDENT', 0s) to your mc file and remake your .cf file with that set ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Sendmail Five Second Greeting Delay
On April 1, 2010, Mike Tancsa wrote: At 08:51 PM 4/1/2010, Norbert Papke wrote: When I connect to sendmail on a local interface, sendmail responds to the connection with its 220 greeting immediately. If I connect to sendmail from another machine on my (home) LAN, sendmail delays five seconds before sending the greeting. I would like it to respond immediately. What if you add define(`confTO_IDENT', 0s) to your mc file and remake your .cf file with that set Thanks, that did it. -- Norbert. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
