Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: more silly questions
 Another thought from George Birblis at kagi.com: "In fact we should push for throw-away of SMTP protocol I think or revision of it so that a mail-server refuses to forward an e-mail if it can't contact the originator server of the e-mail That check could be done by SMTP e-mail servers on the hop-path towards the destination, either at each hop, or at random choice of hops, or just at the end server before it gets delivered to a POP3/IMAP user. Obviously the check should be done at the end point always, before delivery to the enduser. In fact even the enduser's client software could do that check and warn the user for those e-mails that can't be verified as sent from the server they claim they were sent from (e.g. can have the client software set to not allow to open those e-mails at all till their source is verified [say if the originator server of an e-mail is down at the moment and can't confirm it sent that e-mail]) confirmation is simple: * the exact datetime AND checksum of the whole e-mail is kept at the originator server when it sends out the e-mail * the originator server allows one to ask if a message with checksum N was sent at datetime T, but doesn't allow one to poll for all that info, just replies yes/no instead for a certain confirmation check * servers on the way that are set or randomly decide to do the check I was talking about, don't forward/deliver an e-mail unless they can contact the originator server and get an OK from it that they had sent a message with the given timedate (the one in the original e-mail headers) and the calculated checksum (calculated at the forwarding server). This doesn't help with the case where SMTP packets are forged on their way to a destination by pirates, since one could make a similar message adding a garbage attatchment if they know the timedate and checksum they want to achieve. But that's a more rare case, since packets follow various routes and not always go on the same network path for a pirate machine to grab/forge them (unless it's inside the inner network of an organisation the hacking point, that's another story) The above pattern (or a similar one) could help for stopping the forging of e-mail headers by viruses and hackers and detecting the propagation route of something (at least detect where a "zombie" machine is that is sending out stuff [remote controlled via a trojan by a hacker or automatically controlled by some virus] and contact it's owner to fix it). Of course the other thing is that the whole Internet registrar needs some more stict rules, it's a common case nowadays that one can't backtrace to an offending machine or gets old info about who is responsible (legally too!) for a certain network subnet." From: Michael Kay [mailto:michael.h.kay@n...] > How would an XML schema for email address this issue? It wouldn't of course. But a redesign of the email protocols could. The fundamental flaw in the system is the assumption that anyone in the world, without proving their identity, has a right to send me garbage and to use the bandwidth that I am paying for. The protocols are wrong because they are designed to implement this wrong assumption. The designers of the modern postal service got it right: the sender, not the recipient, should pay. I still get junk mail through the letterbox, but not 400 a day. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
