> OK, so 194.172.112.34 is open relay. You know because it is apparent in > the header or you have checked?
checked. > ( 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. > 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. 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. > 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. 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. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
