skraps at hushmail
Apr 14, 2012, 1:41 PM
Post #1 of 1
I guess you can even consider this a green advancement also. If you
Re: attachment seperation idea - Green tech advancement
can reduce the amount of traffic from large attachments and emails in
general you can lower the amount of power that is used. Its great for
everyone all the way around.
Current email routing:
Client -> server (sometimes more servers)-> server(sometimes more
servers) -> client
Attachment separation setup:
Client -> server -> storage/file server -> Client
It really is good stuff.
On 04/14/2012 at 12:32 PM, skraps [at] hushmail wrote:
I guess to make this easy to use a seperate/new mime type would need
to be established and then to get microsoft, mozilla, opera and other
email clients on the same page.
Then this system could be established into mail clients for ease of
use and would seem seem less compared to shortlinks style stuff.
then they could access the file like so
with a post variable of the
Something along those lines.
On 04/14/2012 at 8:53 AM, skraps [at] hushmail wrote:It was built with
libre office. There is no change to base protocols, its just about
separating attachments from the message at the server level
transparent from the users perspective durring the initial upload
sequence. The storage implementation is partly done, the actually
stripping of the data at the smtpd level is not. Refrencing a database
and seperating the attachments at the smtpd level are different
things. This concept applies to any email server in any
infrastructure, without making changes to the base protocol so it is
backwards compatible with current standards. Then becomes a boost for
intermediate mail servers and old servers not using this type of
technology. You can take a once 20mb email reduce its main
content(body) to kilobytes for transferring across the ether then the
download resources for the 19mb attachment is on demand.So if a chain
group mail of 30-50 people is sent out, and only 10-15 of those people
still receive their mail the only 8 people are interested then the
download resources are not wasted sending that same email to 15-20
different networks This is easily done in dbmail because of the
storage standard that dbmail uses(mysql).
This is like emails mixed with text messaging. Low immediate overhead
with performance & cost savings mixed together
I was able to mod the pop/imap in db_messages except I think I don't
quite understand the depth aspects of the messages.
By studying the database I figured out that regular emails header and
body are the first 2 records and then mime emails are the first 4 then
afterwards are inline and attachments. I'm trying to dumb it down and
just use a regex to check the email for attachments then strip the
The emails keep coming thru malformed when they are reassembled. When
I am only taking the data and header from the disposition attachment
and storing it.
On 04/14/2012 at 7:45 AM, Paul J Stevens wrote:Why sent a plain list
of bullet points in a Microsoft format?
Completely unreadable in LibreOffice.
Sounds like you try to 'fix' SMTP and IMAP to fit a HTML kind of model
where emails consist of remote content.
*Any* idea that requires a change in base protocols like SMTP or IMAP
will be met by massive amounts of scepticism, unless proposed by a
protocols guru, and formatted as an RFC.
Some of what you propose however, is already (partly) done in DBMail,
you look at dbmail-httpd (or if you prefer PHP:
On 04/14/2012 07:09 AM, skraps [at] hushmail wrote:
> Dbmail-dev mailing list
> Dbmail-dev [at] dbmail
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/info [at] nfg/+31.85.877.99.97
Dbmail-dev mailing list
Dbmail-dev [at] dbmail