Làm thế nào để xác định giới hạn kích thước tập tin đính kèm hợp lý?


13

Tôi sẽ thú nhận đây là một lĩnh vực mà tôi sẽ cung cấp cho nó 10-20mb và đưa ra một "email không dành cho việc chuyển tập tin" bất cứ khi nào người dùng nắm bắt được về việc phải sử dụng FTP.

Nhưng một mail server mới sáng bóng xứng đáng là một cách tiếp cận hợp lý ... vì vậy những gì một phương pháp phi voodoo để xác định một giới hạn phù hợp với kích thước tập tin đính kèm?

(Đang chờ xem liệu đây có phải là wiki không, hoặc nếu có một phương pháp nào đó tốt như vậy.)

Tôi nghĩ rằng sẽ có một số hướng dẫn tốt độc lập với môi trường, nhưng chi tiết cụ thể được yêu cầu - vì vậy 50 hộp thư, trao đổi 2007, AD, phần cứng là TBD. Khách hàng là một hỗn hợp 2007/2003, tôi cho rằng tôi đã đặt gửi / nhận để khớp, chỉ để mọi thứ đơn giản.



Đừng! Cảm ơn các liên kết. Kỹ năng tìm kiếm của tôi thất bại tôi ở đó.
Kara Marfia

Zero dường như là một giới hạn hoàn toàn hợp lý với tôi.
Tom O'Connor

Câu trả lời:


18

"Email không dành cho chuyển tập tin!"

Nói một cách nghiêm túc, tôi đặt mức của tôi ở mức 10 MB, cao hơn nữa và bạn có thể nhận được sự từ chối từ các máy chủ SMTP từ xa. Nếu công ty / khách hàng của bạn sử dụng nhiều tệp lớn hơn, tôi có thể bị thuyết phục đặt nó ở mức 15 hoặc 20MB nhưng không cao hơn thế.

Tôi hướng dẫn khách hàng sử dụng một dịch vụ như Dropbox nếu gửi các tệp lớn hơn. [Tiết lộ, đó là liên kết giới thiệu của tôi!]


Điểm hay, tôi đã không nghĩ về thực tế rằng một giới hạn tăng làm tăng các phản hồi mà họ sẽ nhận được từ các máy chủ thư của người khác.
Kara Marfia

1
+1 Đối với "Email không dành cho chuyển tập tin!".
Lankymart

9

Bản thân giới hạn có phần ít quan trọng hơn việc cung cấp một sự thay thế nhất quán, an toàn và dễ sử dụng cho những người dùng cần gửi và nhận các tệp lớn hơn.


2

Điều này phụ thuộc trực tiếp vào doanh nghiệp của bạn.

Tôi có những người dùng thường xuyên nhận được các tệp trong phạm vi 40 MB và đôi khi cao hơn mức đó. Tôi chủ yếu đặt một kích thước không giới hạn cho lý do đó.

Hãy xem các tệp đính kèm hợp pháp của bạn, lấy kích thước trung bình và nhân đôi nó, sau đó xem tệp đính kèm hợp pháp lớn nhất bạn đã nhận được. Nếu nó lớn hơn gấp đôi mức trung bình, thì hãy làm cho nó lớn hơn 50% so với mức lớn nhất cho đến nay.


3
Chắc chắn, và tôi có những người dùng thường xuyên cố gắng để có được 300 MB tệp đính kèm hợp pháp. Nội dung có hợp pháp? Nhưng kích thước không hợp pháp để chuyển email.
d -_- b

2

Công ty 10 MB! Ngoại trừ các giám đốc điều hành rộng mở. Chúng tôi đã mệt mỏi vì bị nguyền rủa!


Đáng buồn nhưng là sự thật! Hạn chế hộp thư đến cũng đi ra ngoài cửa sổ ở đó.
Kara Marfia

1

Tôi đang ở trong trại "10Mb và đó là lô của bạn". Đó không chỉ là những gì bạn có thể gửi mà còn là những gì bạn gửi đến có thể nhận được. Trừ khi doanh nghiệp của bạn hoạt động trong một lĩnh vực mà việc gửi các tệp nhị phân rất lớn qua email là tiêu chuẩn thì tại sao lại tăng cao hơn?

Ngoài ra, bạn cần đảm bảo rằng bạn cung cấp một giải pháp thay thế cho những người thực sự cần gửi các tệp lớn hơn, cho dù đó là một cái gì đó như Dropbox, một máy chủ FTP lỗi thời hay thông minh khác (Chúng tôi có máy chủ và dung lượng băng thông để cung cấp dịch vụ riêng của chúng tôi tương tự như dropbox cho người dùng của chúng tôi, như nó xảy ra).


1

Tôi có xu hướng tăng cao hơn một chút và leo lên trên 30 MB. Nó sẽ thay đổi từ doanh nghiệp để kinh doanh. Thay thế cho tệp đính kèm, hãy thử senduit .


Này, giao diện đó rất đơn giản, ngay cả khách hàng của chúng tôi cũng không thể làm hỏng nó ...
Kara Marfia

1

Dù kích thước là bao nhiêu, hãy đảm bảo giữ giới hạn đến vượt quá giới hạn gửi đi . Máy chủ có thể và sẽ trả lại thư của bạn bằng cách gửi lại (tất cả thư) nếu có lỗi không liên quan đến kích thước (sai địa chỉ hoặc như vậy) và ngay cả khi nó sẽ chỉ thêm một vài byte bạn không muốn từ chối thư đó dựa trên kích thước.

Ngoài ra, một số "ứng dụng email" (tôi sử dụng thuật ngữ một cách thận trọng) tạo trả lời cho các email có tệp đính kèm bằng cách thêm cùng một tệp đính kèm. Bạn cũng không muốn trả lại những thư đó, thật ngu ngốc vì hành vi này có thể xảy ra.

