in my access.txt file I have:
speedy.com.ar REJECT
But I still see the connections coming in and sitting there:
\_ sendmail: lAL447o7003067 190-173-26-200.speedy.com.ar [190.173.26.200]
shouldn't they be immediately dropped? they're using valuable
connection sockets.
I'm using sendmail 8.14.1 on linux 2.4.
In article
Ken Williams
> in my access.txt file I have:
> speedy.com.ar REJECT
>
> But I still see the connections coming in and sitting there:
> \_ sendmail: lAL447o7003067 190-173-26-200.speedy.com.ar [190.173.26.200]
>
> shouldn't they be immediately dropped?
Not according to normal MTA behavior. The REJECT in your access map
(assuming that the above has been compiled into the active db file) only
acts at the application layer, i.e. SMTP. Offers of messages are
rejected in the SMTP conversation, but there is no effect on the
underlying TCP connection. A well-behaved SMTP client will do a normal
QUIT in SMTP and a proper TCP close on the connection when it has no
more mail to offer. In principle a rejection of one message must not be
seen by the client as a signal to not try any others it might have for
the same host, and the server that has rejected one message in SMTP
should not be forcibly closing the connection even if the reason for
rejection will apply to all offers of messages on that connection.
However, recent versions of some trojan spamware has shown the behavior
of not closing connections at all. This can be quite a problem, but can
be helped somewhat by reducing the timeout in Sendmail when it is
waiting for a SMTP command from the client: confTO_COMMAND in
sendmail.mc or Timeout.command in sendmail.cf. The default is one hour,
and while that is consistent with the SMTP spec, it is premised on a
world where most clients mean well. In the real modern world, 5 minutes
is a far more reasonable value. Setting it much shorter can be a problem
because some high-volume senders intentionally keep connections open for
a while in case they have a new message to offer, and closing on those
senders can cause them to delay trying on a new session.
>they're using valuable
> connection sockets.
It is a good idea to tune your system to not have that as the bottleneck
for your mail server.
If you really want to cut off some networks at the TCP level, you
probably want to do it with either a packet filter (e.g. iptables) or
the TCP wrappers facility that can be enabled in Sendmail as a
compile-time option. It can be convenient to have both, since low-level
filters like iptables generally only act on IP addresses (and MAC
addresses, which are not relevant in this case) while TCP wrappers can
act on domain names as well.
--
Now where did I hide that website...
In article
>
>If you really want to cut off some networks at the TCP level, you
>probably want to do it with either a packet filter (e.g. iptables) or
>the TCP wrappers facility that can be enabled in Sendmail as a
>compile-time option.
TCP wrappers as used by sendmail will not cut off at the TCP level
though - they have the same effect as REJECT based on client host in
access db.
--Per Hedeland
per@hedeland.org
In article
per@hedeland.org (Per Hedeland) wrote:
> In article
>
> >
> >If you really want to cut off some networks at the TCP level, you
> >probably want to do it with either a packet filter (e.g. iptables) or
> >the TCP wrappers facility that can be enabled in Sendmail as a
> >compile-time option.
>
> TCP wrappers as used by sendmail will not cut off at the TCP level
> though - they have the same effect as REJECT based on client host in
> access db.
Even with delay_checks?
I confess to not using the compiled-in wrapper support, but this strikes
me as a design mistake to the degree of making wrapper support
pointless.
--
Now where did I hide that website...
In article
>In article
> per@hedeland.org (Per Hedeland) wrote:
>
>> In article
>>
>> >
>> >If you really want to cut off some networks at the TCP level, you
>> >probably want to do it with either a packet filter (e.g. iptables) or
>> >the TCP wrappers facility that can be enabled in Sendmail as a
>> >compile-time option.
>>
>> TCP wrappers as used by sendmail will not cut off at the TCP level
>> though - they have the same effect as REJECT based on client host in
>> access db.
>
>Even with delay_checks?
Hm, I don't think delay_checks affects TCP wrappers at all, since
delay_check just reorganizes the mapping from ruleset calls made by the
binary to rulesets in sendmail.cf (i.e. the binary isn't even aware of
delay_checks), and TCP wrappers isn't invoked from a ruleset but
directly from the binary. But if it *did* have an effect, surely you'd
expect it make them even *less* of a TCP level cutoff?
>I confess to not using the compiled-in wrapper support, but this strikes
>me as a design mistake to the degree of making wrapper support
>pointless.
Well, TCP wrappers doesn't *really* do a TCP level cutoff even in
"traditional" usage, it couldn't since it operates completely at user
level. What it typically does do is to accept the TCP connection and
then immediately close it if it should be "denied". I'm sure you know
the argument against doing that for SMTP, a correctly functioning SMTP
client will see it as a "temporary failure" and keep trying, whereas the
way sendmail implements TCP wrapper "deny" (keep the connection open but
respond with 5xx to everything) should make it give up and go away.
I believe the point of having support for it in sendmail is a) some
people may like to have all their "access rules" in one place, and that
place can't be sendmail's access map - that argument probably doesn't
make much sense in the spam era, but the support has been there for a
long time - and b), there are some rules you can specify more easily in
the TCP wrappers config than in access db (e.g. "allow only this single
IP address).
Uh, after writing the above I finally realized what you were saying:-) -
I'll let it stand just in case it's useful to someone. So yes, TCP
wrappers won't have the same effect as REJECT in access db if you use
delay_checks, and that can be seen as another point: TCP wrappers "deny"
will reject from the get-go even if you use delay_checks. Though I'm
pretty sure TCP wrappers support predates delay_checks by several years,
i.e. I don't think that can have been a motivation for adding it.
--Per Hedeland
per@hedeland.org
In article
wrote:
> In article
>
> >In article
> > per@hedeland.org (Per Hedeland) wrote:
> >
> >> In article
> >>
> >> >
> >> >If you really want to cut off some networks at the TCP level, you
> >> >probably want to do it with either a packet filter (e.g. iptables) or
> >> >the TCP wrappers facility that can be enabled in Sendmail as a
> >> >compile-time option.
> >>
> >> TCP wrappers as used by sendmail will not cut off at the TCP level
> >> though - they have the same effect as REJECT based on client host in
> >> access db.
> >
> >Even with delay_checks?
>
> Hm, I don't think delay_checks affects TCP wrappers at all, since
> delay_check just reorganizes the mapping from ruleset calls made by the
> binary to rulesets in sendmail.cf (i.e. the binary isn't even aware of
> delay_checks), and TCP wrappers isn't invoked from a ruleset but
> directly from the binary. But if it *did* have an effect, surely you'd
> expect it make them even *less* of a TCP level cutoff?
>
> >I confess to not using the compiled-in wrapper support, but this strikes
> >me as a design mistake to the degree of making wrapper support
> >pointless.
>
> Well, TCP wrappers doesn't *really* do a TCP level cutoff even in
> "traditional" usage, it couldn't since it operates completely at user
> level. What it typically does do is to accept the TCP connection and
> then immediately close it if it should be "denied". I'm sure you know
> the argument against doing that for SMTP, a correctly functioning SMTP
> client will see it as a "temporary failure" and keep trying, whereas the
> way sendmail implements TCP wrapper "deny" (keep the connection open but
> respond with 5xx to everything) should make it give up and go away.
I thought it was based on a vague memory of trying it out in the 8.9.x
era, but I was under the impression that a Sendmail wrapper denial would
give a 554 banner and disconnect. Were that the case, it should cause
well-behaved clients to not retry.
> I believe the point of having support for it in sendmail is a) some
> people may like to have all their "access rules" in one place, and that
> place can't be sendmail's access map - that argument probably doesn't
> make much sense in the spam era, but the support has been there for a
> long time - and b), there are some rules you can specify more easily in
> the TCP wrappers config than in access db (e.g. "allow only this single
> IP address).
>
> Uh, after writing the above I finally realized what you were saying:-) -
> I'll let it stand just in case it's useful to someone. So yes, TCP
> wrappers won't have the same effect as REJECT in access db if you use
> delay_checks, and that can be seen as another point: TCP wrappers "deny"
> will reject from the get-go even if you use delay_checks.
>Though I'm
> pretty sure TCP wrappers support predates delay_checks by several years,
> i.e. I don't think that can have been a motivation for adding it.
Yes, I'll make another statement from vague memories of the 90's and say
that I believe wrapper support predates the access db and check_*
rulesets altogether.
--
Now where did I hide that website...
In article
>In article
>wrote:
>>
>> Well, TCP wrappers doesn't *really* do a TCP level cutoff even in
>> "traditional" usage, it couldn't since it operates completely at user
>> level. What it typically does do is to accept the TCP connection and
>> then immediately close it if it should be "denied". I'm sure you know
>> the argument against doing that for SMTP, a correctly functioning SMTP
>> client will see it as a "temporary failure" and keep trying, whereas the
>> way sendmail implements TCP wrapper "deny" (keep the connection open but
>> respond with 5xx to everything) should make it give up and go away.
>
>I thought it was based on a vague memory of trying it out in the 8.9.x
>era, but I was under the impression that a Sendmail wrapper denial would
>give a 554 banner and disconnect. Were that the case, it should cause
>well-behaved clients to not retry.
Hm, it may, but it could still be treated as a tempfail due to the
connection dropping abruptly - the server should not close until the
client sends QUIT (with the exception of 421).
>>Though I'm
>> pretty sure TCP wrappers support predates delay_checks by several years,
>> i.e. I don't think that can have been a motivation for adding it.
>
>Yes, I'll make another statement from vague memories of the 90's and say
>that I believe wrapper support predates the access db and check_*
>rulesets altogether.
I was about to add more vague recollection with partial doubts about
that, but hey, the RELEASE_NOTES shipped with every version still go
back to 8.1.:-) In fact check_* and wrappers were both added in 8.8.0
(1996/09/26), but there were no stock rules making use of check_* until
8.9.0 (1998/05/19), which was the first to deny relaying by default.
--Per Hedeland
per@hedeland.org