Danny, >>OK, so 194.172.112.34 is open relay. You know because it is apparent in >>the header or you have checked? >> > >checked. > I used to use Amnesi, but it is down nowadays.
>>( 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) >> > >Although I may not agree with the detail of your idea, there's no getting >away from the fact that spam is an issue, and we're well situated to explore >new possibilities. I hope you dont think our "robust responses" are flames.. > :-) >>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. >> > >This is a sensible approach, but it would increase server workloads, as they >would have to maintain lists of message_id's that they sent. > True, but should not worry about workload of mail servers, if the end point will be a reduction of spam we will recieve (you have seen the projections?) >>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'm beginning to wonder if we shouldn't be looking at this from the point of >view of "trust", and whether any trust mechanisms that exist would be >appropriate to adapt for creating chains of trust amongst mailservers. > I'll come back to this. >On the other hand its all a bit of a vicious circle, because spammers abuse >one of the fundamental features of email, that you can initiate an email and >send it to anyone with no prior agreement. > Yes, that will never be closed. However, if they have to use legitimate mail servers and chains of contract ( ISP to ISP, ISP to customer) and acceptible use policies mean that if they have to use real accounts to send spam, they will be closed down quickly. >>Thus this RFC I talk of is two fold. 1) RUOR and 2) say "DYST" (Did You >>Send This). >> > >I still maintain that if IP faking is within the remit of spammers, then >faking RUOR is too. > You're missing the central point of RUOR. It is a not mail header. A server can be asked at any time by any server (by it's alleged recipient mail server in this case). The dialog goes HELO, RUOR, <bye>. Anything in an incoming mail header could be faked, all RUOR is about is an RFC sponsored way of allowing machines to ask mail servers if they are open relay without being deemed as a hack attempt. >I quite like DYST as a principle, particularly if you can have verified >trust, however if you send my account holders lots of email that they don't >want to receive *directly*, and thereby comply with RUOR and DYST I still >have to blacklist you, but at least now I know who you really are. > Yes. And they will be closed, after some delay, by their ISP who is in contracts or AUPs with larger backbones etc. Spam is not killed by RUOR or DYST, but is made accountable. <fx>Pauls loosens flame retardant jacket a little</fx> - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
