Thanks for the thoughtful reply Thomas, my comments inline below... On 2012-02-11 4:16 AM, Thomas Eckardt <[email protected]> wrote: > 1. each replaced attachment has to be moved to a web server (for download) > immediatly
Correct... > 2. it has to be placed on a "some how 'cryptic' and unique (like a WWN)" > path to prevent unwanted access to stored attachments > 3. access to this attachment store has to be anonymous and secret => > this is impossible - or assp has to calculate a session hash for the > web server that will handle the attachments - and this session hash > must be valid for ever ?? Only if the admin has chosen to keep the attachments 'forever'... Also, as was discussed, it should NOT be ASSPs job to track these and do any clean up on the attachment store. That would be the job of the sysadmin. They would decide whatever time limit they wanted on the attachment store, modify the link text accordingly )to give the recipient(s) notice of the date/time the link to the attachment will expire, and they would also decide how and when to perform the cleanup. That said, I'm not saying this would be extremely easy, but as you noted, it shouldn't be 'impossible'... When the attachment is saved, create the file hash, then create the session hash *using the file hash as an additional key* (I may not be saying this with correct terminology)... > 4. the attachment has to be stored there for ever - there is no rule, > that allows us to prevent the recipient from reading this mail in ten > years or even more Again, this would be determined by the admin - my idea is to let the admin decide - and if they don't want to keep attachments forever, they can modify the link text that is added to the email in place of the attachment that was stripped, and say something like: "Availability of this attachment from the included link is only guaranteed until $time on $date, and could become unavailable anytime after this date/time." This gives the recipient notice that they only have a limited amount of time to download the attachment. Also, the HASH of the attachment should be included in the link text, for purposes of validating that the attachment is the same one that was sent with the original email. > 5. user should care about the size of there mails - even they take care > about the weigth of postal packages or letters I agree, but situations vary. We are a Media Buying Service, and routinely send/receive Ad Creative, which can be very large attachments. We've settled on 30MB as the max files we can send/receive, but there has been talk of increasing this to 50MB. > 6. doing this for incoming mails -....- the mail server could do that > better. So this request should be better posted in the postfix, > qmail.... project - or even better, use a mailserver that is able to > do that for you I don't know of any that have this feature built-in... do you? Also, if ASSP could do it, then ASSP users could still use whatever MTA they wanted. That said, I do know that mimedefang (http://www.mimedefang.org/faq) which is also written in perl can already do this - so at least some of the 'heavy lifting' may already be done. However, since mimedefang is a C "Milter" program, and talks directly to Sendmail using the multi-threaded Milter library, the code may not be easily made 'portable' so that this feature could run on windows, but ianap, so cannot tell... That said, this could simply be a feature (at least initially) that only runs on linux/unis, or at a minimum requires a linux/unix box to run mimedefang on. Then, once it is working well on linux, calls could go out for someone to port libmilter to windows for native windows support of the feature. > 7. it has taken some man-years of work to get DAOS working like now > (Domino 8.5.3) Yes, but they did it from scratch... if mimedefang can be leveraged, it should be relatively simple... ? > 8. assp is a spam filter proxy not a mail server nor a web server I understand, and I'm not saying that this feature totally fits into the category of 'natural fit' for ASSP, but, I don't think it is totally outside that category either... Again, thanks Thomas for your reply, even if there is no interest in attempting this... :) > On 2012-02-09 8:32 AM, Grayhat<[email protected]> wrote: >>> Personally, since there will never be duplicate attachments, keeping >>> them forever (or at least for many years) shouldn't be a real >>> problem, and that is what I would do. The simplest way for those who >> >> well... that fits your reality, but when it comes to a program (ASSP) >> used in a number of different other realities, you can't just look at >> "me and here" ... please :) ! > > Agreed, and that is why my comments also allowed for other options. > >>> Then all you need is a simple script that deletes based on file age. > >> exactly, but, that should NOT be a task for ASSP; > > Agreed, and that is why my comment stated that only *example/sample* > scripts should be provided along with appropriate $scary-warnings about > their use, and leave their implementation to the sysadmin. > >>> Maybe this process could be moved to a separate worker thread > >> No, seriously, such a "cleanup" is NOT a task for ASSP, > > Ummm... read more closely what I was replying *to* - your concern about > extra overhead from processing these attachments (stripping/replacing > with link/linktext)... or at least, that is how I read your comment as > to referring to. I wasn't talking about the *cleanup*. > >>> The biggest problem that I see for someone like me is what to do >>> about *existing* mailstores. Whatwe would also need is a script that >>> runs against an existing mailstore that rips out the attachments >>> (creating the MD5SUM), replaces them with the link/linktext and > >> this is totally OT, nothing ASSP can or should do; sure, finding a >> solution to the above may be a need for someone, but this isn't a task >> for ASSP or the ASSP developers > > I agree, but I meant this in the context of documenting different known > methods of accomplishing this task, which it would make sense for AASP > to do (again, along with appropriate $scary-warnings) *if* it were to > implement attachment stripping/replacing with link/linktext in the first > place, because said scenario would obviously be an FAQ for anyone > thinking about implementing this feature. > > Hope this clears up your misunderstandings on my comments... -- Best regards, Charles ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
