> 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 ??
Possibly this part was written too fast.
What I mean - the implementation of this step in any available Web-Server
(100 and more version) is not really possible. The session key must be
build by the Web-Server
and as long as I know they are not valid after a server restart (in most
cases).
Striping the attachment out, storing an entry in a DB, moving it to
anywhere, manipulating the mail with the right hints, text and links - all
these is relative simple.
But the stuff with the Web-Server session handle (interaction) ... huuu,
that sounds crazy.
What I spoke about until now was the normal handling (20% code) - but what
is with exceptions like: web server (store) down - crazy web server - full
volume - database unavailable
possibly you know some more - (80% code) - and don't forget the crazy
users and (SYS)admins.
Ok - Charles, I understand your requirement to reduce the mail size. A
possibly better solution would be in your case, to use your Web-Server
natively.
What do I mean?
1. An user would send a mail with an 50MB attachment.
2. He opens the web browser and drags the attachment there or simply on an
icon on the desktop (a small program behind) or uses a plugin of his mail
client (small program).
3. This program sends the attachment to the web server, which returns the
full link (including all logon and session data and hints and checksum
...) of the attachment in to a 'new mail' window.
4. The user writes some more or less friendly text - clicks send - that's
all.
The PHP/Ajax/Tomcat/WebSphere stuff to store the attachment and to
calculate the session data for the download should be simple - this is
IMHO already written for software online stores. Also the code for the
drag in of the attachment in to a browser applet should be easy to do for
a web designer - and should be still also available in every online shop
solution.
The desktop icon or mail client plugin or OS plugin needs some more
knowledge - but DOTNET/Java even Perl-tk makes it possible to do it smart
with a user friendly GUI.
>I don't know of any that have this feature built-in... do you?
Yes - with some simple additional NOTES/Java lines - any Domino server
8.x.x will do that for you (including the web service - reference tracking
and cleanup)
>> 7. it has taken some man-years of work to get DAOS working like now
> (Domino 8.5.3)
I mean - if I would do such things in ASSP, my personal claim would be to
it the same way elegant like DAOS.
>That would be the job of the sysadmin.
I trust them no longer! My job is to repair what 'sysadmins' have
destroyed - in most cases all systems are down - all networks are
unaccessable - all services are broken - all yellow/orange lights are on -
and you would not believe what I hear every time: "We've done nothing!!!!"
and "ALL was working well until such time." :)
Oh - forgot - geetings from Mauritius to the northern (cold) hemisphere -
it's just raining here because a cyclon (GIOVANNA) passes the island - so
I've some more time to answer a bit longer.
Thomas
Von: Charles Marcus <[email protected]>
An: ASSP development mailing list <[email protected]>
Datum: 11.02.2012 16:56
Betreff: Re: [Assp-test] Antwort: Re: Antwort: Feature - replace
attachments with a link?
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
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
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
