[
Lists Home |
Date Index |
Thread Index
]
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@ntlworld.com]
> 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.
|
