On Fri, 02 Apr 2010 12:46:24 -0400 Jon Radel wrote:
>On 4/2/10 11:49 AM, David Allen wrote:
>>
>> On 4/2/10, Jon Radel 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 rel
Lowell Gilbert wrote:
> Matthew Seaman 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,
>
Matthew Seaman 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 goo
-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 ID
-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
On 4/2/10 11:49 AM, David Allen wrote:
On 4/2/10, 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
r
On 4/2/10, 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.
>>
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
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 b
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 fi
-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
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 fi
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 woul
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
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
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 s
16 matches
Mail list logo
