Archive-Date: Thu, 11 Oct 2001 00:55:04 -0700 Message-ID: <009101c1522a$21f8ebb0$180110ac@sysman> From: "Ruslan R. Laishev" Reply-To: MX-List@MadGoat.com To: Subject: Re: REJECTION rules ID Date: Thu, 11 Oct 2001 11:55:45 +0400 Hello Matt, All. Is there an ability to add an rejection rule ID to track rejections events? We have a huge number of rules and sometime we are not abble to find what exactly rule have caused to rejection. ================================================================================ Archive-Date: Thu, 11 Oct 2001 05:43:20 -0700 Subject: Re: REJECTION rules ID From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3bc58e34@news.kapsch.co.at> Date: 11 Oct 2001 14:19:00 +0200 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <009101c1522a$21f8ebb0$180110ac@sysman>, "Ruslan R. Laishev" writes: >Hello Matt, All. > Is there an ability to add an rejection rule ID to track rejections >events? We have a huge number of rules and sometime we are not abble to find >what exactly rule have caused to rejection. Do you use the most recent MX version ? Matt added such a feature in one of the latest versions or maybe ECOs. I do see messages like: %%%%%%%%%%% OPCOM 11-OCT-2001 13:39:30.13 %%%%%%%%%%% Message from user SYSTEM on xxxxxx MX SMTP server: rejected message from sent by [a.b.c.d] due to RFC822 header rule [X-Date-Warning: Date header inserted by *] Maybe it doesn't work for all rules (I haven't checked this for a loong time now) and maybe it doesn't work for exclusion rules, but there is something to get started with. Could you please be more specific... -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 11 Oct 2001 05:50:12 -0700 Message-ID: <3BC595AE.9D2DAB88@SMTP.DeltaTel.RU> Date: Thu, 11 Oct 2001 16:50:54 +0400 From: "Ruslan R. Laishev" Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: MX-List@MadGoat.com Subject: Re: REJECTION rules ID References: <3bc58e34@news.kapsch.co.at> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi Peter, thanks, let me check it. Peter LANGSTOEGER wrote: > > In article <009101c1522a$21f8ebb0$180110ac@sysman>, "Ruslan R. Laishev" writes: > >Hello Matt, All. > > Is there an ability to add an rejection rule ID to track rejections > >events? We have a huge number of rules and sometime we are not abble to find > >what exactly rule have caused to rejection. > > Do you use the most recent MX version ? > Matt added such a feature in one of the latest versions or maybe ECOs. > I do see messages like: > > %%%%%%%%%%% OPCOM 11-OCT-2001 13:39:30.13 %%%%%%%%%%% > Message from user SYSTEM on xxxxxx > MX SMTP server: rejected message from sent by [a.b.c.d] due to RFC822 > header rule [X-Date-Warning: Date header inserted by *] > > Maybe it doesn't work for all rules (I haven't checked this for a loong time > now) and maybe it doesn't work for exclusion rules, but there is something > to get started with. Could you please be more specific... > > -- > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 > Network and OpenVMS system manager Fax. +43 1 81111-888 > <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net > A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" -- Cheers, +OpenVMS [Sys|Net] HardWorker .......................................+ Russia,Delta Telecom Inc, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 +http://starlet.deltatel.ru ................. SysMan rides HailStorm + ================================================================================ Archive-Date: Thu, 11 Oct 2001 05:50:57 -0700 Date: Thu, 11 Oct 2001 14:50:27 +0200 From: Leyrat@criuc.unicaen.fr Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <00A035EC.87659745.74@clenche.unicaen.fr> Subject: On holiday Je suis absent jusqu'au 12 novembre. Pour tout probleme concernant: merci de vous adresser a: messagerie, news, systemes Unix Marie-Claire Davy p. 6210 DNS, reseau Francois Moret p. 6255 Securite Gerard Jean-Francois p. 6208 ================================================================================ Archive-Date: Fri, 12 Oct 2001 03:36:42 -0700 Subject: Re: REJECTION rules ID From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3bc6c6cb$1@news.kapsch.co.at> Date: 12 Oct 2001 12:32:43 +0200 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <3BC595AE.9D2DAB88@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > thanks, let me check it. Look for MX_SMTP_REJECTION_EVENT_CLASS logical -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Thu, 18 Oct 2001 14:24:00 -0700 Message-ID: <5.1.0.14.0.20011018235412.032a0e70@juhani.decus.fi> Date: Fri, 19 Oct 2001 00:27:34 +0300 To: MX-List@MadGoat.com From: Esa Laitinen Reply-To: MX-List@MadGoat.com Subject: Problems with rejman header rejection rules when using RBL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi! I'm using MX 5.2 on Alpha. I have had a nagging feeling for quite some time that rejman header based rejection rules don't work, and today I had the time to test it out. This is what I found out: if you use RBL you'll loose header based rejections. Here are the relevant log entries when MX_ANTI_SPAM_DEBUG is set at 2: First without RBL: 18-OCT-2001 23:48:02.30 : Source address did not match an inside network 18-OCT-2001 23:48:12.28 : in IS_LOCAL_DOMAIN, checking iname.com (source address) 18-OCT-2001 23:48:12.32 : IS_LOCAL_DOMAIN: no 18-OCT-2001 23:48:12.39 : IS_SPAM: candidate is user=punkki, dom=iname.com, addr=212.226.136.69 18-OCT-2001 23:48:12.53 : ESPAM_MATCH: addr=212.226.136.69, sender=, rcpt={none} 18-OCT-2001 23:48:12.64 : in IS_LOCAL_DOMAIN, checking iname.com (source address) 18-OCT-2001 23:48:12.69 : IS_LOCAL_DOMAIN: no 18-OCT-2001 23:48:17.81 : in VERIFY_RESET_CHECK... 18-OCT-2001 23:48:17.91 : shutting_down=0 18-OCT-2001 23:48:17.95 : reset_mask=00000000 18-OCT-2001 23:48:18.07 : rejection count=0 18-OCT-2001 23:48:18.16 : NORELAY set -- will do relay check 18-OCT-2001 23:48:18.26 : will parse 18-OCT-2001 23:48:18.35 : in IS_LOCAL_DOMAIN, checking decus.fi (destination address) 18-OCT-2001 23:48:18.45 : -- match, found matching LOCAL path 18-OCT-2001 23:48:18.54 : rewrote address to: laitinen, next hop decus.fi.$$FILTER$$ 18-OCT-2001 23:48:18.88 : FINDPATH status was 00000001, pathid 7 18-OCT-2001 23:48:19.05 : VERIFY_ADDRESS final status=251, outstr="2.1.5 Will forward to " 18-OCT-2001 23:48:19.21 : ESPAM_MATCH: addr=212.226.136.69, sender=, rcpt= 18-OCT-2001 23:49:19.98 : in IS_SPAM_HEADER 18-OCT-2001 23:49:20.07 : candidate hdr code=18, matching against 24 18-OCT-2001 23:49:31.85 : candidate hdr code=24, matching against 24 18-OCT-2001 23:49:31.94 : -- match occurred, count now 1 Then with RBL: 18-OCT-2001 23:43:10.84 : Source address did not match an inside network 18-OCT-2001 23:43:21.01 : in IS_LOCAL_DOMAIN, checking iname.com (source address) 18-OCT-2001 23:43:21.15 : IS_LOCAL_DOMAIN: no 18-OCT-2001 23:43:21.29 : IS_SPAM: candidate is user=punkki, dom=iname.com, addr=212.226.136.69 18-OCT-2001 23:43:21.43 : ESPAM_MATCH: addr=212.226.136.69, sender=, rcpt={none} 18-OCT-2001 23:43:21.55 : in IS_LOCAL_DOMAIN, checking iname.com (source address) 18-OCT-2001 23:43:21.67 : IS_LOCAL_DOMAIN: no 18-OCT-2001 23:43:27.82 : in VERIFY_RESET_CHECK... 18-OCT-2001 23:43:27.91 : shutting_down=0 18-OCT-2001 23:43:27.99 : reset_mask=00000000 18-OCT-2001 23:43:28.10 : rejection count=0 18-OCT-2001 23:43:28.20 : NORELAY set -- will do relay check 18-OCT-2001 23:43:28.28 : will parse 18-OCT-2001 23:43:28.39 : in IS_LOCAL_DOMAIN, checking decus.fi (destination address) 18-OCT-2001 23:43:28.48 : -- match, found matching LOCAL path 18-OCT-2001 23:43:28.58 : rewrote address to: laitinen, next hop decus.fi.$$FILTER$$ 18-OCT-2001 23:43:28.69 : FINDPATH status was 00000001, pathid 7 18-OCT-2001 23:43:28.75 : VERIFY_ADDRESS final status=251, outstr="2.1.5 Will forward to " 18-OCT-2001 23:43:28.81 : ESPAM_MATCH: addr=212.226.136.69, sender=, rcpt= Seems to me that MX doesn't enter IS_SPAM_HEADER routine at all if RBL is used. The log file extracts are from ECO02. ECO05 exhibits the same problem (I just tested it). esa ================================================================================ Archive-Date: Tue, 30 Oct 2001 05:43:00 -0800 Subject: Re: removing the mx% From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3bdea75b$1@news.kapsch.co.at> Date: 30 Oct 2001 14:12:59 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <1004444192.17455.0.nnrp-08.9e989e7e@news.demon.co.uk>, "Chris Sharman" writes: >We've had mx (5.0) running & stable for a long time, working well. >Incoming messages have mx%" " around each from, to, and cc email address, >which isn't a problem on VMS. >However, when the email's downloaded to a PC via IUPOP3, the mx%" " remains >on the to & cc lines, causing all the addresses to need editing on >reply/all. >Have we got something misconfigured, or is there a fix for MX or IUPOP3 >please ? Try setting IUPOP3_DEFAULT_TO_SMTP and IUPOP3_IGNORE_MAIL11_HEADERS to TRUE (don't forget IUPOP3_ENABLE_LONG_LINES as TRUE) Try also avoiding the MX% prefix completely by using SMTP% instead (defining MX_PROTOCOL_PREFIX as "SMTP%") so that a (unexpected/quick-test/usual) IP stack change (or IP stack coexistance in the cluster) doesn't harm VMSmail. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 31 Oct 2001 06:18:50 -0800 Message-ID: <047f01c16216$dfb0e800$c68387c0@ulm.edu> From: "eppinette" Reply-To: MX-List@MadGoat.com To: Subject: Anti-relay problem Date: Wed, 31 Oct 2001 08:18:12 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047C_01C161E4.94F4E640" This is a multi-part message in MIME format. ------=_NextPart_000_047C_01C161E4.94F4E640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I've started having a problem recently with anti-relaying settings. Within the last week my MX system has been placed into the ORDB.ORG = database and I can't determine why their system is classing my box as an open-relay. Hopefully someone thru this list can help shed some light on the = problem. I was running MX 5.1-X, but I upgraded it last night to 5.2 in an = attempt to solve the problem - no luck. I am running OpenVMS V7.2-1 over MultiNet V4.1 Rev A-X with MX V5.2-X I've set the norelay option for MX (which had been set for some time) The smtp logs where showing that the system was working well because = there where numerous rejected messages due to disabled relay. I still = occasionally get these rejection statements, but not as often. I've had a couple of "inside network" entries on my system for sometime = as well that designate my local network. And I've got several entries in "local domains" to indicate my domain = styles. Like I said all had been working fine until about a week ago. This log entry was one of the test that ORDB attempted: 30-OCT-2001 23:14:28.26: MX SMTP server: rejected message from = to sent by [62.242.0.190] due = to disabled relay This is the header of what supposedly failed from the test returned by = ORDB: Return-Path: Delivered-To: marvin@groundzero.ordb.org Received: from alpha.ulm.edu (alpha.ulm.edu [192.135.131.100]) by groundzero.ordb.org (Postfix) with ESMTP id 2AE595B104 for ; Wed, 31 Oct 2001 06:14:12 +0100 (CET) Received: from groundzero.ordb.org (62.242.0.190) by alpha.ulm.edu (MX = V5.2-X An7g) with ESMTP for ; Tue, 30 Oct 2001 23:16:00 -0500 X-ORDB-Envelope-MAIL-FROM: X-ORDB-Envelope-RCPT-TO: From: spamtest@alpha.ulm.edu To: marvin%ordb.org@[192.135.131.100] Subject: ORDB.org check (dc84c0ec532b1095b72e20e8adce9) (9) Message-Id: <20011031051412.2AE595B104@groundzero.ordb.org> Date: Wed, 31 Oct 2001 06:14:12 +0100 (CET) Thanks for the assistance. Chance Eppinette eppinette@ulm.edu Technology Support Manager ULM Computing Center 318-342-5021 fax: 318-342-5018 ------=_NextPart_000_047C_01C161E4.94F4E640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
I've started having a problem recently = with=20 anti-relaying settings.
Within the last week my MX system has = been placed=20 into the ORDB.ORG database and I can't determine
why their system is classing my box as = an=20 open-relay.
Hopefully someone thru this list can = help shed some=20 light on the problem.
 
I was running MX 5.1-X, but I upgraded = it last=20 night to 5.2 in an attempt to solve the problem - no luck.
I am running OpenVMS V7.2-1 over = MultiNet V4.1 Rev=20 A-X with MX V5.2-X
I've set the norelay option for MX = (which had been=20 set for some time)
The smtp logs where showing that the = system was=20 working well because there where numerous rejected messages due to = disabled=20 relay.  I still occasionally get these rejection statements, but = not as=20 often.
I've had a couple of "inside network" = entries on my=20 system for sometime as well that designate my local = network.
And I've got several entries in "local = domains" to=20 indicate my domain styles.
 
Like I said all had been working fine = until about a=20 week ago.
 
This log entry was one of the test that = ORDB=20 attempted:
30-OCT-2001 23:14:28.26:  MX SMTP = server:=20 rejected message from <spamtest@alpha.ulm.edu> to = <marvin@ordb.org> sent by = [62.242.0.190] due=20 to disabled relay
 
This is the header of = what supposedly failed=20 from the test returned by ORDB:
Return-Path: <spamtest@alpha.ulm.edu>
Delivered-To: marvin@groundzero.ordb.org
Received: from alpha.ulm.edu (alpha.ulm.edu [192.135.131.100])
	by groundzero.ordb.org (Postfix) with ESMTP id 2AE595B104
	for <marvin@ordb.org>; Wed, 31 Oct 2001 06:14:12 +0100 (CET)
Received: from groundzero.ordb.org (62.242.0.190) by alpha.ulm.edu (MX =
V5.2-X
          An7g) with ESMTP for =
<marvin%ordb.org@[192.135.131.100]>;
          Tue, 30 Oct 2001 23:16:00 -0500
X-ORDB-Envelope-MAIL-FROM: <spamtest@alpha.ulm.edu>
X-ORDB-Envelope-RCPT-TO: <marvin%ordb.org@[192.135.131.100]>
From: spamtest@alpha.ulm.edu
To: marvin%ordb.org@[192.135.131.100]
Subject: ORDB.org check (dc84c0ec532b1095b72e20e8adce9) (9)
Message-Id: <20011031051412.2AE595B104@groundzero.ordb.org>
Date: Wed, 31 Oct 2001 06:14:12 +0100 (CET)
Thanks for the assistance.
 
Chance Eppinette
eppinette@ulm.edu
Technology = Support=20 Manager
ULM Computing Center
318-342-5021
fax:=20 318-342-5018
------=_NextPart_000_047C_01C161E4.94F4E640-- ================================================================================ Archive-Date: Wed, 31 Oct 2001 06:44:28 -0800 Message-ID: <3BE00E3D.B0287FF7@atm.com.pl> Date: Wed, 31 Oct 2001 15:44:13 +0100 From: Jacek Tobiasz Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: MX-List@MadGoat.com Subject: Re: Anti-relay problem References: <047f01c16216$dfb0e800$c68387c0@ulm.edu> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit > eppinette wrote: > This is the header of what supposedly failed from the test returned by ORDB: > > Return-Path: [...] > X-ORDB-Envelope-RCPT-TO: > From: spamtest@alpha.ulm.edu > To: marvin%ordb.org@[192.135.131.100] [...] What about: mcp show router mcp set router/nopercent_hack regards, Jacek ================================================================================ Archive-Date: Wed, 31 Oct 2001 06:47:21 -0800 Subject: Re: Anti-relay problem From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3be00b55$1@news.kapsch.co.at> Date: 31 Oct 2001 15:31:49 +0100 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article <047f01c16216$dfb0e800$c68387c0@ulm.edu>, "eppinette" writes: >This is a multi-part message in MIME format. Stop using MIME in newsgroups ! >I've started having a problem recently with anti-relaying settings. >Within the last week my MX system has been placed into the ORDB.ORG = >database and I can't determine >why their system is classing my box as an open-relay. >Hopefully someone thru this list can help shed some light on the problem. Ok, I bite. >I was running MX 5.1-X, but I upgraded it last night to 5.2 in an >attempt to solve the problem - no luck. >I am running OpenVMS V7.2-1 over MultiNet V4.1 Rev A-X with MX V5.2-X MX V5.2-X means you have ECOs installed. Did you see/install ECO 7 ? >I've set the norelay option for MX (which had been set for some time) >The smtp logs where showing that the system was working well because >there where numerous rejected messages due to disabled relay. I still >occasionally get these rejection statements, but not as often. >I've had a couple of "inside network" entries on my system for sometime >as well that designate my local network. >And I've got several entries in "local domains" to indicate my domain styles. > >Like I said all had been working fine until about a week ago. Are you absolutely sure ? I don't think so. >This log entry was one of the test that ORDB attempted: >30-OCT-2001 23:14:28.26: MX SMTP server: rejected message from = > to sent by [62.242.0.190] due >to disabled relay > >This is the header of what supposedly failed from the test returned by ORDB: >Return-Path: >Delivered-To: marvin@groundzero.ordb.org >Received: from alpha.ulm.edu (alpha.ulm.edu [192.135.131.100]) > by groundzero.ordb.org (Postfix) with ESMTP id 2AE595B104 > for ; Wed, 31 Oct 2001 06:14:12 +0100 (CET) >Received: from groundzero.ordb.org (62.242.0.190) by alpha.ulm.edu (MX V5.2-X > An7g) with ESMTP for ; MCP>SET ROUTER/NOPERCENT_HACK Matt, please consider making /NOPERCENT_HACK default now ! -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Wed, 31 Oct 2001 07:49:53 -0800 From: "Virginia Metze" Reply-To: MX-List@MadGoat.com To: Subject: RE: Anti-relay problem Date: Wed, 31 Oct 2001 09:49:48 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C161F1.61379610" In-Reply-To: <047f01c16216$dfb0e800$c68387c0@ulm.edu> This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C161F1.61379610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It appears that these vigilantes are now hammering closed relays (to the outside) from INSIDE a network. We expect our servers to be able to forward mail from machines behind it. We define a closed relay as a machine that cannot be reached from outside our network. orbs.org lost a lawsuit and was put out of business in either Australia or New Zealand, don't remember which. They are setting up camp again and behaving even more obnoxiously. They are also targetting, as they always do, those they don't like. Let's be clear about this: they are going way beyond anything required by smtp "standards" if that is what you want to call an rfc. Also, one of the reasons they lost the lawsuit, as I understand it, is because they put anyone in they please, whether an open relay or not. The real thing to do is to keep people from violating the civil liberties of people whose machines were used as a relay and go instead after the REAL spammers, is to get people to stop using the data base. These vigilantes go after the victims, not after the spammers. It would be unfortunate if we have to get them taken out of business on every country on earth, but if they are just going to move around, then that may be what it takes. But complaining to those who use their database for banning email is one way to do it. Now I suppose they will attempt to send hundreds of emails through our network again. -----Original Message----- From: eppinette [mailto:eppinette@ulm.edu] Sent: Wednesday, October 31, 2001 8:18 AM To: mx-list@madgoat.com Subject: Anti-relay problem Hello, I've started having a problem recently with anti-relaying settings. Within the last week my MX system has been placed into the ORDB.ORG database and I can't determine why their system is classing my box as an open-relay. Hopefully someone thru this list can help shed some light on the problem. I was running MX 5.1-X, but I upgraded it last night to 5.2 in an attempt to solve the problem - no luck. I am running OpenVMS V7.2-1 over MultiNet V4.1 Rev A-X with MX V5.2-X I've set the norelay option for MX (which had been set for some time) The smtp logs where showing that the system was working well because there where numerous rejected messages due to disabled relay. I still occasionally get these rejection statements, but not as often. I've had a couple of "inside network" entries on my system for sometime as well that designate my local network. And I've got several entries in "local domains" to indicate my domain styles. Like I said all had been working fine until about a week ago. This log entry was one of the test that ORDB attempted: 30-OCT-2001 23:14:28.26: MX SMTP server: rejected message from to sent by [62.242.0.190] due to disabled relay This is the header of what supposedly failed from the test returned by ORDB: Return-Path: Delivered-To: marvin@groundzero.ordb.org Received: from alpha.ulm.edu (alpha.ulm.edu [192.135.131.100]) by groundzero.ordb.org (Postfix) with ESMTP id 2AE595B104 for ; Wed, 31 Oct 2001 06:14:12 +0100 (CET) Received: from groundzero.ordb.org (62.242.0.190) by alpha.ulm.edu (MX V5.2-X An7g) with ESMTP for ; Tue, 30 Oct 2001 23:16:00 -0500 X-ORDB-Envelope-MAIL-FROM: X-ORDB-Envelope-RCPT-TO: From: spamtest@alpha.ulm.edu To: marvin%ordb.org@[192.135.131.100] Subject: ORDB.org check (dc84c0ec532b1095b72e20e8adce9) (9) Message-Id: <20011031051412.2AE595B104@groundzero.ordb.org> Date: Wed, 31 Oct 2001 06:14:12 +0100 (CET) Thanks for the assistance. Chance Eppinette eppinette@ulm.edu Technology Support Manager ULM Computing Center 318-342-5021 fax: 318-342-5018 ------=_NextPart_000_0027_01C161F1.61379610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It=20 appears that these vigilantes are now hammering closed relays (to the=20 outside)
from=20 INSIDE a network.  We expect our servers to be able to forward mail = from
machines behind it.  We define a closed = relay as a=20 machine that cannot be
reached from outside our = network.
 
orbs.org lost a lawsuit and was put out of = business in=20 either Australia or New Zealand,
don't=20 remember which.
 
They=20 are setting up camp again and behaving even more obnoxiously.  They = are=20 also
targetting, as they always do, those they = don't=20 like. 
 
Let's=20 be clear about this:  they are going way beyond anything required = by smtp=20 "standards"
if=20 that is what you want to call an rfc.
 
Also,=20 one of the reasons they lost the lawsuit, as I understand it, is because = they=20 put
anyone=20 in they please, whether an open relay or not.
 
The=20 real thing to do is to keep people from violating the civil liberties of = people=20 whose machines
were=20 used as a relay and go instead after the REAL spammers, is to get people = to stop=20 using
the=20 data base.
 
These=20 vigilantes go after the victims, not after the = spammers.
 
It=20 would be unfortunate if we have to get them taken out of business on = every=20 country on earth,
but if=20 they are just going to move around, then that may be what it = takes.  But=20 complaining to
those=20 who use their database for banning email is one way to do=20 it.
 
Now I=20 suppose they will attempt to send hundreds of emails through our network = again.
-----Original Message-----
From: eppinette=20 [mailto:eppinette@ulm.edu]
Sent: Wednesday, October 31, 2001 = 8:18=20 AM
To: mx-list@madgoat.com
Subject: Anti-relay=20 problem

Hello,
I've started having a problem = recently with=20 anti-relaying settings.
Within the last week my MX system has = been placed=20 into the ORDB.ORG database and I can't determine
why their system is classing my box = as an=20 open-relay.
Hopefully someone thru this list can = help shed=20 some light on the problem.
 
I was running MX 5.1-X, but I = upgraded it last=20 night to 5.2 in an attempt to solve the problem - no = luck.
I am running OpenVMS V7.2-1 over = MultiNet V4.1=20 Rev A-X with MX V5.2-X
I've set the norelay option for MX = (which had=20 been set for some time)
The smtp logs where showing that the = system was=20 working well because there where numerous rejected messages due to = disabled=20 relay.  I still occasionally get these rejection statements, but = not as=20 often.
I've had a couple of "inside network" = entries on=20 my system for sometime as well that designate my local = network.
And I've got several entries in = "local domains"=20 to indicate my domain styles.
 
Like I said all had been working fine = until about=20 a week ago.
 
This log entry was one of the test = that ORDB=20 attempted:
30-OCT-2001 23:14:28.26:  MX = SMTP server:=20 rejected message from <spamtest@alpha.ulm.edu> = to <marvin@ordb.org> sent by = [62.242.0.190]=20 due to disabled relay
 
This is the header of = what supposedly failed=20 from the test returned by ORDB:
Return-Path: <spamtest@alpha.ulm.edu>
Delivered-To: marvin@groundzero.ordb.org
Received: from alpha.ulm.edu (alpha.ulm.edu [192.135.131.100])
	by groundzero.ordb.org (Postfix) with ESMTP id 2AE595B104
	for <marvin@ordb.org>; Wed, 31 Oct 2001 06:14:12 +0100 (CET)
Received: from groundzero.ordb.org (62.242.0.190) by alpha.ulm.edu (MX =
V5.2-X
          An7g) with ESMTP for =
<marvin%ordb.org@[192.135.131.100]>;
          Tue, 30 Oct 2001 23:16:00 -0500
X-ORDB-Envelope-MAIL-FROM: <spamtest@alpha.ulm.edu>
X-ORDB-Envelope-RCPT-TO: <marvin%ordb.org@[192.135.131.100]>
From: spamtest@alpha.ulm.edu
To: marvin%ordb.org@[192.135.131.100]
Subject: ORDB.org check (dc84c0ec532b1095b72e20e8adce9) (9)
Message-Id: <20011031051412.2AE595B104@groundzero.ordb.org>
Date: Wed, 31 Oct 2001 06:14:12 +0100 (CET)
Thanks for the = assistance.
 
Chance Eppinette
eppinette@ulm.edu
Technology = Support=20 Manager
ULM Computing Center
318-342-5021
fax:=20 318-342-5018
------=_NextPart_000_0027_01C161F1.61379610-- ================================================================================ Archive-Date: Wed, 31 Oct 2001 16:21:11 -0800 Message-ID: <003c01c1626b$0d888cc0$de2c67cb@helpdesk> From: "Geoff Roberts" Reply-To: MX-List@MadGoat.com To: References: Subject: Re: Anti-relay problem Date: Thu, 1 Nov 2001 10:50:44 +1030 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Virginia Metze To: MX-List@MadGoat.com Sent: Thursday, November 01, 2001 2:19 AM Subject: RE: Anti-relay problem > It appears that these vigilantes are now hammering closed relays (to the outside) > from INSIDE a network. We expect our servers to be able to forward mail from > machines behind it. We define a closed relay as a machine that cannot be > reached from outside our network. Actually it looks more like they are using the percent hack. Disable it with MCP and the problem will go away. > orbs.org lost a lawsuit and was put out of business in either Australia or New Zealand, > don't remember which. New Zealand most recently. Before that it was Canada. > They are setting up camp again and behaving even more obnoxiously. > No, same behaviour. They did this to us about 12 months ago. Looks like their new home is in Denmark. > They are also targetting, as they always do, those they don't like. Nothing new there. > Let's be clear about this: they are going way beyond anything required by smtp "standards" > if that is what you want to call an rfc. > These vigilantes go after the victims, not after the spammers. This is the part of their operation I find hardest to take. The majority of spam is US in origin. But the rest of the world is expected to lock up their servers because the yanks won't tread on people's 'right' to spray their crap all over the world. Not saying spam doesn't come from elsewhere, but I'd say 90% US origin. I fixed the problem eventually, completely, by requiring SMTP authorisation for anyone outside our domain and IP block. Unfortunately it doesn't stop us getting spammed, and the filtering is getting a lot harder. Latest batch is particularly bothersome, different address, different origin, different open relay, different subject, different reply to each time. Geoff Roberts Computer Systems Manager Saint Mark's College Port Pirie, South Australia geoffrob@stmarks.pp.catholic.edu.au ICQ 1970476