|
|
| Author |
Message |
| 24 new of 248 responses total. |
gelinas
|
|
response 225 of 248:
| 
Dec 15 03:33 UTC 2002 |
(#217 assumes that spammers *care* that they are inconveniencing other. If
they did, they'd not send the junk in the first place. So why bother asking
them to stop?)
|
mcnally
|
|
response 226 of 248:
|
Dec 15 05:13 UTC 2002 |
No doubt my understanding of the problem is completely deficient but
nothing said so far illustrates to me why this problem can't be dealt
with by using tcp wrappers to block these IP addresses from connecting
to just the SMTP port.
I'm really not understanding what Marcus is saying in the first sentence
of 224. My recollecton concerning TCP wrappers is that the major reason
to run the package is to allow selective blocking of incoming connections
on certain ports. I'll admit it's been a long time, though, maybe I'm
thinking of another package entirely.
|
gull
|
|
response 227 of 248:
|
Dec 15 17:26 UTC 2002 |
Re #225: They might care they're wasting time trying to connect to a machine
they can't get through to.
Re #226: I got the impression these were half-open connections -- a syn
flood, in effect, filling up the state table. In that case TCP wrappers
wouldn't help because it doesn't kick in until the connection is
established. Did I read wrong?
|
krj
|
|
response 228 of 248:
|
Dec 15 19:01 UTC 2002 |
I have another report of lost mail. I sent my sister e-mail on
Wednesday; she tells me by phone today that she received the mail
promptly and replied, but the reply hasn't shown on up on Grex after
about three days.
|
cross
|
|
response 229 of 248:
|
Dec 15 19:11 UTC 2002 |
This response has been erased.
|
gelinas
|
|
response 230 of 248:
|
Dec 16 01:01 UTC 2002 |
(Three days is the usual "first notification" limit, so she may have gotten
her message back by now, or at least a warning that it has not yet been
delivered.)
|
gelinas
|
|
response 231 of 248:
|
Dec 16 01:21 UTC 2002 |
Re #227: It's bulk mail; the individual recipient, or even the individual
machine, isn't important. *IF* the hung connections were inconveniencing
the senders, they *might* be interested in fixing it. But if they were
being inconvenienced, they'd have noticed, no? They haven't fixed it,
so they (must not | probably don't) care.
|
mdw
|
|
response 232 of 248:
|
Dec 16 02:32 UTC 2002 |
My guess is that the bulk mailers were in the "process" of being
disconnected; they still had the physical IP connection and could send
packets, but were using addresses that were no longer "routable", so it
was no longer possible to send packets back to them.
The tcp wrappers come with a library and it's possible to compile other
programs (such as sshd) to use the same basic blocking code. It
wouldn't be useful for sendmail hwever as there are way too many mail
gateways that, when a connection fails for any reason, immediately retry
without even waiting. So, in fact, you actually want to accept the
connection, wait until they try to send mail, and *then* deliver a 5xx
error code. That *should* clear the queue entry out at their end and
avoid the retry. Grex's sendmail isn't great at doing this, but it does
have support and we use it routinely against people we recognize as
spammers. Last week, we rejected 1904 pieces of mail using this
facility. The 5xx error also contains a URL, and 11 people read the
file referenced by the URL.
|
dang
|
|
response 233 of 248:
|
Dec 16 02:36 UTC 2002 |
SYN floods require kernel level protection. All modern kernels have
such protections built in. Unfortuantly, Grex is not yet running a
modern kernel. Hence our current problem.
|
mcnally
|
|
response 234 of 248:
|
Dec 16 04:36 UTC 2002 |
Ahh.. Ok, now I get it.
|
jazz
|
|
response 235 of 248:
|
Dec 16 14:22 UTC 2002 |
Conventional kernel-level SYN flood protection wouldn't help you here,
anyways, since it isn't a "flood" in the sense that there aren't many
connection attempts being made.
|
davel
|
|
response 236 of 248:
|
Dec 16 20:56 UTC 2002 |
For whatever it's worth: I send (from off site) several messages a day to
a couple of people on Grex. From the system where I send them, I see them
hanging in the queue for long periods. Usually the error message given is
Deferred: Connection timed out with grex.cyberspace.org.
but sometimes it is
Deferred: Interrupted system call
Given what's been said, I assume that it times out because there are too many
of these half-open connections. But I have to wonder if the "Interrupted
system call" error doesn't occur because I somehow get a half-open connection.
At any rate, I thought I'd mention this message.
|
dang
|
|
response 237 of 248:
|
Dec 17 02:42 UTC 2002 |
resp:235 That depends on how the particular kernel detects SYN floods.
I would classify "sevaral" half open connections at at time from the
same IP as a SYN flood. How you define "several" depends on the system
and it's load, I suppose.
Many kernels have tunable SYN timeouts, which could be useful here.
Time them out quicker. (Incidentally, my Linux 2.4 box has a max of
1024 backloged SYNs.)
|
mdw
|
|
response 238 of 248:
|
Dec 17 06:02 UTC 2002 |
The half-open connections are typically from several *different* IP
addresses. So, anything that thinks a syn flood comes from one IP
address isn't going to recognize this. Another technique is just to
randomly close out several connections in the middle of the queue - that
would work better here, but would probably also randomly trash real
connections that were too slow to complete.
"Interrupted system call" isn't something grex can create directly.
This would result from an interrupt caused by some event on the remote
end (such as alarm(2)) that caused a system call to be aborted.
Probably that means something was too slow at grex's end, although that
seems difficult to believe, tcp & standard smtp timeouts are pretty big.
Perhaps it means something quite different.
|
russ
|
|
response 239 of 248:
|
Dec 19 03:28 UTC 2002 |
I just got a piece of mail, delivered 2-something Wednesday morning.
It had been sent at 6:08 AM on Monday.
I got another piece of mail, delivered 3:30 PM Wednesday afternoon.
It had been sent about 7 PM *last Saturday night*.
This mail-refusal problem is way out of hand. Something Must Be Done.
|
gelinas
|
|
response 240 of 248:
|
Dec 19 03:47 UTC 2002 |
Russ, can you look at the Received: lines and tell where it got hung up?
|
jep
|
|
response 241 of 248:
|
Dec 19 14:22 UTC 2002 |
Grex is running really slowly. The load average is down to around 6 right
now, but was up to 19+.
|
keesan
|
|
response 242 of 248:
|
Dec 19 15:29 UTC 2002 |
Still running slowly, on and off. I waited close to a minute to open my
mailbox with Pine (100 plus message, I admit). BBS is okay.
|
russ
|
|
response 243 of 248:
|
Dec 19 23:50 UTC 2002 |
(trying again after crash during upload)
The hangups are getting to Grex; what else? Here are the headers,
with some info abridged.
Received: from FOREIGN.SYSTEM (FOREIGN.SYSTEM [NNN.NNN.NNN.NN]) by
grex.cyberspace.org (8.6.13/8.6.12) with SMTP id CAA17563 for
<russ@cyberspace.org>; Wed, 18 Dec 2002 02:41:57 -0500 Received: (qmail 13305
invoked by uid 0); 16 Dec 2002 11:13:00 -0000 Received: from unknown (HELO
OTHER.SYSTEM) (unknown)
by unknown with SMTP; 16 Dec 2002 11:13:00 -0000
Received: from OTHER.SYSTEM (IDENT:25@localhost [127.0.0.1])
by OTHER.SYSTEM (8.12.6/8.12.6) with ESMTP id gBGBAn6k019152;
Mon, 16 Dec 2002 06:10:50 -0500
Received: (from majordomo@localhost)
by OTHER.SYSTEM (8.12.6/8.12.6/Submit) id gBGB8n3o018402;
Mon, 16 Dec 2002 06:08:49 -0500
Date: Mon, 16 Dec 2002 06:08:49 -0500
From USER@SOMESITE.COM Wed Dec 18 15:31:51 2002
Received: from ashd1-2.relay.mail.uu.net (ashd1-2.relay.mail.uu.net
[199.171.54.246]) by grex.cyberspace.org (8.6.13/8.6.12) with ESMTP id PAA05636
for <russ@cyberspace.org>; Wed, 18 Dec 2002 15:31:49 -0500 Received: from
smtp.SOMESITE.COM by mr1.ash.ops.us.uu.net with SMTP
(peer crosschecked as: SMTP.SOMESITE.COM [NN.NNN.NNN.NNN])
id QQntgq19875
for <russ@cyberspace.org>; Sun, 15 Dec 2002 00:11:46 GMT
Received: from Connect2 Message Router by smtp.SOMESITE.COM
via Connect2-SMTP 4.32; Sat, 14 Dec 2002 19:17:31 -0500
Date: Sat, 14 Dec 2002 19:06:00 -0500
As you can see the first message took more than 44 hours to make the
last hop to Grex; the second took 6 minutes to get to uu.net (note
the time change from EST to GMT, and that the clock at the message
router is fast), and then it took until Wednesday afternoon to get
to Grex (over 92 hours).
That's pretty pathetic. You could get a message round-trip to
Pioneer 11 in about half that time.
|
gull
|
|
response 244 of 248:
|
Dec 20 00:07 UTC 2002 |
Reminds me of sending stuff via packet radio. If it arrived faster than
snail mail, it was a good day.
|
gelinas
|
|
response 245 of 248:
|
Dec 20 00:39 UTC 2002 |
Thanks, Russ.
|
krj
|
|
response 246 of 248:
|
Dec 20 18:44 UTC 2002 |
The RoadRunner ISP has decided to block mail from Grex because
they think Grex is offering an open proxy server.
----------
From daemon Fri Dec 20 02:27:07 2002
Received: from localhost (localhost) by grex.cyberspace.org (8.6.13/8.6.12)
with internal id CAA19965; Fri, 20 Dec 2002 02:27:06 -0500 Date: Fri, 20 Dec
2002 02:27:06 -0500 From: Mail Delivery Subsystem
<MAILER-DAEMON@cyberspace.org> Subject: Returned mail: Remote protocol error
Message-Id: <200212200727.CAA19965@grex.cyberspace.org> To: krj@cyberspace.org
MIME-Version: 1.0 Content-Type: multipart/mixed;
boundary="CAA19965.1040369226/grex.cyberspace.org" Status: R
This is a MIME-encapsulated message
--CAA19965.1040369226/grex.cyberspace.org
The original message was received at Fri, 20 Dec 2002 02:27:01 -0500
from krj@localhost
----- The following addresses had delivery problems -----
XXXXXX@austin.rr.com (unrecoverable error)
----- Transcript of session follows -----
... while talking to txmx01.mgw.rr.com.:
>>> MAIL From:<krj@cyberspace.org>
<<< 550 5.7.1 Mail Refused - 216.93.104.34 - See http://security.rr.com/mai
l_blocks.htm#proxy
... while talking to txmx02.mgw.rr.com.:
>>> MAIL From:<krj@cyberspace.org>
<<< 550 5.7.1 Mail Refused - 216.93.104.34 - See http://security.rr.com/mail_blocks.htm#proxy
----------
... and etc down a whole list of mail servers.
|
tpryan
|
|
response 247 of 248:
|
Dec 21 20:15 UTC 2002 |
(remmers will now probably remind us how he used to send packets
by carrier pigeon, and his ISP number was 3).
|
tsty
|
|
response 248 of 248:
|
Dec 22 08:05 UTC 2002 |
2
|
