Re: [exim] Attachment to weblink

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] Attachment to weblink
schmerold2@??? wrote:
> Thank you for the advice. Many of our staff are using mail as a filing
> cabinet - understandable, perhaps, however I am seeing more an more 5GB
> message stores, this issue will continue to get worse as time goes on.
> Outlook doesn't scale well with these large stores and it is putting
> putting a burden on our backup systems.
>
> End users are the problem - but they are the source of the butter for my
> bread. They want to send 20MB attachments to 100 internal staff members
> - urrgh!
>
> So my hope is that Exim can come to the rescue by striping the
> attachment and storing one copy on an accessible shared path - web ftp
> etc. There are a few products that handle inbound attachments, I would
> like to address inbound & outbound messages.
>


Ah, so ...

If you cannot break their habits, and if they *really do* send massive
attachments to many, many 'internal' recipients, then there are a couple of
other options.

You can save a great deal of I/O and storage if you store just one copy and
provide access to it to (only) all of the addresees *as they seek it*.

No need to worry about whether the traffic is 'special' or not - this approach
is 'universal'.

CAVEAT: I haven't used it in Donkey's years, but...

PowerMail (the one from the PowerDNS folks, not the for-fee MUA from
Swoitzerland), does this. ISTR is uses a DB to track what is where and for whom
stired and if read, to be moved or deleted, etc, but actually stores the content
in the fs, not in the DB, then uses multiple hardlinks to make it 'visible' to
each of the recipients, tearing them down as each user does their 'delete' until
all have done so (or not).

In any case, only one copy is stored, thus only one write on the inbound.
Reads, of course depend on how many viewers, and how often the look at the same
message/attachment before deleting it.

AFAIK, PowerMail can be put 'behind' Exim such that Exim handles the usuals,
does one transfer into PowerMail, which in this case would be acting as a
'samrt' mailstore.

I was using it with a PostgreSQL DB behind Courier-MTA at the time, so it is
more than five years ago. Perhaps much more... (Irish Alzheimer's here...)

There are no doubt other and newer methods, both MS and 'ABM'.

HTH,

Bill

> W B Hacker wrote:
>> schmerold2@??? wrote:
>>> I would like Exim to:
>>> 1. Strip any attachment larger than 10KB
>>> 2. Save it to a folder for hosting
>>> 3. Append something like this to the message:
>>> ------=_Part_20237_25078055.1269439861362
>>> Content-Type: text/html; charset=ISO-8859-1;
>>>     name=Ricoh_Aficio_SP3400N_SP3410DN_lores_brochure_pdf.html
>>> Content-Transfer-Encoding: 7bit
>>> Content-Disposition: attachment;
>>>     filename=Ricoh_Aficio_SP3400N_SP3410DN_lores_brochure_pdf.html

>>>
>>>
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
>>> Transitional//EN"><html><head><meta HTTP-EQUIV="PRAGMA"
>>> CONTENT="NO-CACHE"><meta http-equiv="Refresh" content="0;
>>> URL=http://www.salesforce.com/link-redirect.jsp?oid=00D600000007C6F&retURL=%2Fservlet%2Fservlet.EmailAttachmentDownload%3Fq%3De2%252BFw8USLKmVo661LN6Ti1PfTTGhnV9zAvoMyzeO6A%252B0WrjR44zzQTGaurqLZ2wHQgKpc7j%252FTH8A%250Ak6VCI%252F%252FUOQ%253D%253D&us=1"></head>Attachment:
>>> <a
>>> href="http://www.salesforce.com/link-redirect.jsp?oid=00D600000007C6F&retURL=%2Fservlet%2Fservlet.EmailAttachmentDownload%3Fq%3De2%252BFw8USLKmVo661LN6Ti1PfTTGhnV9zAvoMyzeO6A%252B0WrjR44zzQTGaurqLZ2wHQgKpc7j%252FTH8A%250Ak6VCI%252F%252FUOQ%253D%253D&us=1">Ricoh_Aficio_SP3400N_SP3410DN_lores_brochure.pdf</a><br></html>
>>>
>>>
>>> Anyone have any ideas regarding how to do this?
>> 'Not with the MTA' comes first to mind. BTDTGTTS
>>
>> - For purely 'internal use, we did it for blank forms, instruction sheets and
>> templates, legal and banking documents intra-office and inter-office (HQ and
>> branches).
>>
>> But I advise against using attachment *size* or even attachment *type*, as you
>> will miss things you want and capture things you do not want.
>>
>> What worked for us were synthetic user ID's - eg the sender specifically
>> addressed a given message to the ID of the storage folder(s), such as
>> 'blankforms@???'. We DID have Exim accept only our own staff as senders.
>>
>> The material was stored as-sent in ordinary IMAP folders and sub-folders.
>>
>> Those who had the need - and no others - were given access by ordinary secure
>> authentication - any such IMAP folder can support an arbitrarily large 'group'
>> of users.
>>
>> Nothing was webified or published externally with that system. It was left just
>> as you would have it in any other IMAP folder, so users had to extract the
>> attachment as needed for viewing, printing, editing, with their MUA.
>>
>> But we all know how to do that already, so no training load.
>>
>> If it is web-access you want, private, in-house, or to the whole world, there
>> are hundreds of web publishing tools, and they have their own security and
>> privilege control and upload/download/management toolsets.
>>
>> Most Mailing List Managers also have conversion tools or 'hooks' to them so as
>> to publish their archives on the web.
>>
>> But 'Horses for courses'.
>>
>> No need to involve an MTA or MLM, except possibly to notify interested lists of
>> folks that a new document or photo has been made available.
>>
>> For the purpose you cite, adopting an existing web publishing tool - designed
>> for the purpose, and with lots of testing and experience, security features
>> (careful with those!) and their own support groups - should be faster and
>> easier than trying to train and maintain Exim (or any other MTA) to do a job not
>> relevant to its primary purpose. Gettign the material In is only part of hte
>> job. You still need tools to edit, move, or delete it. Not to mention preventing
>> the unwanted...
>>
>> HTH,
>>
>> Bill Hacker
>>
>