Danny, Harmeet, OK, so 194.172.112.34 is open relay. You know because it is apparent in the header or you have checked? The shot-down-in-flames RUOR could detect that, or go part way to detecting that. There would be three types of mail servers:
1) Pre RUOR 2) RUOR compatible and reporting correct policy 3) RUOR compatible, incorrectly replying "No I am not" (and in breach of the RFC associated with RUOR). Blacklists, if they were built, would not be needed to list open relays, but mail servers that did (3) above. A smaller list one would assume. ( I duck again as I await the flames again. Seriously I was not going to say another word on spam, but you guys raised it again) It is also apparent (as Harmeet says) that if open relays close, then the spammer still get through by really spending time faking headers. I do not really understand the insertion point of the mail, but I guess it is something to do with IP origin faking that hacker use and was talked about a lot in a few years ago ususally in the context of IPv6 etc. If it is that the mail server accepts the incoming because it is apparently from another server it trusts, maybe the second part of the RFC could be used to tackle that. It reaches back, post connection, to the mail server that was proportedly the sender, and checks the message ID and a digest of the message with it. If that mail server replies "whatare you on about?" then the mail was very craftily faked. Thus this RFC I talk of is two fold. 1) RUOR and 2) say "DYST" (Did You Send This). ( putting on fire retardant suit now). Regards, - Paul >Paul, > >Here's an extract from a header from a spam I recieved this a.m. It clearly >shows how the information describing each host it passed through has not >been verified, (each line ought to receive from the recipient of the line >below) and no action has been taken to block this mail where names and >addresses don't match. > >What I think is important is that the IP address of the top entry is an open >relay, and the lower ones dont accept connections on port 25 at all. Which >suggests to me that this is a live example of the scenario you set out a few >days ago. > >I should also point out that it is also clear from a little research that >this is not connected at all with Edinburgh University (ed.ac.uk) whos name >has been used maliciously by the spammer. > > >Received: from ed.ac.uk ([194.172.112.34]) > by mx0.dircon.net (8.9.1.Dirconised/8.9.1) with SMTP id AAA13183 > for <[EMAIL PROTECTED]>; Fri, 29 Mar 2002 00:59:01 GMT > >Received: from unknown (HELO rly-xr02.nikavo.net) (127.38.79.237) > by symail.kustanai.co.kr with SMTP; 28 Mar 2002 15:00:03 -0300 > >Received: from smtp013.mail.yahou.com ([211.199.191.200]) > by rly-xr01.nihuyatut.net with local; 28 Mar 2002 11:55:00 +0100 > >Received: from unknown (HELO rly-xw01.otpalo.com) (132.118.28.155) > by n7.groups.huyahoo.com with asmtp; Thu, 28 Mar 2002 12:49:57 +1100 > >Received: from unknown (HELO q4.quickslow.com) (176.200.210.157) > by web.mail.halfeye.com with smtp; Thu, 28 Mar 2002 23:44:54 +0100 > > >This mail would not have got to me had the open relay been closed, or if it >had verified the Recieved headers for internal consistency, without recourse >to any enhanced SMTP functionality, or network services of any kind (DNS >etc). > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
