|
|
| Author |
Message |
| 25 new of 248 responses total. |
gull
|
|
response 75 of 248:
| 
Oct 14 13:01 UTC 2002 |
Re #72: Nope. Grex has a very ancient version of sshd.
|
albaugh
|
|
response 76 of 248:
|
Oct 21 16:58 UTC 2002 |
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Mon, 21 Oct 2002 11:51:47 -0400
from mwsc0223.mw4.mailwatch.com [204.253.83.164]
----- The following addresses had transient non-fatal errors -----
<someuser@cyberspace.org>
----- Transcript of session follows -----
<someuser@cyberspace.org>... Deferred: Connection timed out with
grex.cyberspace.org.
|
scott
|
|
response 77 of 248:
|
Oct 21 17:41 UTC 2002 |
finger: someuser: no such user.
|
other
|
|
response 78 of 248:
|
Oct 21 17:47 UTC 2002 |
Uptime Report for Grex
Current date and time: Mon Oct 21 13:44:04 EDT 2002
1:44pm up 16 days, 4:19, 65 users, load average: 22.83, 20.20, 17.64
1 waiting, 63 remote + 4 local users; 72 max remote users; 13371 head
|
albaugh
|
|
response 79 of 248:
|
Oct 21 17:48 UTC 2002 |
"someuser" was just a dummy value I edited in (sorry). The real problem was
the connection, not a user. Anyway, seems to be working now...
|
gull
|
|
response 80 of 248:
|
Oct 21 18:58 UTC 2002 |
There's one person I correspond with who cannot send mail to Grex at all
-- it always times out. I suspect, from my own experiences, that the
problem is his ISP firewalls the identd port. When mail connections are
made to Grex, Grex tries to get ident information from the remote host,
and the identd connection takes so long to time out that the sendmail
connection times out as well.
Since very few hosts actually run identd now, and since the information
is so easily forged as to be useless, I'm wondering if it would make
sense for Grex to stop trying to do these lookups. Besides the problem
of hosts that firewall that port being unable to connect, it also adds
overhead to every incoming mail connection, and Grex gets a lot of mail.
|
mdw
|
|
response 81 of 248:
|
Oct 22 01:41 UTC 2002 |
Ident is typically only suported by large timesharing hosts with a
diverse population of users. Since that describes few machines, it's
not surprising that "most" don't do it today. Where it *is* supported,
it's invaluable in terms of tracing e-mail forgeries down. One of those
hosts is grex, and since grex gets a lot of its mail from grex, it would
not make sense for us not collect this information. Besides, the SMTP
timeout value is much larger than the TCP timeout value - and none of
this would have helped Kevin, since it appears he was seeing a TCP
timeout on the initial SMTP, which means the ident protocol was never
involved. Most probably Kevin's failure was some sort of transient
router or network issue - something completely beyond grex's control.
|
russ
|
|
response 82 of 248:
|
Oct 22 03:46 UTC 2002 |
My file transfers with sz keep getting zapped by something. Is
the idle-killer dumb enough to send messages to an active tty
in binary mode?
|
russ
|
|
response 83 of 248:
|
Oct 22 04:20 UTC 2002 |
Yup, seems to be getting nailed about every 15 minutes. Somebody,
please provide a way to shut this idiot thing off...
|
iggy
|
|
response 84 of 248:
|
Oct 22 12:28 UTC 2002 |
*rimshot*
|
gull
|
|
response 85 of 248:
|
Oct 22 12:56 UTC 2002 |
Re #81: Are you sure about the timeout values? My experience indicates
the SMTP connection is not completed if the identd connection doesn't go
through. When I set up a mail system at work about a year ago, it was
unable to send mail to Grex until I unblocked the identd port. I was
completely puzzled by why the connections to Grex, and only Grex, always
timed out until a staffer filled me in on the identd requirement. It
works fine if the host rejects identd connections, but not if it
silently drops the packets.
|
polytarp
|
|
response 86 of 248:
|
Oct 23 00:47 UTC 2002 |
russ should just learn to use FTP.
|
mdw
|
|
response 87 of 248:
|
Oct 23 04:53 UTC 2002 |
I'm guessing that gull got a relatively quick "Connection reset by peer"
and not a slow "Connection timed out". This is one of those cases where
small wording differences in the error message can mean drastically
different things. In fact, grex is likely to work better with firewalls
that silently drop packets than ones that "reject" connections.
Unfortunately, for "reject" some firewalls return ICMP UNREACH messages,
instead of TCP reset (which would be the "expected" behavior if there
were in fact no listener on the port), and grex interprets this to mean
everything on the remote host is now unreachable, rather than just that
one connection. (Granted, there is a icmp subcode that can be used to
further distinguish cause - unfortunately the original bsd tcp/ip code
doesn't check this.) A firewall that rejects ident connections using
TCP reset should work fine with grex, and some are indeed capable of
doing this. Unfortunately, the sort of mentality that blocks ident
connections using a firewall instead of simply not running an ident
service is also the sort that is not likely to understand the difference
between ICMP UNREACH and a TCP reset.
|
gull
|
|
response 88 of 248:
|
Oct 23 14:53 UTC 2002 |
The usual recommended firewall practice is to block everything, then
only enable what you need, instead of trying to block things piecemeal.
I understand the problem with ICMP UNREACH vs. TCP reset, but I don't
have control over how developers choose to implement their firewalls.
Linux iptables, for example, can only respond with ICMP or by silently
dropping the packets. It *is* set to respond with
ICMP-port-unreachable, not ICMP-host-unreachable, by default.
In the case of the mail server I set up, I solved the problem by opening
the identd port specifically, but I don't have the ability to do that on
the mail server of everyone who wants to send me mail. Fortunately only
a minority seem to have this problem, but I expect it'll only get worse.
I also expect fewer and fewer sites will be running identd, since it
leaks information to potential hackers. You can, for example, use it to
determine what userid servers are running as.
|
keesan
|
|
response 89 of 248:
|
Oct 24 01:19 UTC 2002 |
Lynx is not letting me reset my options and save them to disk (I can reset
but it does not stay set despite checking off 'save to disk'). The tab to
next link has never worked and it still redraws the pages up to 5 times, but
reset used to work, I think. I am tired of having labels for images turned
on permanently (bluedot.gif bluedot.gif.....). 2.8.4 version.
|
davel
|
|
response 90 of 248:
|
Oct 29 14:56 UTC 2002 |
Attempts to send mail to Grex are timing out. Grex is up (obviously) and not
entirely off the net - I can telnet in. But attempting to connect to the
sendmail port just hangs until it times out.
Of course, this may be (say) a load-based restriction that will correct itself
eventually, or something like that. Grex feels slow enough to make that seem
all too likely.
|
keesan
|
|
response 91 of 248:
|
Oct 29 17:23 UTC 2002 |
I have not had trouble receiving mail at grex, but I am unable to send to a
particular address since late yesterday. I keep getting back rejected mail
notices. Has something changed at grex, or at their end? I could send
mail to them earlier yesterday.
From MAILER-DAEMON@cyberspace.org Tue Oct 29 12:16:01 2002
Date: Tue, 29 Oct 2002 09:09:24 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@cyberspace.org>
To: keesan@grex.cyberspace.org
Subject: Returned mail: Service unavailable
The original message was received at Tue, 29 Oct 2002 09:09:11 -0500
from keesan@localhost
----- The following addresses had delivery problems -----
<hold@shadow.net> (unrecoverable error)
----- Transcript of session follows -----
... while talking to mail.shadow.net.:
>>> DATA
<<< 552-MessageWall: Message score (1) has reached or exceeded maximum (1):
<<< 552- 1 RFC822/REJECT: keesan@grex.cyberspace.org: Source address must be
in From header <<< 552 MessageWall: This message is being rejected 554
<hold@shadow.net>... Service unavailable
----- Original message follows -----
[ Part 2: "Included Message" ]
Date: Tue, 29 Oct 2002 09:09:07 -0500 (EST)
Lynx also won't accept the command r while viewing the bookmarks file to
remove a line. I have to type e and edit it out instead.
|
albaugh
|
|
response 92 of 248:
|
Oct 29 17:38 UTC 2002 |
This isn't a problem, per se, but an inquiry: A grex account I have personal
knowledge and control of was sent a SPAM e-mail (from a yahoo.com account),
and this grex account has never sent an e-mail, posted in bbs, or participated
in party. So how was the spammer able to know about the existence of this
grex account? Is /etc/passwd exposed or something?
|
tpryan
|
|
response 93 of 248:
|
Oct 29 17:47 UTC 2002 |
1, 2 and 3 letter logins are easy to mass-email. Does the account
fall into this list?
|
keesan
|
|
response 94 of 248:
|
Oct 29 17:53 UTC 2002 |
I have received spam sent to keesan at a number of ISPs, some of them not very
well known. I think they just take logins and combine them with ISP names
and send spam out that way.
Shadow.net knows what the problem is. Yesterday they improved their spam
filter to reject headers of a certain format. They have had complaints from
a few other people who tried to mail their customers from shell accounts, and
they will fix the problem pronto. The phone was answered immediately (no
menu, no wait) by a really knowledgeable support person who spoke perfect
English with a Spanish accent and who diagnosed the problem at once. It is
nice to know some ISPs are competent (unlike AOL, Earthlink....). I recommend
them to anyone living in South Florida.
Webmail might be a good temporary solution to grexers who cannot send mail
to places with this sort of spam filter.
|
albaugh
|
|
response 95 of 248:
|
Oct 29 17:57 UTC 2002 |
The account in question has its ID formed by a common 7-character first name
followed by a 1-character last name (e.g. robertoa). So I guess it's possible
the spammer just got lucky when constructing a target account name. But I'm
still wondering if the information could have come from grex...
|
gull
|
|
response 96 of 248:
|
Oct 29 18:17 UTC 2002 |
It could have. The person would have to be a user first. But it's more
likely it was just random coincidence.
|
albaugh
|
|
response 97 of 248:
|
Oct 29 18:24 UTC 2002 |
OK, so let's say the user *was* a grex user - how does that help him find out
info about other user accounts which are inconspicuous due to lack of
participation? If you don't wish to say because this will encourage other
spammers, I'll understand...
|
gelinas
|
|
response 98 of 248:
|
Oct 29 18:44 UTC 2002 |
The password file can be read by anyone on grex:
} Respond, pass, forget, quit, or ? for more options? !ls -lFg /etc/passwd
} -rw-r--r-- 1 root wheel 2075714 Oct 29 13:29 /etc/passwd
It is kinda big, but there it is.
|
other
|
|
response 99 of 248:
|
Oct 29 19:44 UTC 2002 |
wtmp?
|
