Shortly after annoucing this Timo Sirainen from the dovecot project made refrence to these RFC's RFC 1873 RFC 2017

Green attachments is not the same thing and it differs in many ways. If you look at the date those RFCs are written they do not meet current security standards and they interfer with current email service providers searching abilities.

Problems email currently face is there is not a easy way to scale the enviroment. Then also a huge waste of resources. Green Attachments fixes those problems, then also introduces new advantages to email technology. We can now take a old car and give it some new wheels to improve the handling and therefore making it more effecient. The drivers are also comfortable and trained to drive this car.

How is this green and better for the enviroment?

By using this type of system you can reduce bandwidth going in and out of the network. Reducing the amount of data intermediate email servers process reduces the load on the CPU and RAM on the servers therefore lower power usage. By using less power less resources are pulled from the grid that currently uses nuclear and coal to generate the electricity for these systems. Even if the provider says they run on 100% green energy doesn't mean it's true. Most providers claim this but in reality they are only investing and funding that type of research and development.Then pulling energy from the same part of the grid that uses dangerous and hazordous fuels to create energy.

Advantages

• This can be integrated easily into current email systems in the corporate infrastructure with minimal effort and change in the whole process of email communications
• No employee retraining to use this transparent system
• Database of all email attachments sent in and out of your network. You can even document to who and where from. Leaving the old, "I didn't get it" or I don't know what you are talking about" excuses out the window.
• This can also make it easier to integrate effecently key/value system like memcache and casandria. To take advantage of memory cacheing to save disk io for current email systms. Reducing power usage by not having to use the hard drive to fetch the data. It is stored in RAM that is powered no matter what
• Reduce outgoing bandwidth to create a on demand attachment download system
• Less power needed to power the servers that currently process email
• Faster pop/imap email downloads
• You can use redirection with your attachment servers to generate revenue and or display your own advertising in your network therefore a system that once only cost money can now start paying for it's own resources.

Disadvanages of current email systems

• Slow mail downloading for users especially road warriors that use air cards on data plans
• Key/value storage systems are not easily integratable with attachment sizes
• Everyday person: When a chain email is sent out to 30 people. Only 20 check their email anymore. Then only 10-15 people are interested in the attachment.
• Corporate user: When a chain email is sent out to 30 people. 5-10 people already received the attachments in previous emails or a hand off by thumb drive or CD. 5 people are out on vacation, or off work.
• When a email is sent with a large attachment to 30 people. That 20-30mb attachment is sent instantly to all networks. Why are we sending megabytes, we could be transfering kilobytes

Key Elements of this system

• Your current email server (dbmail, postfix, qmail, exim). Integrating only a small set of tools and patches.
• MySQL database server
• lighttpd / apache webserver

New content dispostion type proposal

Disposition-type: seperate-attachment
url: https://www.google.com/attachments
file-name: somefilename.mov
file-size: 103432665
file-hash:b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184
auth-hash:b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

Then this system could be established into mail clients for ease of use and would be better that short links style

Then they could access the file like so:
www.google.com/attachments/b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

with a post variable of the:
auth-hash=b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

Shortly after annoucing this Timo Sirainen from the dovecot project made refrence to these RFC's RFC 1873 RFC 2017

Green attachments is not the same thing and it differs in many ways. If you look at the date those RFCs are written they do not meet current security standards and they interfer with current email service providers searching abilities.

Problems email currently face is there is not a easy way to scale the enviroment. Then also a huge waste of resources. Green Attachments fixes those problems, then also introduces new advantages to email technology. We can now take a old car and give it some new wheels to improve the handling and therefore making it more effecient. The drivers are also comfortable and trained to drive this car.

How is this green and better for the enviroment?

By using this type of system you can reduce bandwidth going in and out of the network. Reducing the amount of data intermediate email servers process reduces the load on the CPU and RAM on the servers therefore lower power usage. By using less power less resources are pulled from the grid that currently uses nuclear and coal to generate the electricity for these systems. Even if the provider says they run on 100% green energy doesn't mean it's true. Most providers claim this but in reality they are only investing and funding that type of research and development.Then pulling energy from the same part of the grid that uses dangerous and hazordous fuels to create energy.

Advantages

• This can be integrated easily into current email systems in the corporate infrastructure with minimal effort and change in the whole process of email communications
• No employee retraining to use this transparent system
• Database of all email attachments sent in and out of your network. You can even document to who and where from. Leaving the old, "I didn't get it" or I don't know what you are talking about" excuses out the window.
• You get to maintain your companies privacy by not resorting to third party / government owned or controlled infrustructures that are interested in what you are communicating about. Then use cloud services for archival purpose 5-6 months to a year down the road.
• This can also make it easier to integrate effecently key/value system like memcache and casandria. To take advantage of memory cacheing to save disk io for current email systms. Reducing power usage by not having to use the hard drive to fetch the data. It is stored in RAM that is powered no matter what
• Reduce outgoing bandwidth to create a on demand attachment download system
• Less power needed to power the servers that currently process email
• Faster pop/imap email downloads
• Faster email downloads for smart phones and other devices alike.
• You can use redirection with your attachment servers to generate revenue and or display your own advertising in your network therefore a system that once only cost money can now start paying for it's own resources.

Disadvanages of current email systems

• Slow mail downloading for users especially road warriors that use air cards on data plans
• Key/value storage systems are not easily integratable with attachment sizes
• Everyday person: When a chain email is sent out to 30 people. Only 20 check their email anymore. Then only 10-15 people are interested in the attachment.
• Corporate user: When a chain email is sent out to 30 people. 5-10 people already received the attachments in previous emails or a hand off by thumb drive or CD. 5 people are out on vacation, or off work.
• When a email is sent with a large attachment to 30 people. That 20-30mb attachment is sent instantly to all networks. Why are we sending megabytes, we could be transfering kilobytes

Key Elements of this system

• Your current email server (dbmail, postfix, qmail, exim). Integrating only a small set of tools and patches.
• MySQL database server
• lighttpd / apache webserver

New content dispostion type proposal

Seperate Attachment

Then this system could be established into mail clients for ease of use and would be better that short links style

Then they could access the file like so:
www.google.com/attachments/b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

with a post variable of the:
auth-hash=b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

Possibly - Smtp message body compression