87 new of 248 responses total.
Well, that's what they tell me, but I just can't recall...
Re #159: I was thinking of something more like putting new users into a "no mail" (also no ftp, thus getting rid of donkey) group, and giving people full privs if they become members, have an identifiable USA presence or make a special request. Existing users would not be affected. Getting rid of donkey might be worth the whole effort.
We disable accounts which do automated stuff anyway, so it's probably not as big a problem as it appears. The big edonkey problem was just excessive clueless bots trying to connect, which somebody could do maliciously anyway.
re #159: > giving people full privs if they .. have an identifiable USA presence.. I can't decide whether or not I'd like to hear your rationalization for this proposal or not..
This response has been erased.
Re #157: It's not mail *from* Grex that's the problem, it's mail *to* Grex. The problem has eased up for me a bit, lately, though I do still occasionally see mailing list mail arrive out of order (which indicates a batch of it didn't go through on the first attempt.)
yeah, I'm still getting reports about mail that bounced from my grex address. From the AATA, so it shouldn't be spam filtered.
Hola, Why was grex down???????? was it because of the new backtalk update?
Grex was down because of some kind of power blip, apparently.
The modems were ringing open around 6 PM. Dunno if this was a Grex problem or a modem problem.
Re #165: Mostly because it's likely that someone coming in through our dialups is in the USA, and we could automagically include IP blocks belonging to US ISPs if it became an issue. India and Brazil are no worse off for computers than Ann Arbor was when Grex was founded; let them follow our example. Re #166: What part of "or makes a special request" was obscure? The point is to reduce Grex's mail load (and potential for abuse) by adding a hoop to jump through before being able to add to the load. Other sites are much better suited to handling it than we are.
Are you suggesting that groups of people in India, making $80/month each if they are lucky or nothing if they are students, get together and pay for a fast internet connection? Some of them have really slow connections right now and Yahoo takes a lot longer to use than grex even at its worst. Ever had a chat with someone who types a sentence then you both wait 30 sec for it to appear?
re #172: but I'm still not clear on why American users rate special privileges under your reasoning. What is it that makes a user from Atlanta, GA, or Pierre, SD more desirable than one from Madras or Yogjakarta or Rio de Janeiro?
I think he's thinking in terms of "community service".
There's nothing inherently wrong with the idea. Community credit
unions won't give accounts to someone from Rio de Janeiro, either, if they
don't have local relatives, but there's nothing immoral about it. It just
doesn't seem to be the way that GREX is set up to be.
This response has been erased.
Philosophical discussions about Grex, its community and its services need to be in SOME OTHER ITEM, not the System Problems report.
Join Coop for a place to discuss the management of Grex.
This response has been erased.
The mail delays are pretty bad. I received some e-mail at about 7:20 PM which was sent at about 5:30 PM.
I've seen worse than that, lately. What's going on?
I've seen much worse than that.
The original message was received at Mon, 9 Dec 2002 11:08:17 -0500 from keesan@localhost ----- The following addresses had delivery problems ----- <XXXX@bluegrass.net> (unrecoverable error) ----- Transcript of session follows ----- ... while talking to mail.bluegrass.net.: >>> RCPT To:<XXXX@bluegrass.net> [The XXXX's are mine to hide the personal address] <<< 554 Service unavailable; Client host [216.93.104.34] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?216.93.104.34 Spamcop has a list of blocked IPs from which spam originates. They take you off the list after a week of no spams, I think. Is there some way to ask them to take grex off permanently and just send us a list of spammers to delete their accounts instead?
Here is what I got when I entered 216.93.104.34 into the form at spamcop -
10 reports of spam from grex, with a sampling of the originating
addresses, and a list of the many other times grex has been blacklisted
this year, sometimes for 1 minute, sometimes for 10 days.
Query bl.spamcop.net - 216.93.104.34
216.93.104.34 listed in bl.spamcop.net.
216.93.104.34 Qty Most Recent Oldest
Spam reports: 10 42.87 hours ago
Sat Dec 7 23:21:19 2002 GMT 45.36 hours ago
Rationale: Spam score 10.00: spam report ratio (10.000) exceeds
threshold (0.020)
Samples of reported spam:
Reportid: 132139819 dated Sat Dec 7 23:12:51 2002 GMT
Return-Path: <tmobile@grex.cyberspace.org>
Received: from mb1i0.ns.pitt.edu (mb1i0.ns.pitt.edu [136.142.186.35])
by imap.srv.cis.pitt.edu with ESMTP (8.8.8/8.8.8/cisimap-7.2.2.4)
ID <SAA20065@imap.srv.cis.pitt.edu>;
Sat, 7 Dec 2002 18:12:52 -0500 (EST)
Received: from grex.cyberspace.org ([216.93.104.34])
by pitt.edu (PMDF V5.2-32 #41462)
with SMTP id <01KPRD2OSGBG004HJ1@mb1i0.ns.pitt.edu>; Sat,
7 Dec 2002 18:12:51 EST
Received: from localhost (tmobile@localhost)
by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id SAA20366; Sat,
07 Dec 2002 18:08:14 -0500
Date: Sat, 07 Dec 2002 18:08:12 -0500 (EST)
From: Kenneth <>
Subject: *** HOLIDAY SEASON SPECIALS FROM T-MOBILE ***
To: x
Message-id: <Pine_________________________________0000@grex.cyberspace.org>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Reportid: 123931890 dated
Sun Nov 10 09:16:13 2002 GMT
Status: U
Return-Path: <admin9@cyberspace.org>
Received: from grex.cyberspace.org ([216.93.104.34])
by killdeer (EarthLink SMTP Server) with SMTP id 18aOct1p33NZFlr0
for <x>; Sun, 10 Nov 2002 01:16:13 -0800 (PST)
Received: (from admin9@localhost) by grex.cyberspace.org (8.6.13/8.6.12) id EAA
08366 for x; Sun, 10 Nov 2002 04:17:24 -0500
Date: Sun, 10 Nov 2002 04:17:24 -0500
From: null <>
Message-Id: <2002_____________8366@grex.cyberspace.org>
To: x
[HERE IS A SUMMARY OF ALL THE TIMES GREX GOT ON THE SPAMCOP BLACKLIST]
Listing history:
listed: Sun Nov 25 13:33:01 2001 GMT
delisted: Mon Nov 26 09:20:01 2001 GMT
listed: Sat Feb 9 08:22:01 2002 GMT
delisted: Sun Feb 10 03:57:01 2002 GMT
listed: Thu Apr 25 21:39:01 2002 GMT
delisted: Mon May 6 04:11:01 2002 GMT
[This was for a longer period]
listed: Sun Nov 10 09:34:02 2002 GMT
delisted:Wed Nov 13 09:48:01 2002 GMT
[This sounds like about the time I was unable to write my ISP.]
listed:Sat Dec 7 21:47:01 2002 GMT
delisted:Sat Dec 7 22:43:03 2002 GMT
[Delisted after one minute!]
listed: Sun Dec 8 00:54:02 2002 GMT
-----------
Grex has been on the blacklist since Sunday just after midnight.
Would it help to post this sort of info in the motd so people can expect
to get their mails bounced back and know when to resend them?
--------------
References
6. http://spamcop.net/
Another note on the 'delayed email' conversation. I just an email early this afternoon that had been sent at 8 pm last night.
Spamcop apparently puts you on the list first and doesn't tell you
afterwards. There's no way a public access system like grex can
guarantee it will stay off such a list. There's also no way such any
system that *uses* such a list can guarantee reliable mail - because the
list itself does not have adequate checks for abuse or mistakes.
Spamcop.net itself grudgingly acknowledges this feature but doesn't
explain why it's inherent in their design:
http://spamcop.net/bl.shtml
I don't see why there's any reason we should make any announcements
regarding this list - any more than we should list when any other mail
service provider goes down for any reason.
I was reading the conferences and when I quit , I got logged out of grex .. Below is what appeared on my screen Respond, pass, forget, quit, or ? for more options? p Browse (item list), Read (new items), Join confname (type "help conf" for a list of conferences), Help (for more help), pine (for e-mail) Quit (to exit) or !change (to change settings). Ok: Read from remote host grex.org: Connection reset by peer Connection to grex.org closed. [ary@mp17 ~]$
Sounds like a timeout or network glitch. If you got kicked off by the idle killer, it would have printed a message.
resp:186 (Spamcop *will* pass along reports, if requested. it would
relatively easy to guess, based on those reports, whether
Grex were a prime candidate for blacklisting.)
http://spamcop.net/fom-serve/cache/94.html
(me, I find it refreshing to know that Grex has only been on Spamcop's
blacklist six times in the past year, and, excepting the late April-
early May period [which appears to be an aberration], for less than
seven days. that's about 98% off-list, right?)
(the "admin9" account appears to have been a toss-away.)
Given the way Spamcop operates, any site that uses it for rejecting mail is being irresponsible to their users. It's too sensitive, and too easy to abuse. I've used Spamcop, but only for tagging mail to shunt into my Junk Mail folder, like I would use a content-based filter.
I just asked the person to whom I cannot send grex email for a week because of spamcop to ask his ISP to stop using spamcop's blacklist.
Spamcop apparently sends its reports to grex to "uce@" - which is not required by any RFC and which we don't review on a regular basis. I found the spamcop report for Nov 6 - the block seems to have been triggered by spam forwarded *through* grex via a .forward to a certain chinet account, and thence off to spamcop Nov 7. So the particular spam responsible for this problem wasn't even originated *on* grex. Ironically, spamcop's use of uce@ for this mail *was* appropriate; sites that block grex based on this are deliberately sacrificing mail reliability and not using spamcop's blocking service the way they recommend.
Is it possible to change things so that mail cannot be forwarded through grex, or would that interfere with normal use of grex mail?
Well, a lot of people, including me, forward mail from grex. So yes, it would interfere with "normal" use of grex mail. It could be argued that grex shouldn't be in the mail forwarding business.
This response has been erased.
resp:192 (wrong, wrong, wrong.)
(1. SpamCop reports for 216.93.104.34 are currently sent
to abuse@voyager.net. see http://spamcop.net/sc?track=216.93.10
4.34
for details.)
(2. if I receive spam at my Grex address, which forwards to my
Chinet account, and file a SpamCop report, I regularly forward
a copy of that report to uce@grex. this is likely what you are
seeing in the uce inbox.)
(3. there was no SpamCop block on Grex on November 6. you
either must be subconsciously combining the two separate dates
of November 10 and December 7 or not reading carefully. either
way, keesan already cited the two spams sent from Grex that
caused those blocks in an earlier response. you can see them
for yourself at
http://spamcop.net/w3m?action=checkblock&ip=216.93.104.34
I've checked my report #s and can verify that I did *not*
submit either report. of course, I didn't get the spam,
either.) ;)
(re: misinformation keesan is spreading over in coop: Grex was delisted
on the 9th of December. two days is not a week.)
(I concur with all earlier responses regarding the use of SpamCop's
blacklist, namely that it's Not A Good Idea to use it.)
Thanks for the delisting information. I will now go back to using grex for sending email to places that use spamcop's list. (I discovered along the way that the free webmail service I was forwarding through instead converts all text attachments to MIME, that my intended recipient's Netscape mail cannot handle MIME attachments, and that my ISP's webmail not only cannot forward attachments but cannot read MIME attachments either!!!!!). Pine is great! Spamcop said they automatically delist sites in a week - I did not understand the details of when they sometimes delist in less time than this. Can you explain that?
Hmm.... Never heard of a version of Netscape mail that didn't handle MIME attachments.
Possibly she means the "My Netscape"-portal web-based e-mail, not the GUI mail client that comes bundled with Navigator?
My intended recipient only said 'Netscape'. I asked for more info. My ISP's web-based email does not handle MIME. I have not checked if Yahoo mail does so (probably it does) but I am about to check Pine 3.96 at grex because I think it had trouble with this same mail when I forwarded it back. Pine 3.96 is the latest version of pine that does not render HTML. Pine is now up to version 4.50. Grex might want to consider switching. Just about everyone we have taught to use grex mail phones or emails asking what to do about html mail - their usual solution is to ignore it. If the sender included text as well you can do a Reply to read the text part, but our beginners cannot handle View, Save, Exit, Quit, view with Lynx, print to text, exit lynx, return to pine, go back to the mail, do a reply, and import the text output from lynx. Should I bring this up in co-op?
I forwarded the email with text attachment (which I could read with Pine 3.96) from grex to the free webmail service (where I could read the attachment) and then back to Grex. I cannot read the attachment with Pine after forwarding it there and back - View gives me the message [Can't display missing text segment]. The free webmail service converts the text attachment to a MIME encoded attachment. If they have done this properly, should Pine be able to decode and display it as text? The ISP webmail service simply did not display any attachment at all - I don't think it can handle MIME encoding, but possibly there is something wrong with the encoded version. This ISP webmail service received the attachment - I can see the upper-case ASCII when I view the HTML version of the page - just does not display it. It says there is 1 attachment.
I opened a new account at m-net and they have Pine 4.44 which has the new feature 'Export as plain text file' to deal with html messages, but still cannot read the MIME-encoded attachment from the free webmail service. I wonder if they encoded it improperly.
Here is the message I found in uce@. I'm afraid I botched the date
above; so shoot me, I'm human. Note date: Dec 7: note it was sent from
spamcop not Carson: note this is the *only* message I found from
julianhaight.com going to any administrative account on grex for the
past 2 weeks. I suppose it's possible this isn't the actual message
that triggered the block, if so, then we've received *no* notification
for the block. I don't blame Carson for any of this - I believe spamcop
fails in an unfortunate way, and did so here:
From 131441976@bounces.spamcop.net Sat Dec 7 00:24:48 2002$
Received: from saruman.julianhaight.com (saruman.julianhaight.com
[216.127.43.87]) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id
AAA07159 for <uce@grex.org>; Sat, 7 Dec 2002 00:24:46 -0500$ Received:
(qmail 11842 invoked from network); 7 Dec 2002 05:16:28 -0000$
Received: from localhost (HELO spamcop.net) (127.0.0.1)$
by saruman.julianhaight.com with SMTP; 7 Dec 2002 05:16:28 -0000$
Received: from [204.38.207.130] by spamcop.net$
^Iwith HTTP; Sat, 07 Dec 2002 05:16:28 GMT$
From: "Carson" <131441976@reports.spamcop.net>$
To: uce@grex.org$
Subject: [SpamCop (Forwarded Spam) id:131441976]*****SPAM***** Try a
FREE 30 Day Sample of HGH !$ Precedence: list$ Message-ID:
<131441976@spamcop.net>$ Date: Sat, 7 Dec 2002 12:40:40 +0900$
X-SpamCop-sourceip: 203.145.15.153$ X-Mailer: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; NMU; .NET CLR 1.0.3705)$ ^Ivia
http://spamcop.net/ v1.3.3$ $ - SpamCop V1.3.3 -$ This message is
brief for your comfort. Please follow links for details.$ $ http:/
/spamcop.net/w3m?i=z131441976z3568a9fae07466db073765233c498529z$ User-targeted
report, see notes, if any.$ $ Offending message:$ Received: from
grex.cyberspace.org (grex.cyberspace.org [216.93.104.34])$ ^Iby
chinet.chinet.com (8.12.3/8.12.3/SuSE Linux 0.6) with SMTP id
gB73gtZ4020503$ ^Ifor <x>; Fri, 6 Dec 2002 21:42:56 -0600$ Received:
from www.kocomnet.com ([210.205.61.9]) by grex.cyberspace.org
(8.6.13/8.6.12) with ESMTP id WAA26182; Fri, 6 Dec 2002 22:44:12 -0500$
Received: from email-com.mr.outblaze.com ([203.145.15.153])$
^Iby www.kocomnet.com (8.9.3/8.9.3) with ESMTP id MAA24893;$ ^ISat,
7 Dec 2002 12:40:40 +0900$ Message-ID:
<0000______________________2f96@email-com.mr.outblaze.com>$ To: <x>$
From: "dustin ketchum" <>$ Subject: *****SPAM***** Try a FREE 30
Day Sample of HGH !$ Date: Sat, 07 Dec 2002 10:40:22 -0500$
MIME-Version: 1.0$ Content-Type: text/plain$
Content-Transfer-Encoding: 7bit$ Reply-To: fmaperezr@email.com$
X-Mailer: Microsoft Outlook, Build 10.0.2616$ X-Spam-Status: Yes,
hits=11.6 required=5.0
tests=FAKED_UNDISC_RECIPS,PLING,GAPPY_TEXT,CLICK_BELOW,ONE_HUNDRED_PC_GU
AR,GUARANTEE,SUPERLONG_LINE,RCVD_IN_ORBS,RCVD_IN_RFCI version=2.20$
X-Spam-Flag: YES$ X-Spam-Level: ***********$
X-Spam-Checker-Version: SpamAssassin 2.20 (devel $Id:
SpamAssassin.pm,v 1.77 2002/04/06 19:28:30 hughescr Exp $)$
X-Spam-Prev-Content-Type: text/plain;$ ^Icharset="Windows-1252"$
X-Spam-Prev-Content-Transfer-Encoding: 7bit$ $ $ SPAM:
-------------------- Start SpamAssassin results ----------------------$
SPAM: This mail is probably spam. The original message has been
altered$ SPAM: so you can recognise or block similar unwanted mail in
future.$ SPAM: See http://spamassassin.org/tag/ for more details.$
SPAM: $ SPAM: Content analysis details: (11.6 hits, 5
required)$ SPAM: Hit! (3.4 points) Faked To "Undisclosed-Recipients"$
SPAM: Hit! (0.5 points) Subject has an exclamation mark$ SPAM:
Hit! (-1.2 points) BODY: Contains 'G.a.p.p.y-T.e.x.t'$ SPAM: Hit! (1.5
points) BODY: Asks you to click below$ SPAM: Hit! (4.4 points) BODY:
One hundred percent guaranteed$ SPAM: Hit! (1.9 points) BODY: Contains
word 'guarantee' in all-caps$ SPAM: Hit! (-0.4 points) BODY: Contains a
line >=199 characters long$ SPAM: Hit! (1.0 point) Received via a
relay in orbs.dorkslayers.com$ SPAM: [RBL check:
found 9.61.205.210.orbs.dorkslayers.com.]$ SPAM: Hit! (0.5 points)
Received via a relay in ipwhois.rfc-ignorant.org$ SPAM:
[RBL check: found 9.61.205.210.ipwhois.rfc-ignorant.org., type:
127.0.0.6]$ SPAM: $ SPAM: -------------------- End of SpamAssassin
results ---------------------$ $ $ $ Younger and healthier with
ULTIMATE-hGH: all-natural human growth hormone supplement designed to
stimulate own production of growth hormone (hgh)!$ $ As seen on N.B.C.,
C.B.S., C.N.N., and even OpRah!! The health discovery that
actuallyreverses aging while burning fat, without dieting or exercise!
This provendiscovery has even been reported on by the New England
Journal of Medicine.Forget aging and dieting forever! And it's
Guaranteed! $ $ Click below to enter our web site:$ http://www.game
towncastle.com/hgh/$ $ Would you like to lose weight while you sleep!$ No
dieting!$ No hunger pains!$ No Cravings!$ No strenuous exercise!$
Change your life forever! $ $ 100% GUARANTEED!$ $ 1.Body Fat Loss 82%
improvement.$ 2.Wrinkle Reduction 61% improvement.$ 3.Energy Level 84%
improvement.$ 4.Muscle Strength 88% improvement.$ 5.Sexual Potency 75%
improvement.$ 6.Emotional Stability 67% improvement.$ 7.Memory 62%
improvement.$ $ Click below to enter our web site:$ http://www.game
towncastle.com/hgh/$ $ $ **************************************************$ If
you want to get removed$ from our list please visit - http://www.ga
metowncastle.com/rm/rm.html$
**************************************************$ $ $ $
(yep, that's a report I forwarded to uce because the original message was sent to me here. I suppose that begs the question of whether the information in the report is at all useful; the reason that I forward them is because Marcus had asked for examples of spam sent to Grex. anyway, I've already gone over where SpamCop sends reports for Grex [they go upstream to abuse@voyager, not to Grex]; for that reason, I highly doubt that any such reports would have been forwarded to Grex.) (http://spamcop.net/fom-serve/cache/94.html explains how to go about getting those reports sent to Grex. there's a form to fill out at http://spamcop.net/w3m?action=routeform that may require assent from someone at Voyager.) (re: delisting: SpamCop automatically delists an address if there are no reports against it within the past 48 hours. for whatever reason, that's not in the FAQ, but it is explained on the query page.) (it looks like Grex is particularly vulnerable to SpamCop blocking because of a low spam threshold [0.020 spam per non-spam] and because we aren't sending enough legitimate e-mail to systems that use the blocking list [catch-22?]. perhaps this whole thing deserves its own item...)
(both "tmobile" and "admin9" have existing accounts on Grex. I find the "last login" dates amusing, for obvious reasons.)
Not bvious to me, I'm afraid.
(the "last login" dates are when the accounts sent the spam that put Grex on SpamCop's blacklist, i.e., they've likely only been used once.)
The report wouldn't have appeared to come from carson. Spamcop deliberately munges the addresses, to prevent spammers from retaliating or reselling them.
Re #207: Ah. Thanks.
Over the past month or so, e-mail to me from non-Grex sources is often *seriously* delayed. This morning's collection has an e-mail sent to me from umich.edu on Dec. 10 at 3:06 p.m. which did not arrive at Grex until Dec. 12 (today) at 4:27 a.m. My wife and I frequently get duplicate e-mails from the same sender(s). She has a Comcast account. Her e-mails arrive almost immediately after they are sent. Mine are delayed for up to a day! What is happening here?
Marcus talked about that problem a bit at last night's board meeting. He's not sure but thinks it might be a (possibly inadvertent) form of denial-of-service attack. He's investigating. I'll let him explain more fully if he wishes.
Re #211: Thanks. I don't know about other people here, but mostly I just wanted to know that the problem was being taken seriously and investigated. :)
Thanx! The problem is quite annoying. An e-mail was sent to me from aadl.org (the Library) on Wednesday, Dec. 11 at 5:36 p.m. and I didn't receive it until today, Dec. 13, at 3:32 a.m.
It's causing havok on the Grex staff list as staffers answer questions multiple times because the answers cross each other in flight by hours.
I think I better understand why mail got slow. We apparently have at least 3 different spammers trying to connect to grex, but failing to do so. Presumably there's a firewall, possibly at their end, perhaps in the middle, that drops packets from grex to the spammers. The half-open connections occupy slots in the input queue, and there are only a limited number of such connections that are permitted to exist. After those slots fill up, other connection attempts are silently ignored. Since the 3 spammers have at least 20 IP addresses between them, they're doing a pretty good job of keeping those slots full. And, since we never actually get any connections from them, let alone mail, they don't appear in our logs at all. This is certainly going to be "interesting" to fix. So far, a few simple things I tried haven't been useful, but there are certainly any number of not so simple fixes we can do. I suppose we should be thankful that we don't get the spam.
Are we running any sort of IP filtering SW that can simply block those IP addresses completely or don't we have the horsepower for that?
Can you simply write to these spammers, point out to them that the mail is not getting through to grex anyway but they are disabling our system, and ask them to 'delist' us (stop sending things in our direction)?
Thanks for keeping us informed, Marcus. What a problem!
This response has been erased.
It's been a long time since I've dealt with something like this but it seems at first glance that a simple package like tcp_wrappers should be fine for this, I don't think you need full bpf-style flexibility.
We can completely block their IP ranges, and we routinely put such blocks in place. However, there appear to be quite a few legit users who connect from those ranges, so we'd prefer not to block them entirely if possible. Besides, if Marcus can fix this problem, then this won't happen in the future. I'd say blocking the range is a last resort.
(I'd say blocking the range is a first, temporary measure, but that's a discussion for another conference.)
What is an IP range? Can you block just specific IP numbers rather than a range, and if legitimate users are also using those IP numbers can the ISP be asked to cancel just those accounts or is this a free mail service where they keep signing up for new accounts? Or am I confused?
Tcp wrappers can't help - they work at the user level; this problem isn't even visible at the user level, so there's no way to use it to reject connections. The DSL router has a limited capability of filtering packets, but we don't administer it, so that's not useful to us. obsd pf would be quite capable of that, but we're not on openbsd yet, and an obsd pf firewall of some sort would also work, but that's quite a bit of work. It may be worth doing this anyways, but it's not going to happen this weekend. My current plan is to try to write something that can "sniff" the wire, detect when grex tries to complete a connect to a set of bad IP ranges, and send packets to grex to cause the connections to be aborted. I tried to do just this last night, but I'm afraid lack of sleep was catching up fast with me and I didn't succeed in getting this to work. I'm going to try to debug this separately outside of grex where I can better figure out what's happening, and hope to have better luck making this work with grex tomorrow.
(#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?)
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.
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?
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.
This response has been erased.
(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.)
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.
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.
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.
Ahh.. Ok, now I get it.
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.
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.
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.)
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.
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.
Russ, can you look at the Received: lines and tell where it got hung up?
Grex is running really slowly. The load average is down to around 6 right now, but was up to 19+.
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.
(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.
Reminds me of sending stuff via packet radio. If it arrived faster than snail mail, it was a good day.
Thanks, Russ.
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.
(remmers will now probably remind us how he used to send packets by carrier pigeon, and his ISP number was 3).
2
You have several choices: