ki4jgt Posted July 27, 2011 Share Posted July 27, 2011 Just wrote my own email protocol: It's incompatible with any other protocol. Have any suggestions? I know this is reinventing the wheel, but I'm wanting an open protocol, which is why I created this one. http://sourceforge.net/projects/smashindex/files/E3%20Protocol/E3%20Protocol.txt/download It's a txt file. Quote Link to comment Share on other sites More sharing options...
Jason Cooper Posted July 27, 2011 Share Posted July 27, 2011 Having skimmed your protocol I can't see what benefits it has over the standard email protocols, which are also open, and well documented in the RFCs like most other networking protocols in use today? If you really want to make a new email protocol figure out one that will work on both IPv4 and IPv6 which stops spam. Not an easy task and it is spam that stops most people from moving their mail servers over to IPv6 (blacklists which are one of the most effective ways to stop spam aren't scalable and IPv6 scales the problem of maintaining blacklists up massively). a slightly relevant xkcd entry Quote Link to comment Share on other sites More sharing options...
ki4jgt Posted July 27, 2011 Author Share Posted July 27, 2011 (edited) Having skimmed your protocol I can't see what benefits it has over the standard email protocols, which are also open, and well documented in the RFCs like most other networking protocols in use today? If you really want to make a new email protocol figure out one that will work on both IPv4 and IPv6 which stops spam. Not an easy task and it is spam that stops most people from moving their mail servers over to IPv6 (blacklists which are one of the most effective ways to stop spam aren't scalable and IPv6 scales the problem of maintaining blacklists up massively). a slightly relevant xkcd entry As of current, the protocol eliminates email spoofing, using tokens. This is why I introduced this protocol here and a few other places. It successfully eliminates spoofing. I have made it open sourced with modular variables for email messages. But seriously, I'm just doing it for the intellectual exercise of it all. The protocol does work on IPv4 and IPv6. As for the SPAM thing, It gets email spoofing right out, with a little creativity, I'm sure something can be done. Edited July 27, 2011 by ki4jgt Quote Link to comment Share on other sites More sharing options...
Jason Cooper Posted July 28, 2011 Share Posted July 28, 2011 As of current, the protocol eliminates email spoofing, using tokens. I may have missed it, but I can't see the tokens explained in your document. How are they generated? Is it an common cryptographic standard token, or something else? Without knowing how the tokens are generated, used and verified we can't say how effective they would be at stopping spoofing. This is why I introduced this protocol here and a few other places. It successfully eliminates spoofing. I have made it open sourced with modular variables for email messages. But seriously, I'm just doing it for the intellectual exercise of it all. It's always good to get second, third, fourth, etc opinions on a new protocol's security, you just need to make sure to point out what you see as the benefits and deficiencies of the protocol. (e.g. it stops spoofing or it requires the use of GPG) The protocol does work on IPv4 and IPv6. As for the SPAM thing, It gets email spoofing right out, with a little creativity, I'm sure something can be done. I can't really comment on this till I understand the whole method that your protocol uses to validate a message. It seems very vague in your document (It is a first draft though, so you can beef this section up in the next revision). Quote Link to comment Share on other sites More sharing options...
ki4jgt Posted July 28, 2011 Author Share Posted July 28, 2011 (edited) I may have missed it, but I can't see the tokens explained in your document. How are they generated? Is it an common cryptographic standard token, or something else? Without knowing how the tokens are generated, used and verified we can't say how effective they would be at stopping spoofing. It's always good to get second, third, fourth, etc opinions on a new protocol's security, you just need to make sure to point out what you see as the benefits and deficiencies of the protocol. (e.g. it stops spoofing or it requires the use of GPG) I can't really comment on this till I understand the whole method that your protocol uses to validate a message. It seems very vague in your document (It is a first draft though, so you can beef this section up in the next revision). Sure. . . :-) The token is a 10 character alphanumeric string randomly generated by the sending server and attached to the message, the receiving server then strips the token from the message and sends the two emails involved with the message. If the sending server sends the same token back, the message is verified and NO SPOOFING. The protocol is setup with a variable for a verification server, so the server could be anywhere on the web you wish. EDIT: I believe the document refers to it as a key. I changed it over to a token the night before last. Edited July 28, 2011 by ki4jgt Quote Link to comment Share on other sites More sharing options...
Jason Cooper Posted July 28, 2011 Share Posted July 28, 2011 Does it connect back to the verifictation-server, the server that originally connected to it or the server related to the host part of the senders e3/email address? If it connects to the verification server then the spammer could just run their own verification server and put that in the email. If it connects back to the server related to the host part of the senders e3/email address then in theory this would stop the email being spoofed, but it would also present a possible denial of service attack. If the attacker chose a host that has a firewall rule to just drop packets for the relevant port then they could just send a mass of large emails to the server with e3/email addresses from that host. The receiving server would then try to connect to the host and only throw away the email when the connection attempt has timed out. The larger the mail received and the more of them recieved the more resources being spent holding onto fake messages. Another alternative would be send large fake emails, with the host of a target e3 server, to a number of other e3 servers, they would each connect back to this e3 server and pass it the large fake email. If you have enough machines doing this you can effective DDOS the server but without any of your machines communicating directly with the target. Quote Link to comment Share on other sites More sharing options...
ki4jgt Posted July 28, 2011 Author Share Posted July 28, 2011 Does it connect back to the verifictation-server, the server that originally connected to it or the server related to the host part of the senders e3/email address? If it connects to the verification server then the spammer could just run their own verification server and put that in the email. If it connects back to the server related to the host part of the senders e3/email address then in theory this would stop the email being spoofed, but it would also present a possible denial of service attack. If the attacker chose a host that has a firewall rule to just drop packets for the relevant port then they could just send a mass of large emails to the server with e3/email addresses from that host. The receiving server would then try to connect to the host and only throw away the email when the connection attempt has timed out. The larger the mail received and the more of them recieved the more resources being spent holding onto fake messages. Another alternative would be send large fake emails, with the host of a target e3 server, to a number of other e3 servers, they would each connect back to this e3 server and pass it the large fake email. If you have enough machines doing this you can effective DDOS the server but without any of your machines communicating directly with the target. I'll give you your first strategy. However, your second is a little off. The protocol strips the email down to ONLY sending address, receiving address, and a small amount of the token (in case multiple emails have been sent). The verification server is it's own variable. It doesn't connect automatically to the server at the end of the sending address. The thing behind this is that it will give away the IP of the hacker. Quote Link to comment Share on other sites More sharing options...
Jason Cooper Posted July 29, 2011 Share Posted July 29, 2011 (edited) I'll give you your first strategy. However, your second is a little off. The protocol strips the email down to ONLY sending address, receiving address, and a small amount of the token (in case multiple emails have been sent). The verification server is it's own variable. It doesn't connect automatically to the server at the end of the sending address. The thing behind this is that it will give away the IP of the hacker. So the first part of the token has to be unique when compared to all other messages the server is waiting to verify? Personally I would have had each message identified by a message ID that is unique to the verification server. This could be something as simple as a sequence that is easy for the verification server to deal with. What could be a useful exercise for you to do is to put together a simple graphic showing the flow of a message being sent and verified. (e.g. something like this http://security.crudtastic.com/wp-content/uploads/2010/05/3way.jpg) Edited July 29, 2011 by Jason Cooper Quote Link to comment Share on other sites More sharing options...
ki4jgt Posted August 5, 2011 Author Share Posted August 5, 2011 So the first part of the token has to be unique when compared to all other messages the server is waiting to verify? Personally I would have had each message identified by a message ID that is unique to the verification server. This could be something as simple as a sequence that is easy for the verification server to deal with. What could be a useful exercise for you to do is to put together a simple graphic showing the flow of a message being sent and verified. (e.g. something like this http://security.crudtastic.com/wp-content/uploads/2010/05/3way.jpg) Here is an example: Alice sends bob a fax with this letter-head: Bob 123 Dead st. New York, New York Letter 129-4297-1709 Alice has a system of keeping up with the letters. If someone calls and asks for a particular letter number, Alice knows she sent the letter. Bob calls Alice: Bob: Hey Alice, I have this letter you sent me. It's letter 129-4297 something, but I can't remember the rest. Alice: (looking through her filing system for the first few numbers Bob gave her, finds the letter)(Alice then repeats the number in whole) Ah! Here it is Bob. You mean letter 129-4297-1709. Bob: (Knows the letter is from Alice, because she is able to complete the number sequence) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.