I must apologise if this idea has already bounced around, but I was discussing the pro's and con's of SPF with my colleague and hit upon an idea.
With raw socket capability (and subsequent abilities to falsify IP address, mac address and other information) the current SPF model is limited in it's ability to eradicate Spam.
My suggestion is quite simple, but I think would provide a much higher level of security and verification that the Email Server was actually responsible for the resulting spam message.
Basically, every time an email is sent from an email server the first (for example) 32 bits of the packet header are stored (this can be hashed / encrypted) by the Email server in a log, along with a timestamp.
This log would be capable of storing for a determined length of time (for example 1 week).
When an email is received from that domain, then (like the SPF) the receiving email server can check the authenticity of the message by first making sure that the Server exists (as per the SPF records).
However, it can then go one step further. It transmits the first 32-bits of the packet header (along with a timestamp) to that server, and asks if it has the details in it's Log.
The originating server receives this pakcte header, encrypts it and compares it to the values stored in the Log (along with the timestamp?). It can then send a simple yes/no acknowledgement to verify if that email was actually sent from that server!
Now, I'm sure there are people out there thinking ... "store logs of every email we've ever sent!!!"
Well, that is NOT the case.
You only have to log the encrypted 32-bit header, along with a simple Date-Time stamp, for future interrogation. You also don't need to save every email's details (as you only want to be able to verify those emails that are being sent and received right now) so no more than 1 week would be necessary in most cases!
Let us take an example company, who sends 50,000 emails per day from their beefy server.
They store a simple encrypted 4-byte (32-bit) packet header along with an 8-byte timestamp.
This represents 600,000 bytes of raw data per day.
Over the space of 1 week, that is only 4 megabytes!!
Even the extraordinary requirements of Hotmail Servers, sending (for example) 100,000,000 emails per week. such a log would represent around 1 gigabyte of data (and indexed by timestamp would be quite fast to query). And thats only if they keep entire 7 days logs .. they could quite reasonably request to keep only 1 day of logs instead .. drastically reducing requirements.
This system would bring together a distributing network of authorised servers (such as SPF) but at the same time tie in a solid backbone for verifying if every single email that is sent across the internet comes from a valid email server, and evidence of such is logged for verification.
No-one can tell what encryption method a particular email server uses (as there is no public / private key exchange .. the encryption is kept entirely secure as the email server itself is simply comparing one encrypted value with another)
Given that a tiny email will consist of thousands of bytes, transmitting 4 byte packets for verification is hardly an increase in network resources.
I hope you have gotten this far in reading my proposal. I am not "techie" enough to consider implementation of such a solution, but I thankyou for at least hearing me out.
Thoughts, comments and suggestions are of course welcome.
cheers
Martin Hatch
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
With raw socket capability (and subsequent abilities to falsify IP address, mac address and other information) the current SPF model is limited in it's ability to eradicate Spam.
My suggestion is quite simple, but I think would provide a much higher level of security and verification that the Email Server was actually responsible for the resulting spam message.
Basically, every time an email is sent from an email server the first (for example) 32 bits of the packet header are stored (this can be hashed / encrypted) by the Email server in a log, along with a timestamp.
This log would be capable of storing for a determined length of time (for example 1 week).
When an email is received from that domain, then (like the SPF) the receiving email server can check the authenticity of the message by first making sure that the Server exists (as per the SPF records).
However, it can then go one step further. It transmits the first 32-bits of the packet header (along with a timestamp) to that server, and asks if it has the details in it's Log.
The originating server receives this pakcte header, encrypts it and compares it to the values stored in the Log (along with the timestamp?). It can then send a simple yes/no acknowledgement to verify if that email was actually sent from that server!
Now, I'm sure there are people out there thinking ... "store logs of every email we've ever sent!!!"
Well, that is NOT the case.
You only have to log the encrypted 32-bit header, along with a simple Date-Time stamp, for future interrogation. You also don't need to save every email's details (as you only want to be able to verify those emails that are being sent and received right now) so no more than 1 week would be necessary in most cases!
Let us take an example company, who sends 50,000 emails per day from their beefy server.
They store a simple encrypted 4-byte (32-bit) packet header along with an 8-byte timestamp.
This represents 600,000 bytes of raw data per day.
Over the space of 1 week, that is only 4 megabytes!!
Even the extraordinary requirements of Hotmail Servers, sending (for example) 100,000,000 emails per week. such a log would represent around 1 gigabyte of data (and indexed by timestamp would be quite fast to query). And thats only if they keep entire 7 days logs .. they could quite reasonably request to keep only 1 day of logs instead .. drastically reducing requirements.
This system would bring together a distributing network of authorised servers (such as SPF) but at the same time tie in a solid backbone for verifying if every single email that is sent across the internet comes from a valid email server, and evidence of such is logged for verification.
No-one can tell what encryption method a particular email server uses (as there is no public / private key exchange .. the encryption is kept entirely secure as the email server itself is simply comparing one encrypted value with another)
Given that a tiny email will consist of thousands of bytes, transmitting 4 byte packets for verification is hardly an increase in network resources.
I hope you have gotten this far in reading my proposal. I am not "techie" enough to consider implementation of such a solution, but I thankyou for at least hearing me out.
Thoughts, comments and suggestions are of course welcome.
cheers
Martin Hatch
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com