Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DBMail: dev
Re: attachment seperation idea - RFC thoughts.
 

Index | Next | Previous | View Flat


skraps at hushmail

Apr 14, 2012, 9:31 AM


Views: 222
Permalink
Re: attachment seperation idea - RFC thoughts.

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.

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

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
www.google.com/attachments/b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

with a post variable of the
auth-hash=b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184b1946ac92492d2347c6235b4d2611184

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
attachments.

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
known
protocols guru, and formatted as an RFC.

Some of what you propose however, is already (partly) done in DBMail,
if
you look at dbmail-httpd (or if you prefer PHP:
contrib/dbmailclient.php)
On 04/14/2012 07:09 AM, skraps [at] hushmail wrote:
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev [at] dbmail
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
--
________________________________________________________________
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
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

Subject User Time
Re: attachment seperation idea - RFC thoughts. skraps at hushmail Apr 14, 2012, 9:31 AM

  Index | Next | Previous | View Flat
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.