May mắn thay, có các MTA đẹp (không phải Exchange, nhưng ví dụ postfix là một) cho phép bạn hạn chế trả lại ở kích thước thấp hơn nhiều so với thư gốc. Vì vậy, trường hợp đầu tiên có thể là sự suy giảm vì tính năng này được áp dụng ngay cả bởi các MTA dũng cảm.

Dù sao, sự lựa chọn kích thước thực sự phụ thuộc vào người mà bạn chủ yếu giao tiếp và giới hạn của họ là gì. Trong các doanh nghiệp đồ họa, kích thước tối đa của megabyte ba chữ số không phải là chưa từng thấy, ở các doanh nghiệp khác (tôi muốn nói là các học giả, nhưng thời gian đã thay đổi, đáng buồn thay, bạn thậm chí có thể tránh xa việc nói với mọi người rằng bắt đầu đính kèm là thông lệ xấu. Tôi biết tôi đã làm, nhưng đó là mười năm trước :(


1

10MB ở đây cũng vậy. Nó dường như là tiêu chuẩn được chấp nhận. Tôi có những khách hàng phàn nàn về nó (đặc biệt là một nhóm kiến ​​trúc sư luôn sử dụng "bản vẽ CAD lớn" như một lý do để ghi đè bất kỳ hạn ngạch hoặc giới hạn nào) nhưng tất cả chỉ cần gửi cho họ rằng (1) email là một chia sẻ dịch vụ, và do đó các hoạt động của họ có thể ảnh hưởng đến sự sẵn có cho người khác và (2) họ phải chơi đẹp với người nhận.

Đối với bất cứ điều gì vượt quá giới hạn đó, có rất nhiều sự sắp xếp thay thế có sẵn, vì vậy mọi người đều có thể được giữ hạnh phúc.


1

Chúng tôi đặt giới hạn của mình cho dù giới hạn của Gmail là gì. Chúng tôi nổi tiếng là điếc trước những lời cầu xin của một số nhà khoa học ở giữa chúng tôi, những người muốn gửi email các bộ dữ liệu lớn qua lại với các nhà nghiên cứu. Đây là lý do tại sao chúng tôi vẫn có cả máy chủ thư của bộ phận và máy chủ Exchange hỗ trợ người dùng 4000 lẻ và cửa hàng thư dưới 1TB.


1

Ở cấp độ PC riêng lẻ, tất cả những cải tiến đáng kinh ngạc về tốc độ và dung lượng phần cứng đã mang đến cho mọi người cảm giác lệch lạc về những gì hợp lý. Máy tính và máy tính xách tay nhanh với ổ cứng 500 GB + giúp xử lý các bức ảnh 5 MB từ máy ảnh kỹ thuật số, phim ảnh, tài liệu có nhiều hình ảnh được chèn, v.v., không có vấn đề gì.

Sau đó, họ muốn gửi chúng qua dây ... Vâng, nó hoạt động rất nhiều thời gian để gửi 20MB, 50 MB, thậm chí các tệp đính kèm lớn hơn. Nhưng khi có sự cố xảy ra, nó làm mọi thứ rối tung theo một cách lớn hơn nhiều. Có các tệp lớn hơn trong hàng đợi, có thể phí băng thông của bạn tăng lên, đại loại như thế.

Dù sao, đó là tất cả sơ bộ cho những gì chúng tôi đã làm: rút 20 MB ra khỏi không khí và nói "đó là nó." Nó đủ lớn để chúng tôi có thể liên kết nó với kết nối 100MBPS của chúng tôi và cố gắng cung cấp cho họ cảm giác về những gì sẽ xảy ra nếu 50 người cố gắng gửi cùng một tệp có kích thước.


1

Để đáp ứng giới hạn 5 MB hoặc 10 được xác định trên một số máy chủ Nhắn tin riêng (Exchange, Qmail ...), có một giải pháp chuyên nghiệp khắc phục kích thước và loại tệp bạn muốn gửi. Giải pháp này cũng cung cấp khả năng truy nguyên và bảo mật mạnh mẽ mà không cung cấp FTP (mật khẩu và tên người dùng rõ ràng ...). Cũng khả dụng trên môi trường di động (iPhone, Windows phone 7 / mobile, Blackberry, ...)

Có sẵn 2 công nghệ:

Giải pháp chế độ nền tảng:

http://www.edipoles.com/index.php?id_page=36&openPanel=1

Giải pháp trong plugin Outlook:

http://www.edipoles.com/index.php?id_page=30&openPanel=1


0

Có bao nhiêu người dùng? IMAP? POP3?

Tôi không bận tâm với bất cứ điều gì trên 10, như bạn nói, đó không phải là dịch vụ chuyển tập tin.


0

Đã gửi hoặc nhận email đính kèm? Tổ chức của bạn có sử dụng MS Exchange / MS Office Outlook / Active Directory / SharePoint không? Nếu vậy, phiên bản nào? Đây là chủ đề phức tạp.


0

Nghiêm khắc, thả lỏng. Tôi sẽ chấp nhận mọi thứ lên tới 100 MB, nhưng tôi từ chối mọi thứ trên 15.


0

Khi thế giới tiến bộ, chính sách cũng vậy. Với bản nâng cấp gần đây của chúng tôi lên Exchange 2010, chúng tôi đã tăng giới hạn gửi / nhận lên 25 MB (giới hạn của Gmail). Với các dịch vụ email được lưu trữ của Gmail mở rộng, bạn sẽ chỉ gặp vấn đề với giới hạn thấp hơn. Nếu không gian lưu trữ không phải là vấn đề (xem xét các đĩa nhỏ hơn, nhanh hơn và rẻ hơn) thì tại sao không?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.