Re: RFE? Handling of big attachments (revised, long)

[Michael Kolmodin]

OK, folks, it might make sense to bring  this one into new life. Sorting this newsgroup after contents, you will find some discussion early this year about handling of big attachments. I havn't followed up the discussion until now because I've felt that other issues were more important at that time. However, it might be that this is the time for a new discussion on this topic. If not, let me know !

My basic idea is still that we should make it simple for users to distribute big attachments as links to a ftp server rather than as numerous copies which causes problems for the email infrastructure. I feel that if we can solve this, it can be a real USP for Mozilla both from a company and a ISP perspective.

>From the previous discussion, I think there is an overall acknowledgement that this really is a problem, and a solution would be nice. But:

• Who is supposed to provide space for the attachment? for how long? to whom?
• Firewall issues
• User interface?
• Overall feeling that is is a large amount of code.

Some has acknowledged the problem but argued that it's better solved by chopping the attachment into pieces before it's sent, recombining them at the receiving part. Although this might be nice, I think this misses the real problem: the large amount of data when big attachments are sent to i. e. mailing lists.

Summing this up, I get the idea that when the composer's publish functionality will be in place (at latest 1.0, as I understand it) and if Ben Bucksch's proposal to somehow make it possible for ISP to "preset" certain configuration parameters such as mail servers,  news accounts, proxies etc.  is implemented then a solution might be pretty straightforward - if it is supported by the ISP/IT dept. Something like this:

ISP/IT-dept presets following things:

• Address of ftp server (or possibly two, see below).
  
• Max size for "unlinked" messages. Messages exceeding this size will force user to choose between normal operation and "linked" operation.
• The template for a text message containing the link to the message. This message reflects  the policy on the ftp server: "The attachment can be retrieved as <link> within one week from this message"
• Firewalls: Organisations which have firewalls have typically two ftp servers: one for internal stuff  and one for public available things.  Adresses of both  is also preset by ISP. In this scenario, it's actually an advantage that internal stuff stays in the organisation.
• Strings used in the user dialogue below.
  

Of course, these settings might be available in a advanced section. Doubt that this is meaningful: there is only a narrow window between  when the ISP is doing  the job or the user is capable of editing a text file

>From a user perspective everything happens when pushing the "Send" button:

• When sending attachment smaller than the preset size: no change
• When sending a larger attachment The user gets a dialogue saying " This is a really large attachment. Send as link (recommended by IT dept) ? Yes/no"
• When sending a large attachment from organisation with  both internal and external ftp server (firewall scenario): two questions: Yes/no for Send as link and radiobuttons for external server/internal server.
• Before the message is sent, the attachment is uploaded through existing code and replaced with the message template, putting in the link to the server. During this, a separate infobox is displayed. When done, the normal send procedure takes place.
  

Actually, I think this is a good feature at a reasonable cost if we have the composer upload and ISP "preset configuration" in place. Any comments before I make a RFE entry in Bugzilla for this?

BTW: Where is the ISP "preset configuration" proposal from Ben Bucksch discussed earlier in this group?

--Michael

[EMAIL PROTECTED]">